How to program a NINTENDO POWER Cartridge ?

Hello there,
I bought a NINTENDO POWER Cartridge and try to program other game into it.
The original game in NINTENDO POWER Cartridge is Derby Stallion .
I programmed the Fire Emblem: Thracia 776 to the flash but the game is only black screen of death .
Did someone else have had this problem and know a way to fix this?
Does the the Fire Emblem: Thracia 776's rom has been revised for emulator ?

I usually use normal cartridges to program NP games. Did you make sure, if the game/cartridge are actually matching? HiRom/LoRom, SRAM, etc..

But some Games are only release in NP,like :[Genjuu Ryodan]，[Super Famicom Wars]...etc.
these games has not HiRom/LoRom etc.

You're supposed to be able to tell whether a game is LoROM or HiROM from a byte in the game's internal header.
For LoROM, byte $7FD5 will have a value of $20 or $30 and byte $7FFD will be $80-$FF.
For HiROM, byte $FFD5 will have a value of $21 or $31 and byte $FFFD will be $80-$FF.
Add $0200 to each if your image has a (redundant) floppy copier header.

How did you manage to write to Nintendo Power cartridges ???
I was thinking that it would be impossible to write anything to the FLASH chips without first sending some some secret unlocking commands to the MX15001 chip...
Did somebody figure out how to do that? Or is there no such protection at all? Or did you simply bypass that protection by doing some hardware mods... like desoldering the FLASH chips? Or do you have one of the official store/kiosk programming stations at home?

I just managed to pick up one of the NP SFC carts on Ebay for $20US. I'll play around with it when it arrives and let you know what I find out.

I'm almost certain he programmed the FlashROM directly. You probably don't *have* to desolder the chip to do this (example), but it probably makes it a whole lot easier if you do.

Nintendo Power carts are not just individual games: there's a boot menu in there that also handles all the mapping for the games. If you don't copy that (and likely, modify it for the game you want to run), then the mapper doesn't set anything up and it won't work. Your best bet would be to image a real Thracia 776 NP cart and then burn that image verbatim.

I'm glad this thread exists. I've stated that I am unwilling to collect and/or dump any flash carts (BSX/NP) because they are basically USB sticks with a weird connector and raw file system. Now I have a link to show people.

If nintendopower pulls this off, he can flip $20 eBay NP carts for $400 Wizardry 1-2-3 carts until the market catches on and all NP carts lose all their value, if he were so inclined. We already have eBay sellers reprogramming NSS carts thanks to nocash's info, so this is inevitable I suppose.

I say we go ahead and do it. Reflashed NP would make a nice boot loader for my serial port controller, I keep wiping the SRAM on my current devcart and having to break out the Super UFO to rewrite it. (I guess I could dual-purpose quertymodo's Cx4 devcart though too.)

As far as reprogramming a cart through SNES code ... the actual programming of the flash chips is almost certainly the usual 0xaa55-style commands for BS-X and GBA RAM. The flash vendor interfaces are usually very similar to each other, with a few minor tweaks. But there's probably some extra catch like a "write enable" register/sequence that the NP reprogramming stations performed via running its own boot ROM instead of booting directly off the cart. Unlikely it's anything super complicated like special voltages applied to pins that a regular SNES console can't do, to turn on reprogramming mode, although I guess we can't rule that out.

Best bet to learn how to do this through cart swapping + reprogramming, would be to emulate the actual NP menu and memory mapping chip. Get a good idea of the register space involved, look for gaps in the register table, and start experimenting. Use the usual GBA RAM rewrite command style on it as you brute-force any kind of enable handshake.

But hell, it may have no enable required at all. I don't think anyone's actually tried a straight up cart swap GBA-style reprogram before.

EVERY SNES game has a mapper, whether it be LoRom or HiRom.

As for the cartridge itself. I used simple SHVC-1AxM-xx (LoRom) or SHVC-1JxM-xx (HiRom) donor boards from sports games and the like. Programmed the EPROMS (usually 27c801 or 27c322 with a few other decoders) and replaced the original MaskROM.

That way I have made Genjuu Ryudan, Power Lode Runner and other NP games, like the Picross series. Not for sale though!

I never had a NP Cartridge in my hands yet but I might buy one just to see how it works.

This is not true. LoROM and HiROM are not "mappers". They are terms we use for two different memory models. Nintendo refers to them as "Mode ##". They are not memory mappers in the sense like NES or SA-1/SDD-1 because they aren't capable of mapping anything on the fly. They are just a static setup of how the memory is mapped.

Take Killer Instinct for example. This game consists of only two chips on a very small PCB. One 32 Megabit MaskROM and the Lockout/CIC chip. The game is "HiROM". But there is no mapper involved. The game is "HiROM" because of what signals on the MaskROM connect to what signals on the cartridge port.

My bad, "mapper" was indeed a wrong expression. HiRom/LoRom is determined whether Pin 40 is connected to A15 or not.

So why is there 7 numbers on the front? Can it hold 7 games? I didn't even know these existed until this thread! How would they program?

Yes it can hold 7 games if they are small enough to fit into the memory space given. These cartridges where programmed at stores by a Nintendo Power writer machine. Think Famicom Disk System writer, but instead it's SNES and using Flash Memory.

Interesting! Is there any write-ups on the specs for this cart? What it can and can't do? I assume it won't do any special chip games....

Does anyone here have one of the programming machines?

I picked up a few of these NP carts and they are interesting....

It appears there is a menu to select from (albeit in Japanese).

I have a DK3 and street fighter 2 hyper fighting. The cart inside has the potential of 3 16mbit flash chips but only 2 of the flash roms are installed. So it would seem that whatever can be programmed, couldn't be any bigger than 48mbits or total more than 48mbits. DKC3 is a 32mbit game so that completely occupies the 2 flash roms on the cart.

There are three chapters about Nintendo Power carts in fullsnes.htm, http://problemkaputt.de/fullsnes.htm#sn ... rflashcard
The I/O port chapter is essentially a long list of unknown details, ie. just a list of unsolved problems.
The FLASH directory chapter is more or less complete (some details about SRAM/HiROM allocation are missing), but it's unknown if the cartridge is using that directories for ROM/SRAM allocation at all - it's also possinle that there is a second directory stored inside of the MX15001 chip, and that the per-game memory mapping is initialized based on that info (so the FLASH directory would be merely used for GUI purposes, such like displaying the game title bitmaps).

Some things that would be interesting...

One simple thing: Dumps of more FLASH directories: That would help to figure out if there's any SRAM/HiROM allocation info in the directory.

More difficult: Somehow confirming if there is a second directory (in the MX15001 chip) or if there is none such.
Ie. doing something like desoldering the FLASH chips from one cartridge, and installing them in a different cartridge (one with differently mapped games). If that is working, then there would be apparently only one single directory (in one of the FLASH chips) (technically, that might be possible: the MX15001 chip might be able to take control of the databus during /RESET, so it might be able to read the directory info from the FLASH chip, and then map the selected game accordingly) (of course that theory won't work for bigger 4Mbyte games which come up without any menu/directory).
Being pessimistic, I would suspect that swapping the FLASH chips won't work, and that the whole (de)-soldering work would just result in crashing right after selecting a game from the menu. And even if it would work: It wouldn't really on learning how to reprogram the cartridges without soldering.

The only way to learn how to reprogram the carts is probably hacking one of the offical programming stations. As by now there seems to be little known about them. Photos of their PCBs/chipset would be nice, and one would also need dumps of their storage memory, whatever they've been using there... ROM, EPROM, FLASH, HDDs?

I'll take some pics. Maybe I'll try swapping the flash roms...if I have time.

I noticed I have 2 different versions carts..

SHVC- MMS - X1. (SF2)
SHVC -MMS - 02. Dkc3

Here's some info on programming the Nintendo Power gameboy version: http://blog.gg8.se/wordpress/2013/02/25 ... and-tears/ - for technical info: you can skip most of the text, and look at the "appendix" at the bottom of that webpage.

Normally, writing to FLASH chips would be done by writing 8bit data to a 24bit address. If I do understand the above appendix correctly, then it seems as if one would do that same thing in a more indirect fashion on nintendo power cards: Write one 8bit data value, and three 8bit address snippets to some I/O ports (?).

Did anybody ever try writing to the Nintendo Power FLASH memory yet? If not... the first try should be, of course, directly writing to 24bit addresses. If that doesn't work, then it might worth trying the command sequences from the above appendix (the gameboy addresses at 0120h and up obviously won't work on SNES, but using address 2400h and up might do it, since the snes menu program is using that addresses, too).

If it should be possible to write to FLASH memory, then the only remaining problem would be the memory mapping, for mapping the selected game into memory.

Ok, I removed the DKC3 J flash roms from the power cart. I read them using the mx29F1610 IC type (the actual IC is mx29F1601 but I couldn't find ANY information on this IC). I compared the files I read out of the 2 flash roms to the SFC DKC j version and they compared exactly the same. SO I had this bright idea (Not so bright) to re-flash the chips to the USA version DKC3 and was going to re-mount the roms to see if it worked. BUTTTTT, when I tried to write to the flash rom, I keep getting errors... so I'm wondering if it has some protected sectors. And now my flash roms are not correct either English or the Jap version. SO I'm stuck
I've ordered some generic flash roms that *should* be the same so I'll try them when they arrive. Obviously, it'd be nice to program through the cart edges but I'm a long way from that.....

I'd really like to know how the FMGBx guy figured out those commands in the first place. Is there anyone who speaks Japanese that would be willing to try and ask him?

But this seems to make it highly likely that my presumption is correct, the GB NP carts appear to work exactly as I said the SFC NP carts should: standard commands after an I/O unlock. No special programming hardware required.

Does anyone have an SFC NP menu ROM handy? I'm curious if pressing all buttons at once gets you into a debug mode. Obviously you can't do that with real hardware (easily) or with just any emulator. You need one that allows U+D and L+R simultaneously.

That the existing games hold 32mbit of flash ROM, and yet the maximum number of games on one cart is 7 (as opposed to the more logical 8), tells me that the menu data only exists when there is more than one game. Hence if you have seven 4mbit games, you need a bit of extra room (maybe not the full 4mbit) for the menu. With just one game, they'd have to omit that to fit a 32mbit game on there.

So either the MegaChips has logic to detect the contents of the flash and set up the memory mapping on its own (for single games; Thracia 776 should be 'LoROM' and DKC3 should be 'HiROM', so it's unlikely it just defaults to one or the other) or with only simple hints from a menu ROM; or it has internal storage as well. I am thinking the former is probably more likely. Especially in light of FMGBx. The GB doesn't have address pin layout changes, but it does have MBC changes, so it'd have similar issues for multi-boot.

Yes, that was a bit too fast ahead : - ) Before trying to store retail ROMs on the flash chips, one should first try to swap flash chips form one NP cartridge to another. That, for games that do use different mappings (eg. replacing a LoROM game by a HiROM game, or replacing a big LoROM game by several small LoROM games).
If that is working then we would know that all mapping info is stored in the FLASH chips, without additional important/hidden mapping info being stored in the MX15001 chip.


Interesting effect. Hmmm protected sectors? Does it look like so to you? Ie. do you get write errors only to certain regions, and other regions are writeable without problems?
Theoretically there should be no protected sectors: The game slots should be writeable, and the directory (at the end of the menu area) should be writeable. The menu might be write-protected, but as far as I know, it's possible to store 4Mbyte games without menu, so the menu cannot be write-protected either.
However, there might be some nonstandard commands in the flash chip, or it might use standard write-protection features (being unlocked by the programming station). Or you might simply have bad contacts on some pins - did you check if the dump from the chips was intact, eg. loading it into a emulator? If you got corrupt data on reading, then it would be no surprise if you get errors on writing.

My programmer has a pin connect function so it will tell me if a pin connection is bad. Even so, I did a comparison to the .SFC rom and it was exactly the same. So I'm certain that the chip reads were good.

Do you want me to send you the images? If the compare was the same as the .SFC, then where could the menu (and menu sound) be stored?

When I tried to write to the MX29F1601, it would error out almost immediately.... A few seconds into the program initiate. But something did change as my compare data did change in the flash chip.

I haven't tried loading the rom image into an emulator. Since it compared exactly to the .SFC dkc3j, I would bet that it would work. (I combined the 2 images into 1 4mB image to do the compare)

NoCash, I also picked up a derby98. Should I try swapping those chips to the DKC card?

And why is one card "x1" and others "02". What could be the difference?

Derby98 is LoROM, and DKC is HiROM? Then, yes, would be interesting if the LoROM game works on the PCB that has formerly contained the HiROM game.

The X1 and 02 boards seem to contain the same chipset. Some resistors/capacitors are arranged differently. It's probably just some cosmetic revision.

What do you mean by where the menu could be stored? The theory is that the menu is stored in first 512Kbytes of FLASH memory, but only if you have multiple small games on the cartridge - not if you have a single big game on it. Or did you see a menu being displayed before dumping the chips?

The programming errors might be a problem with unsupported commands, or timings, or so. If the erase command didn't work, then you would probably get the old data ANDed with the new data (ie. some bits changed from 1 to 0, but, due to the missing erase, no bits changed from 0 to 1).

I swapped the chips from derby stallion 98 to the DKC3 cart. Game works.
And it does boot to the menu first.

And I am 90% sure the DKC3 booted to a menu first but I can't swear to it.

That's great news! Looks as if the thing is less complex than expected (ie. no hidden data stored in the MX15001 chip).

Here you go.

I have three games on my NP cart: Torneco no Daibouken – Fushigi no Dungeon, Super Trump Collection 2, and Shanghai III, all of which show up in the selection menu when loading this up in an emulator. So obviously, game info (and possibly, game mapping) is stored in flash ROM.

Do you have details on the memory layout of the three games? Ie. are they LoROM or HiROM, and what ROM size and SRAM size (if any) do they have?

Nevermind, I've checked them myself:
File1: http://superfamicom.org/info/torneco-no ... no-dungeon SHVC-TQ, LoROM, 12Mbit ROM (1.5Mbyte), 64Kbit SRAM (8Kbyte)
File2: http://superfamicom.org/info/super-trump-collection-2 SHVC-AQKJ, LoROM, 4Mbit ROM (0.5Mbyte), No SRAM
File3: http://superfamicom.org/info/shanghai-3 SHVC-AS3J, LoROM, 8Mbit ROM (1Mbyte), No SRAM

File1 has 8Kbyte SRAM as indicated by directory_entry[0005]=0040. Accordingly, the SRAM base address is raised for the following two files. Actually File2 and 3 don't use any SRAM, but their SRAM base address is raised anyways: both have [0002]=04, that confirms that [0002] contains the SRAM base address, counted in 2Kbyte units. So the format of the directory entries is now fully known:


There isn't any LoROM/HiROM flag in there. Most games are LoROM. But there are at least a few HiROM games: Rockman 7, and Super Donkey Kong 3.

For Rockman 7, I have a dump of it's menu entry, and there isn't any special bit or byte in there, nothing that would indicate it being a HiROM game. So the MX15001 must apparently first map the selected game file, and then examine its cartridge header at 7Fxx and FFxx to determine if it's a LoROM or HiROM game (much like emulators are doing it, eg. by comparing the checksum value against the checksum complement - even that simple comparision would be quite amazing for a logic chip, maybe there's some microprocessor in the MX15001 for handling that task).

For Super Donkey Kong 3, markfitzb has dumped the two desoldered FLASH chips. That kind of low level dump is interesting because it allows to see how the HiROM banks are stored: In that HiROM cartridge, the cart header is located at ROM offset FFxx, which means that the ROM isn't interleaved (in that case the header would appear at 7Fxx even for HiROM games, which would simplify the mapping, but Nintendo didn't do that).
Super Donkey Kong 3 is 4Mbyte, occupying the whole FLASH memory, without menu, and without any intact looking directory entries at offset 060000h, so it seems to boot up using the cart header instead of the directory.

Oh, and mark also made a low level dump from desoldered Derby'98 chips. Derby'98 contains the menu/directory in first 512Kbytes, Super Donkey Kong 3 doesn't contain any menu/directory, so I am very sure that the latter one didn't displayed a menu.

For the FLASH chip that got corrupted by mark's write-attempt: It turned out that the whole chip is just FFh-filled. Ie. the erase worked fine, but writing didn't work for whatever reason.

If somebody has a digital scope: It would be interesting to view two signals when selecting a game in the menu:
/RESET signal, on one scope channel (used as trigger)
/OE or /CS signal for FLASH chip, on the other scope channel
Theoretically, /OE and /CS should be toggled a bunch of times during /RESET=low (assuming that the MX15001 chip is really takng control over the databus for reading directory & cart header).

I haven't been able to find a data sheet on this chip.. The MX29F1601MC I wonder if the OE and CE are reversed maybe??? Anyone know of a datasheet? I tried to look it up on the almighty google but came up with not much useful. And the chip isn't in my programmers directory so I had to use one close to it (the MX29F1610 and similar) to read the chip.

Your overall wiring seems to be okay since you have successfully managed to send the erase command to the chip.

It's possible that Nintendo has bought FLASH chips with customized protocol for write commands from Macronix (for the Satellaview mini-flashcards, they seem to have bought customized FLASH chips with special ID commands).

Apropos, ID. Does your programming tool allow to read chip IDs, and if yes, what ID values does it show for the FLASH chips?

Here are some photos of the PCB front & back sides: http://www.snescentral.com/article.php?id=0799 the picture quality is very bad. But it does look as if the thing connects to Pin 1 (master clock) and Pin 2 (expand). Master clock would make sense since the MX15001 should require some clock signal to read the separate header/directory bytes. Expand would suggest that one would need to inject some signal/voltage to that pin to unlock writing, which should be no problem, except that it couldn't be done on normal retail snes consoles.
Better photo of the PCB back side would be nice to confirm that!

EDIT: Satellaview carts have EXPAND (Cart.Pin2) wired to SYSCK (Cart.Pin57) via a 100ohm resistor. Maybe the NP carts are doing that, too?

Does Wizardry123 only work on the NP cart? I got it to load on a Lo Rom cart but can't start the game. gives my a system file message error "wiz1 sys file" and then a bunch of Japanese characters..

Thanks

ファイルが、こわれています。

"The file is broken/has failed."

Wierd. It boots with animation and sounds.... Just won't go into a game.
I did use the English translation so I need to try the original next...

Edit: tried original J version. Same result.

OK, I got my MX29F1610MC flash roms in today. I programmed the DK3 that came on the cart to begin with. As a reminder, the original roms are MX29F1601MC. They both got hot real fast! needless to say the game didn't work. So what would make the cart get real hot?? the heat was from the roms. SO if I can read the roms just fine, why wouldn't the cart read them also? REALLY need a datasheet for the MX29F1601....

Oh, and I've mounted these before without issue so I don't believe the problem was mounting.

Maybe it's actually talking about the save data? (assuming it saves progress, I have no idea about that game) What happens if you wipe it?

I've tried everything possible. Tried to change, delete, alter, rename..... nothing will get this to go into game mode.

I burned the original Jap version, and it acts the same way.

edit: I using a 1A3M host cart. I even tried it on a 256k cart. no difference

How in the hell would we know that? :P
It's not because Wizardry 1-2-3 is stored on them, I can surely tell you that much.

I've only ever had chips boil when I ended up crossing wires or connecting them wrong.

ICs in general more or less only ever get hot because of bus conflicts, using the wrong voltage supply, or being given invalid voltage inputs causing both FETs on an input stage to be on.

I was hoping for someone would use their crystal ball. I figured there are significant differences between the flash roms....
I was hoping for suggestions on where to start looking. I know it wasn't because of game program on them (DK3 was programmed by the way, not Wizardry).

If my programmer can read the chips (read them as if they were the MX29F1610MC) then I would think that the data and address lines are the same. And probably the /CE and /OE as well..... whats left beside /WE...

I'd test Vcc first, because it's by far easiest (and fast). After that, Vio seems more likely but more involved.

Hard to say, but just throwing random ideas out there, the MX29F1610 comes in a "reverse type" where the leads are bent backwards in order to simplify placement on opposite sides of a board, might want to check that you don't have one of those, or you'd have it soldered in backwards. I can't find a datasheet for the original chips, but here's the datasheet for the 1610. That being said, my money would still be on a soldering issue, like an improperly seated chip or soldering short.

Anyone here have the time to verify/cross-check the schematics I made?
https://dl.dropboxusercontent.com/u/209 ... ematic.png

Here are some pics of the cart:
https://dl.dropboxusercontent.com/u/209 ... r_back.JPG
https://dl.dropboxusercontent.com/u/209 ... _front.JPG

Cool. Interesting to see the MX-chip pinouts. Some comments...

Marking not-installed resistors would be nice (eg. as "N/A" instead of just leaving the description blank).
Some more wires (and bold address/data bus lines) might also help to see what goes where.
I would have probably numbered the FLASH and SRAM A0,A1,A2... address lines the same way as on SNES side (instead of using the shifted 16bit FLASH chip numbering.

The "MC" signals, MC35 and MC36 are connected to the battery controller... and the other MC's like MC38, MC_72, MC_74, MC_96... are they connected anywhere? I can't see there, although there is a short green wire attached to those pins (which is somehow suggesting that they are connected, if they aren't then I would leave them without green wire, and without external signal name (ie. only use an internal pin)).

Going by a PCB photo, there seems to be a via between R11 and R12, so there's probably something more connected there (just two resistors in series wouldn't make too much sense anyways, especially if one of them isn't installed).

Oh, nice to see SYSCK being passed to EXPAND via R14. It's same as for Satellaview carts (ie. apparently intended for passing SYSCK to the satellaview receiver unit on expansion port). Btw. you forgot the resistor value for R14 (going by PCB photos it's having 100 ohms installed, which would be also same as in satellaview cartridges).

R1 and R4 are 510K and 510 ohm accordingly (not 500K and 500). If you can decipher the part numbers on the real board: There are hires PCB photos earlier in this thread (the 3-digit numbers are reading as NN and number-of-zeroes, eg. 123 = 12000 ohm = 12K ohm).

There seem to be further vias near R1 and R4 which aren't showing up in the schematic. And more vias on A12 and A23 on the cart edge connector. There seems to be stuff missing in the schematic, unless the vias are dead-ends without connection (btw. a photo of the PCB bottom side would be nice).

On PCB front side, cart edge pin 32,33,34,35, and 49, and 60,61,62 are not connected (probably more on bottom side). Would be neat to indicate that in the schematic. I guess your CAD software autogenerated wires on each pin - but it should (hopefully) allow you delete that wires in cases where the pins aren't connected.

Thanks for your input, really appreciate it.

You're absolutly right about R11 and R12, R11 goes to the MegaChips' Pin 38.
MegaChips 96 is connected to the edge connectors reset pin.
Still can't find MegaChips pin 72 and 73.

Thanks for the update and PCB photos!

MM1134 pins should be as so:
So MC36 would be /SRAM_CS (forwarded from pin7 to pin5 when VCC is good).

And MC35 would be /RESET (low when VCC is bad), that would serve as power-on reset signal for the MX1500. The other /RESET pins (MX1500 pin 96 and 100), one of them should OUTPUT to SNES (when starting a game selected in the bootmenu), and the other one is probably INPUT from SNES (on power-up, or when pushing RESET button). No idea which is input and which output since they are just shortcur together.

MX1500 pin 30 + 31 are apparently oscillator inputs (could be named OSC1 and OSC2 or so), in this case driven by the 21MHz master clock SNES rather than using a separate oscillator.

MX1500 pin 29 and 38 are still looking weird. If there's no other connection to those pins then I've no idea what they could be good for. My first idea would have been pin38 = /SRAM_WE, but it seems that the SRAM write enable is shared with /FLASH_WE3.

MX1500 pin 72 and 73 could be anything. Are they wired to any vias (underneath of the chip) or are they just not connected? One guess would be that they could be upper address lines for FLASH memory (Nintendo is often doing that: outputting the higher address bits together with separate /CS1 and /CS2 signals), maybe intended for testing/debugging, or allowing to use a single big FLASH chip instead of 2-3 smaller FLASH chips in future hardware revisions... though in that case they would also need an option for merging the /CS1,2,3 and /WE1,2,3 signals to single pins.

MX1500 pin97 might be some mode selection input, that could be pulled high or low by installing either R9 or R10. Maybe for selecting between multiple small FLASH chips and single large FLASH chip. Or for indicating if the 3rd FLASH chip is installed. Or whatever. Some of the GNDed pins might be also whatever mode selections.

Oh, and C5 should connect to pin91 instead of to R9 (they are both VCC, so it would matter only for context & signal run time).

EDIT: CIC_10 could be called /CIC_RESET or /CIC_ERROR. It should get low (pulsed) on CIC region errors. And it might also get low on power-up or when pressing Reset button (in that manner it would be a 4th reset signal on the MX1500 chip, doubt that the MX1500 relies on this extra reset input). When using the cartridge with non-japanese consoles, then one would probably cut the CIC_10 signal, and strap MX1500 pin 93 to VCC (?)

Turns out MX1500 pin 29 is VCC

Ah, then everything makes more sense (and pin 38 would be another "mode select" input with either R11 or R12 installed, similar to pin 97).

Could you check R7 and R8, too? Both would make more sense if they would go to VCC instead of GND.

PS. and double check if FLASH_WE3 is really shared as SRAM_WE? It's possible, but looks quite odd. But having three separate FLASH_WE signals is odd anyways, no idea what they have intended there.

PPS. why is the schematic called "Nintendo SF-Memory Cartridge"?
"Nintendo Power Cartridge" would appear more obvious to me : -)

WE is shared between the 3rd Flash and the SRAM, just double checked again to be sure.

Okay, you are right. Thanks for checking!
One small detail: the signal on MX1500 pin 34 should be marked GND.

So I desoldered the two MX29F1601 flashroms out of my NP cart and wrote a programmer based on Arduino for them. It works but takes 4 hours because I am supposed to write 128 bytes at once but I only write one byte at a time. Because otherwise I get alot of unwritten bytes. So no special write commands, no protected sectors, just a changed protocol that I don't fully understand, which is why it takes 4hrs to write them.

Now I did the following tests:
- flashed a retail Illusion of Gaia to one of the MX29F1601 and put the flashrom into a standard hirom pcb to confirm that you can indeed flash the MX29F1601 -> it worked flawlessly
- flashed a retail Illusion of Gaia to one of the MX29F1601 and put the flashrom back into the Nintendo Power cartridge -> didn't boot
- downloaded Wizardry 1-2-3(from some emu site), split it into two and flashed it to both MX29F1601 -> didn't work
- flashed back the Derby Stallion 98 with menu that was on there before -> worked

My conclusion, that could be wrong, is that when the rom you flash has a menu you can flash the MX29F1601's and it will work. If you flash something that doesn't have a menu it won't boot. Most likely there is something in the MX1500 chip that needs to be setup if there is no menu.

I did not have any luck flashing the MX29F1601 while they are still soldered into the NP cart even though I connected the missing WE/OE pins to the Arduino flasher. The data lines are connected straight through to the cart connector as you can see in the schematic I posted earlier but the address lines are not and not everything you send to the cart edge connector will come out of the other end of the MX1500 chip. At first it did but then the MX1500 chip somehow locked up idk. I have no clue what I am doing tbh.

Interesting and good to know that write commands are working, at least with 1-byte writes.
Aside from being slow, issuing 128 separate writes per sector will also reduce the chip's lifetime by factor 128.

Did you test your code with both MX29F1610 and MX29F1601 chips? Ie. are you sure that the "can write only 1 byte" problem occurs only for the Nintendo Power chips, or could be a general problem with your code?

For the "delay(7)": Erasing/writing flash memory does take some time, so you would need some similar delay also for normal 128-byte writes. Usually, the chip should output some "busy/ready" info, so you would wait for that info instead of using a hardcoded "delay(n)". Going by the MX29F1610 datasheet, data.bit7 should indicate ready. Or are you doing that kind of wait somewhere outside of the write function?

Datasheet also says that gaps between multiple byte writes may not exceed 30us. That might also cause lost writes in case the arduino is too slow, or in case it gets interrupted by IRQs.

NB. what is delay(7), seven microseconds, or seven milliseconds?

I started with the 29F032 flashrom and wrote an Arduino Mega based programmer for that, then continued to the 29F1610 and 29L3211 and finally tried to apply what I learned to the NP's 29F1601.
I'm a beginner when it comes to programming, hence working with Arduino.
Yes the delay is also needed with the 29F1610, but since I can write 128bytes per delay it's not that bad. The delay is in milliseconds (1/1000s), so it's quite long if you have to delay after every written byte.

Reading the status register while the flashrom is programming itself would be much much better, I tried that but couldn't get it to work so I kept the delay.

The next step would be to be able to program the flashrom inside the NP cart without the very tedious process of desoldering the flashroms.

I got an own nintendo power cart, too (thanks to skaman). And started some hardware tests today. Some first findings:

The thing initially didn't want to boot, but worked after a few attempts with inserting/removing the cartridge, maybe the contacts in my console were just a bit dirty. I am a bit surprised that it is working in my PAL console (with the PAL-CIC disabled in the console). I would have expected needing to disable the NTSC-CIC in the cartridge since it's passing some "ERROR" signal to the MX15001 chip... but apparently that signal doesn't protect the NTSC cart agaist being used in (modded) PAL consoles. Well, just fine.

Next surprise is that the boot menu music is quite moderate. After having listened the Satellaview and DSi bootmenu music themes, I was having the impression that Nintendo planned to create an army of labile teenagers running amok and to randomly shoot other people just because they are scared and distracted about the world that they are living in. But, for the Nintendo Power menu, the music is quite okay (just gets a bit boring when listening to it for about 30 minutes). Hmmm, maybe I was wrong and Nintendo never really intended to provoke amok and they are just tend to have a real/unreal bad taste in music. Anyways.

The Reset button is handled other as I would have expected: Within the menu, it does just restart the menu. But after selecting a game, it does restart the selected game. Only way to return to the menu seems to be switching power off/on? Can somebody confirm that? (just in case it happens only on my modded PAL console).

Reading the I/O area returns value 7Dh for addresses 00h:2400h..2407h (no matter if menu or game is being selected). Addresses 00h:2408h and up are open bus. And there are no mirrors in other banks (tested banks 01h, 10h, 20h, 80h, and they are all open bus).

Next, I've also had a look at the menu of the nintendo power gameboy version. One difference is that it's having some simple selftest mode, which is making a bit easier to get an idea what kind of commands are being used/supported. The used port [0120h] command numbers are 09h, 04h, 05h, 08h for whatever purpose, and 8xh and/or Cxh for game(x) selection. All commands seem to be terminated by [013Fh]=A5h. Command 09h should be prefixed by a dummy read from [0120h], and seems to require two fixed parameters: [0121h]=AAh, [0122h]=55h. The other commands don't use any parameters at all. The "decode data" selftest displays a 24bit value read from [0122h..0124h], and does then verify if [0122h..0124h] is A8h,00h,00h. The "menu sequence" selftest checks if [013Fh] is A5h.
The homebrew source code snippets for programming nintendo power gameboy carts are using command 09h and 04h, too. Plus commands 01h, 02h, 0Ah (also without parameters), plus command 0Fh (with 8bit data and some incomplete looking 16bit address). I am still wondering who has reverse-engineered those extra commands and how. Either somebody did have access to an official programming station - or somebody just randomly tried sending commands & parameters to see if any of them would pulse pins on the FLASH chip. Considering that most commands don't require any secret parameter values, that method should be actually working - without even needing any other equipment than a LED or volt-meter.

Going by the part number, the SNES chip seems to be a bit older than the gameboy chip. And it doesn't seem to require any equivalent to the gameboy's trailing [013Fh]=A5h write. So, the SNES chip might be even less complicated than the gameboy chip. At the moment, I am optimistic that it'll be cracked in next 24 hours...

"Within the menu, it does just restart the menu. But after selecting a game, it does restart the selected game. Only way to return to the menu seems to be switching power off/on?"

It does exactly the same on my Super Famicom. Also when in the menu you can hold X and it shows you where the game is stored and how much space it occupies by flashing the F and B symbols.

As for the GB NP cart it seems like the commands where found by doing some educated guesswork and using a lot of probes:

"Combination of numbers will become the astronomical number, but look at the behavior we will squeeze to guess the command format."(Translated by google from this source http://mootan.hg.to/fmgbx/)

Yeah, I've seen that photo. It's a bit hard to make sense of it. The stupid theory would be that the software for the blue cartreader did have nintendo power support included, and that the guy reverse engineered the software with a logic analyzer instead of disassembling the cart reader software directly. But that would be just stupid.

Other theory would be that the cartreader was just used for doing the tests on a PC instead of on a real gameboy. The connection is weird though. The nintendo power cart-edge seems to be on the left (=without direct connection to the cartreader on the right). Maybe there's an adaptor from left-to-right underneath of the cartridge, and with additional wires on the left for forwarding the cart-edge signals to the logic analyzer (not that one would need to analyze the cart edge signals that one is sending to the cart, since one should know what one is sending anyways; but it might be helpful to log the sent-commands alongsides with the cart-internal signals). Inside of the cartridge, most wires seem to go to the SRAM chip (makes sense since it has the biggest solder pads).

As far as I understand it, the NP cart plugs into some cheat device like a Blaze xploder or Action Replay

and through that it plugs into the blue Bung flash linker.
The cheat device is probably just used so he has better access to the NP cart since that way it's not hidden away inside the blue Bung flasher's cart slot.
Then he send commands from his pc through the Bung flasher to the cart edge and read the results if any on the sram chip inside the NP cart.

My guess is that they hooked it up to that device just as a PC interface to send arbitrary commands to the cart, then they have the probes set up to log the output result of the commands. Chances are, the SNES cart has an unlock sequence similar to the GB one, and you could try to bruteforce it by sending a single byte sequence to each address, and cycle through every address/data combination, then try a two-byte sequence, then three, and basically monitor the ROM /WE line. If you manage to get the /WE line to go low, then you've found the unlock sequence. However, as the poorly translated page says, the number of possibilities quickly becomes incredibly large. You could start with some commonly-used values to start though, such as 0x55, 0xA0, 0xAA, etc. as data values.

Oh, yes, the yellow Blaze thing looks like the gray case on the other photo.

Writing commands to the FLASH chip seems to be no issue, writing the chip ID commands works without problems, it does even seem to work without needing to send any of the special nintendo power commands (like those being sent in the menu). I've tried this:
Unlike as in the gameboy source snippets, the writes are done directly to cartridge memory space (rather than writing HH and LL and DD bytes to the MX15000x registers; though the SNES might support that indirect write method, too).
The MX29F16xx chips are having 16bit databus, hence the "word addresses" in the datasheet are meant to be multiplied by 2 for "byte addressing" (ie. word address 5555h would be AAAAh in byte addressing, with the SNES LOROM mapping, that'd be 01:AAAA, ie. the above "mov [far 018000h + 1555h*2]" opcode).

For programming the FLASH memory, the main issue would be probably finding a way to unlock the /WP pin (ideally by software, although doing it by soldering would be "easier").
The other issue would be getting access to the whole FLASH memory (writing to the LOROM space of a cartridge with MENU does probably allow to access only the mapped 512Kbytes) (a possible workaround might be overwriting the MENU's cart header by a "bigger" cart header, reset the cart, and hope that the MX150001 chip will see the new header and map the whole memory, so one could then write a bigger file, or rewrite the menu with multiple smaller files).

I've also tried issuing the commands from the menu software:

Don't know what CMD_09h is good for, maybe it's just needed as prefix for unlocking other CMD's (looks a bit like so in the gameboy menu).
CMD_06h seems to toggle port 2400h..2407h to return either eight 7Dh bytes, or bytes 2Ah,00h,2Ah,2Ah,03h,AAh,AAh,00h (it can be sent multiple times to toggle between the two responses). Whatever that's intended for.

Ah, and here's a summary of the different IDs (from datasheet's and from actual cartridge):

Tried the gameboy unlock stuff (commands 0Ah,04h,01h,02h). The SNES doesn't seem to require commands 0A,04,01h. The /WP pin is getting HIGH when just sending SECRET command 02h (preceeded by the OFFICIAL normal SNES bootmenu commands). Ie. this sequence:
Whoa, one must write 02h to 002400h. That's just... incredible ;- )

Testing some other random commands did also have some effects (mostly changing some of the 2A,00,2A,2A,03,AA,AA,00 response values):

Tried sending the FLASH write command. Doing it as described in datasheet (or as in sanni's 29F1610 source) doesn't work out for the 29F1601 chip. It's causing odd effects: Outputting weird status values on databus, even after trying to issue the "Read/Reset" command, so one is receiving those odd status values even on following "Read ID" commands.

So, I checked sanni's 29F1601 source code again... and, yes, writing the data byte twice is doing the trick: The chip is then outputting correct status values, and returns to normal state when issuing "Read/Reset".
Trying to write a different value didn't work as expected, the result got ANDed with the old value (I was thinking that the chip would automatically erase/rewrite the written page, which should works as so on modern FLASH chips, but the 29F1601 can apparently only change bits from 1 to 0).

Next, tried to write multiple bytes: Writing each byte twice didn't work, it caused only the first byte to be written. So write-twice is apparently terminating the write command. Writing all bytes (except last byte) once, and then writing the last byte twice seems to work okay. Then wait for status.bit7 to become set (in case of the arduino code, don't forget to switch to read-direction for status reads (read address can be probably anywhere, as long it's on the same FLASH chip; I used reading the address of first-written byte, or the last written-address should be fine, too), and remove all that delay(20) and delay(7) stuff).

---

Todo would be trying to find out how to access the whole FLASH memory. Or, well, maybe it's already fully accessible (I haven't yet tested if the the chip is booting up with/without memory being restricted to the 512Kbyte menu area).

And one thing that would be great is logging the traffic on the databus after switching from the menu to a game. That's something that can't be done on a SNES console (at least not without external extra hardware). But your arduino cart-readers should be quite optimal for doing that tests, somehow like so:
That would be great for seeing if/what values the chip is reading from FLASH memory.
Logging the state of the cart-edge /RESET pin alongsides with the databus values would be neat, too.
The "21MHz" is probably internally divided, so you'd probably see each value on several clock pulses.
The chip is probably doing that on initial power up, too (so you may need to issue LOW/HIGH pulses to "21MHz" pin after power-up, too).

Can the data bus be observed non-invasively by hooking a logic analyzer up to the clock port on the bottom of the Super NES? Or is the clock port driven only when the B address bus is also driven?

Amiga clock port like this: http://www.ianstedman.co.uk/Amiga/amiga ... _port.html ? I don't see too much relation between the 80pin/22pin Amiga Clock Ports and the 28pin EXT port on SNES.

For hooking the EXT port, nobody is having a connector for it, so one could only connect wires to the EXT port solder pads (which are quite well accessible, so the EXT port may be actually good for such stuff). It doesn't have a good clock signal (ideally the 21MHz master clock), so that would need to be picked up elsewhere (to get an idea when new data values are being output).

Anyways, sanni and skaman are already having fully working hardware attached to the nintendo power cartridge (except still needing to output the "21MHz" in slow-motion on one pin). So they would essentially need to switch the data direction to "input", and then just READ what is happening on the databus on each clock cycle. That should be the simpliest solution, and the data could be logged as desired (plain ASCII HEX values, or plain binary file) (logic analyzers could probably do that, too, but usually they are producing bitmap graphics with waveforms instead of raw data).

What I would have in mind, could look as so (showing input from /RESET pin as one digit, and input from DATA as two digits):
1 FF
0 03
0 07
0 A3
0 80
0 5C
0 7F
1 FF
1 FF
1 FF
Then one could see which values are read during /RESET=0, and search those values in the ROM-image, and probably guess the addresses where they are read from (=presumably from the menu's directory entry for overall mapping, and from the game's cart header for lorom/hirom detection).

Never could get the Nintendo Power or even any SA-1 game to work on my Arduino cart reader, skaman got them to work though, must be some hardware issue on my side. So we'll have to wait for him.

That doesn't mean much without the /OE and /WE signals. For all we know, that's just the ROM data being read by the console.

This is an expected behavior for any Flash/EPROM. Erasing sets all of the bits to 1, and programming can only set them to 0. In order to set a bit to a 1, you have to erase it, then reprogram the new value. So, by writing two different bytes to the same address, since you can't set any of the bits back to 1, you end up writing all of the 0's from each byte, aka ANDing them together.

Tried some more "commands":

Some odd effects happened only once (that might have been unintended/unstable effects for whatever reason).
Some commands might do something when adding whatever parameters (eg. as known for commands 09h and 06h).
There stable/interesting commands are:
- 80h..8Fh: RESET and map GAME0..15 (aka 80h=MENU)
- 02h,03h: Controls /WP pin
- 04h/05h: Force HIROM mapping (either ALL memory, or only MENU)
With the "HIROM:ALL" command (04h) it should be possible to write the whole FLASH memory, so programming cartridges should be solved; unless there are some hidden configuration bits required for different games.

With different mappings (MENU, GAME's, or special HIROM modes), Port 2400h..2407h return different values (this on a cart with MENU and one 3MByte LOROM game (FIGHTING ELEVEN) installed):

Port 2400h,2402h,2403h are always 2Ah.
Port 2401h.bit4-7 is the selected GAME number (or 0=MENU).
Port 2401h.bit2 is the /WP pin state.
Port 2404h..2407h are "strange values". The FFh's for the empty game slots would suggest that they are simply read somewhere from FLASH memory (either from the GAME memory, or from the DIRECTORY entries). For the other mappings, they are just "strange values", I can't find those values being stored anywhere in FLASH (at least not in continous 4-byte memory blocks, and they don't seem to match for separate bytes in the directory region).
Can somebody dump those values on other carts? Would be interesting if you are getting the same values.

Concerning hidden stuff, I have dumped the "sector protect" bytes for the MENU sectors, and for the first some sectors of the GAME.
The first sector (lorom banks 00h..03h) of the MENU returns C2h (which should mean "protected", although I can write to that sector). The other three MENU sectors, and all GAME sectors are returning 00h (which should mean "unprotected") (and yes, writing to those sectors does work, too).
So, those bytes are apparently having a different meaning as described in the MX29F1610A/B datasheet. So they might contain hidden info about game mapping. Or they are just garbage because the "write protect" feature isn't implemented in MX29F1601 chip, though then it would be odd that different "write protect" have different values.
When dumping those bytes on other cartridges, are you getting the same results, first sector C2h, other sectors zero?

I added your findings to my MX29F1601 Arduino flasher, so it now can flash the complete NP cart without desoldering the flashroms, it's also alot faster than before.

This allowed me to do a couple of tests and it seems that the only thing that boots without a menu are games/programs that are 512K in size and lorom, like Super Mario World, the 240p Test Suite homebrew and ofc the NP menu.
Games like Super Bomberman(512K, hirom) or Super Mario Allstars(2M, lorom) won't boot.
I also flashed the japanese versions of DKC3(4M hirom) and Fire Emblem Thracia(4M lorom) and they didn't boot either even though they were available for the NP cart and Markfrizb stated that his DKC3 dump was identical to the retail rom.
On the other hand I flashed back the original content of my NP cart and that worked flawlessly, but then again it had a bootable menu.

So there must be a permanent hirom all/lorom all switch that can be toggled and if it's not the NP cart will just boot the 512k lorom menu or any other 512k lorom rom. Maybe some configuration bits are saved in the carts SRAM?

I'll try to write the suggested databus logger next to see what is happening right after powering up the NP cart.

That would be great to see if/what kind of mapping info it's reading from FLASH (or SRAM) chips!

As far as I understood, mark has swapped FLASH chips with lorom/hirom games, viewtopic.php?p=131832#p131832 so, theoretically, all mapping info should be located in the FLASH chip. The best candidate for hidden mapping info might be the 32 "sector protect" bytes for the 128Kbyte memory blocks. Would be interesting to dump those bytes, especially if somebody has a cart with a 4Mbyte hirom game on it.

I've tested only writing to 2400h. The menu code is also writing to 2401h, so that should be writeable, too. Although, as one can see, the values writting to 2400h/2401h have no direct relation to the the values being returned when reading from 2400h/2401h, so it seems that there are read-only registers at 2400h/2401h, and separate write-only registers at 2400h/2401h. No idea if 2402h-2407h are also writeable.

What new menu and new games did you upload? If you've tried to create a custum menu with hand-edited directory entries, then you might have just screwed up that part - better would be dumping a working cart in HIROM:ALL mode to a 4Mbyte flash image, and then programming that image to another cart, in HIROM:ALL mode, too.
Btw. mind that the SNES memory map doesn't have FLASH/ROM in bank 7Eh-7Fh (ie. you can't access the whole hirom at 40h-7Fh), accessing the whole hirom should work in bank C0h-FFh.

On a blank cart, I would expect the menu being located in first 512K, and the remaining memory being FFh-filled. That, when using the HIROM:ALL mode for dumping the cart. If you are mapping game#0, or use the HIROM:MENU mode, then you would obviously see only the menu, repeated 8x aka mirrored throughout the whole memory space.

Currently, it does look as if there's some hidden mapping info required...

If it's in SRAM, then you could simply copy the SRAM image alongsides with the FLASH image from one cart to another. That would be easy and worth testing, though it'd be a pretty bad design as it would brick the cartridge as soon as the battery becomes empty.

If there's an EEPROM in the MX15001 chip, then one may need to send further stuff to port 2400h-2407h, which might be difficult: doing stuff like guessing how to enter the EEPROM programming sequence, and guessing which values being needed to be written to the EEPROM.

If it's in the FLASH chip, then the "sector protect" bytes would still seem like the best candidates to me. Dumping those bytes would be easy as they are documented in the official datasheet, and from my tests, the chip does actually allow to read those bytes, but without actually using them for write-protection, so it wouldn't be unlikely that they are misused as mapping flags. Just DUMP those bytes, and check if you get different values on different carts! Somewhat like so:

On my cart, the first byte would be C2h, followed by 00h-bytes.

I tried the SRAM theory, sadly it was a dead end. Even after I flashed both the SRAM and the complete 4MB dump of skaman's Fire Emblem NP cart to my former menu+DerbyStallion98 cart it didn't boot.

I also tried listening to the databus with the Arduino but I'm not sure if I'm doing it right.
To me it looks like the MX15001 chip is resetting the flash and then doing some other stuff and sometimes it then resets the flash a second time.

In case it matters, I removed the CIC and all clocks for this test, and just manually clocked the expclk pin with a pin from the arduino, maybe about 500-700khz 50% duty cycle or something like that.
And the NP cart is a working Menu+Derby Stallion 98.
Writing and reading the complete NP cart also works this way.



Somtimes it does the same but without second flash reset


"Hirom All" and "hirom menu" don't do any reset, it's just 0x2A all the time with them

Cool, many thanks! That values do actually make sense: They seem to be the standard FLASH read/reset commands (as you said), plus additional Satellaview-style custom extra FLASH commands for reading the per-game mapping info from the FLASH chip.
Arranging your four dumps next to each other:

The leading/ending 2Ah/7Dh values seem to be just read from Port 2400h (assuming that you are still outputting address 2400h on address bus, as a relict from the preceeding Port 2400h game selection write) (and assuming that you have /OE switched LOW for some reason).
The AAh,55h,F0h values are just resetting the FLASH chip to read mode.
The 38h,D0h,71h, and 72h,75h values are custom FLASH commands, exactly same as used for Satelleview FLASH cart chip detection (though in this case they seem to be used for reading mapping info, not for chip detection).
The various FFh-bytes are probably just HighZ (at least most of them) occuring for a short moment when neither /OE nor /WE is output to the FLASH chip (yesterday you had posted a "dirtier" dump that showed each value repeated several times, and the FFh's were repeated only 2 times, unlike as the other values which occurred repeated 6-8 times). Looking at the above table, it does look as if the FFh/HighZ's do occur after READing from FLASH chip, so they do help on guessing the Read/Write-direction of the separate bytes.
The last FFh byte might be just another HighZ... or, if occurs for a longer duration, then it would be probably a FFh value written to terminate the chip-info mode (as done by satellaview).
The 88h byte being read after the writing 38h,D0h,71h seems to be just a status byte with bit7=ready, the Satellaview bios is reading that kind of status value in that place, too.
The remaining four bytes are supposedly mapping info being read from the chip, and then copied to port 2404h-2407h.

The missing two bytes in the second dump: That looks as if something went wrong, either your dumping software missed the 55h,F0h bytes, or the MX150001 chip somehow failed to output those bytes; maybe related to absent CIC. Anyways, just let's ignore that.
The missing seven bytes in the fourth dump: As there's no GAME2 on that cart, two things could have happened: The chip did output four FFh bytes (plus four HighZ bytes) in that case you should see about thirty-two repeated FFh's. Or the chip did output only one FFh byte, and the MX150001 did treat that as "no game" and aborted reading the other bytes.

For the address bus values, the AAh,55h,F0h values are obviously written to standard FLASH addresses (AAAAh and 5554h). The 38h,D0h,71h, and 72h,75h bytes are probably just written to FLASH address 0000h (the satellaview bios is doing it that way), the 88h ready byte is probably read from address 0002h (also as done by satellaview), and the four mapping bytes are probably read somewhere from FF00h..FFxxh (also as done by satellaview, but in this case using different addresses based on the preceeding port 2400h game selection).

Next steps should be:
Trying to read the mapping info manually from the FLASH chips.
Somehow "decrypt" those values & figure out which bits do affect the ROM/SRAM mapping base/size and lorom/hirom mode. For that purpose, it would be helpful to collect mapping bytes from different nintendo power carts.
And try to erase/rewrite the mapping bytes via whatever FLASH commands, which may require some guessing or brute forcing. Or, as skaman asked if port 2404h-2407h are write-able: That might be also worth trying. If it works then one could completely bypass the hidden mapping bytes, and just use a custom menu which is manually applying the mapping based on the directory and cart-header's (instead of using the [002400h]=8xh game selection).

Tried to write port 2401h..2407h: It didn't change any values read from 2400h..2407h, so that ports aren't writeable (or writing works only indirectly in form of command parameters, as done with port 2401h during initialization).

And, tried dumping the hidden memory of my menu+fighting eleven cart, that worked well:
The bytes at even addresses are the values for port 2404h..2407h (eg. 03,AA,AA,00 for menu). Confusingly there are further values at odd addresses (eg. 11,50,98,10 for menu). Going by sanni's databus dump that values aren't used during game selection, so they seem to be just unused garbage... unless they are checked on power-up, or are used internally by the FLASH chip for whatever purpose.
The data repeats every 100h bytes. The satellaview uses address 0FFxxh, but one could as well read anywhere from 000xxh to 1FFxxh. Assuming that the whole 100h bytes are writeable, then the whole mapping info for ALL games will be probably stored in the first chip, and the other 100h bytes in second chip would be always FFh-filled (apart from those 55h/00h values seen in above dump, which might be some chip-testing relicts or so).

The dumping function looks as so:
For the second chip use address E0xxxxh instead C0xxxxh. Switch to HIROM:ALL mode before using above function.

Wow so much info, thank you, I read through it three times already and am still amazed. This is one very interesting cartridge.

Got some more mapping bytes from skaman:
There are always 8 bytes at odd addresses at C0FF01..0F, interleaved with the mapping entries 0 and 1 (though no matter if the cart uses 1, 2, or 3 mapping entries). The 'odd' bytes are always in BCD range, probably some serial number, apart from the first two bytes, it seems to be just a date/time stamp, ie. formatted as 11-xx-YY-MM-DD-HH-MM-SS.

Some carts have extra 'garbage' at C0FF7F and E0FF80..BF.

And the actual mapping info, might be as so:

Port 2404h = Size:
Bit0-1 SRAM Size (0=2K, 1=8K, 2=32K, 3=None) ;ie. 2K SHL (N*2)
Bit2-4 ROM Size (0=512K, 2=1.5M, 5=3M, 7=4M) ;ie. 512K*(N+1)
Bit5 Zero (maybe MSB of ROM Size for carts with three FLASH chips) (set for HIROM:ALL)
Bit6-7 Mode (0=Lorom, 1=Hirom, 2=Forced HIROM:MENU, 3=Forced HIROM:ALL)

Port 2407h = Base:
Bit0-3 SRAM Base in 2K units
Bit4-6 ROM Base in 512K units
Bit7 Zero (maybe MSB of ROM Base for carts with three FLASH chips) (set when forcing HIROM:MENU on skaman's blank cart)
Would need more dumps to confirm that (especially carts with multiple games on them).
Edit: below DKC3 issue was due to bad dump
The DKC3 cart is already somewhat blowing that theory: It's having the "ROM Base" set to 1 (although not having a menu), so the game's cart header would be at FLASH offset 08FFC0h rather than 00FFC0h, which looks wrong... unless the cart is really programmed in that fashion, that could be verified by dumping it in HIROM:ALL mode.

Port 2405h,2406h = Whatever:
AA,AA ;Menu (512Kbyte Lorom)
29,4A ;Fighting Eleven (3072Kbyte Lorom, 8Kbyte SRAM)
29,4A ;Fire Emblem Thracia 776 (4Mbyte Lorom, 32Kbyte SRAM)
29,4A ;Derby Stallion '98 (3Mbyte Lorom, 32Kbyte SRAM)
29,4A ;Super Mario World (512Kbyte Lorom, 2Kbyte SRAM)
29,4A ;Torneco no Daibouken (1.5Mbyte Lorom, 8Kbyte SRAM)
71,B5 ;Donkey Kong Country 3 (4Mbyte Hirom, 2Kbyte SRAM)
61,A5 ;Mother 2 (3Mbyte Hirom, 8Kbyte SRAM)
61,A5 ;(when forcing HIROM:ALL)
D5,7F ;(when forcing HIROM:MENU)
8A,8A ;(when forcing HIROM:MENU on skaman's blank cart)
That stuff looks kinda meaningless. For Lorom (except menu) it's always 29,4A. And for Hirom it's either 61,A5 or 71,B5. Maybe more dumps will reveal some purpose, like some extra SRAM-disable flag, or selecting which bank(s) the ROM/SRAM is mapped/mirrored in the SNES memory space or so.

So without including the sector protect bytes of the flash chips, Nintendo Power cart dumps are incomplete. Yet with the traditional ROM format, there's no place to put this data.

We could probably apply traditional "LoROM / HiROM detection" heuristics every 512KiB of ROM to generate valid information ourselves dynamically, but it wouldn't be accurate nor complete as we don't know exactly what every bit is for.

One could also claim a similar issue with BS-X Satellaview packs, but there's really only two types of values there: one for FlashROM (all the same size), one for MaskROM (only three such packs.)

Given the extreme difficulty and low utility in dumping these (NP-only games are already extracted to standard 'ROMs', eg Metal Slader Glory), there's not much point in worrying about it, I suppose.

But if there were complete images (with sector protect info) out in the wild, I'd be up for emulating this.

That aren't sector protect bytes. It's read via different custom flash commands, not via the official "get sector protect" command.

Oh, you mentioned sector protect earlier. Then stuff about Satellaview having the same thing by a different name. It's very difficult to follow this thread.

So in that case, there are two special hidden areas that aren't part of the main flash memory pool. And so far, only one of them seems to be important.

At any rate, it's hidden data that's not part of the standard memory dump of a flash cart. So the question is, how would one go about including that data with NP images? Mostly a theoretical exercise because I don't see anyone doing this, or anyone besides you and maybe me emulating this at all.

More mapping stuff. Rest of the carts that I have available right now. I should be getting a few more carts with HiROM games coming within the next week or so.



I redumped DKC3 and got different data. Maybe this makes more sense?

Menu + Umi no Nushi Tsuri(LoROM Sram: 64 Kb Size: 16 Mb) + Otogiriso(LoROM Sram: 64 Kb Size: 8 Mb)




Menu + Harvest Moon(LoROM Sram: 64 Kb Size: 16 Mb) + Umi no Nushi Tsuri 2 (LoRom Sram 64Kb Size: 16Mb)




Menu + Super Mario World(LoROM Sram: 64 Kb Size: 24 Mb) + Doraemon 4(LoROM Sram: 0 Kb Size: 12 Mb) + Dragon Slayer II (HiROM Sram: 64 Kb Size: 12 Mb)

Thanks for the new dumps! As far as I can see, all bytes are matching up with the theories on date/time serial number, and port 2404h-2407h meanings.
New findings are that the "xx" in the "11-xx-YY-MM-DD-HH-MM-SS" can be non-BCD (spotted in the Super Puyo Puyo cart). And the values for port 2405h/2406h are always one of these three sets, apparently related to SRAM mapping:
29,4A for Lorom with SRAM
61,A5 for Hirom with SRAM
AA,AA for Lorom/Hirom without SRAM
The redumped DKC3 values are making more sense (the old dump had bit4 set in all bytes).

Here's a copy of the new values from skaman and sanni (with titles, mapping, and ROM/SRAM sizes (as listed at superfamicom.org) added next to each entry):

More Satellaview stuff...

First of, writing "last-byte-twice" is also done in Satellaview BIOS, so that stuff isn't totally uncommon (although it doesn't seem to be documented anywhere in official Macronix datasheets for normal FLASH chip).

Then I came accross an uncommon FLASH command in Satellaview BIOS, as far as I remember, it's been documented as "upload status bits" in some datasheet. So I just checked back for more info... I've still no clue what that "upload status bits" command is about - but alongsides I came accross some documents talking about "vendor info" and "page buffer" commands, which seem to be resembling the nintendo power hidden data commands:
http://wiki.superfamicom.org/snes/show/Data+Pack+Commands - satellaview info (see "vendor info")
[url]http://www.mw-elisra.com/MICROEL-ELISRA/pdf/Flash/MEF1M32[12V-Reg].pdf[/url] - some datasheet (see "page buffer")
http://www.donat.org/ti92/016suht1.pdf - some other datasheet (see "page buffer" on page 15)

Haven't yet tried, but with that info, it might be easy to figure out how to rewrite the mapping data without too much guessing.
The "page buffers" seem to be temporary RAM (unlike as the hidden FLASH/EEPROM in nintendo power carts), but the overall command descriptions might be still helpful to understand what's going on.

EDIT: Clicking the second link doesn't work out due to the square brackets in "[12V-Reg]", just copy the link manually:
mw-elisra.com/MICROEL-ELISRA/pdf/Flash/MEF1M32[12V-Reg].pdf

Just updated the Satellaview Flash commands wiki page mentioning ikari_01 and that they were tested on real hardware.

I figured it's good information. (It's not like I was asked about it.)

I guess for Nintendo Power carts, there was no reason to not use the same kind of thing.

Is there more info available on how to get the Block Lock Status Bit in the Page Status Register from 0 (Locked for Erase/Write) to 1(Unlocked for Erase/Write) with the Satellaview cart's flash?
Is the register itself writable or is there a special command that does unlock the protection? Like "0x77D0 = Lock Page" just the other way around.

Mind that the Satellaview supports 4 different FLASH types (probably from different manufacturers). See here for details,
http://problemkaputt.de/fullsnes.htm#sn ... ontype1234

The Nintendo Power Macronix chips seem to be resembling Satellaview Type 2, so many of the Satellaview Type 1/3/4 commands are probably unsupported on Nintendo Power carts.

But, at least, commands 38h,D0h,71h,72h,75h should be supported on all types. Or more or less supported: I've tried to use the "toggle" command (72h) on Nintendo Power, and it doesn't actually seem to toggle anything (nethertheless it seems to be required to write that command number).

Either I did something wrong, or the Macronix chip is only mimmicking Sharp-like commands, without actually fully implementing them the way as described in Sharp datasheets.

I've also tried writing via command 74h, but it didn't work on my Nintendo Power cart (although it sounds as if it worked for ikari_01 on Satellaview Type 1/3/4 carts).

> Mind that the Satellaview supports 4 different FLASH types (probably from different manufacturers)

One interesting thing is that I have around 10 BS-X packs from Matthew Callis. Every single one is the exact same type (forget which one it was, though x.x)

Also never seen any different sizes: they're all 8mbit.

Pretty sure that the Town BIOS was written to allow for the option of releasing different capacities / flash types in the future, but in the real world ... you only ever have to worry about one type of cart.

xFD0-xFD3 in the header of EACH program is the Allocation Block Flags. 1 bit = 1M. There are 32 bits of those flags.
32M was supported but instead nope, just 8M.

Not to mention the japanese Satellaview patents was talking about Hard Drive support via the Satellaview addon... (Yes, that's what the EXT port was supposed to be used for)

Everyone should look at these patents. It's filled with very technical tidbits.

That are japanese patents (not english)? Then, no thanks.
Though, english patents are so hard to read that the language won't matter too much ;- )

---

I am trying to sort out the extra flash commands. Going by the datasheets, the sharp/elisra chips are having two "page buffers", intended for faster writing, ie. allow the cpu to write to one buffer at the same time when the chip is writing the other buffer to actual FLASH memory.
Normally, that would be probably done via E0,lo,hi,<data bytes> (write to page buffer) followed by 0C,lo,hi (forward page buffer to FLASH), probably to be followed by whatever status read (to see if the forwarding has finished).
Unfortunately, the datasheets are real crap and don't explain that stuff very well. Reading between the lines, it sounds as if the byte count (the "lo,hi" bytes) should contain the number of bytes minus 1 (it doesn't exactly say that anywhere, but it says that 0000h means 1 byte, and says that the count must be in range 0000h..00FFh even when writing 256 bytes, hence it sounds like count=num_bytes-1).
The other page buffer commands (72h, 74h, 75h) were probably mainly intended for testing purposes.

The customized nintendo chips are adding one extra command (38h, plus D0h for confirmation), that seems to transfer the hidden sector to page buffer (so it could be read via command 75h), on a "real" Sharp chip this would probably take some clock cycles (hence the status=ready check after 38h,D0h), the Macronix chips seem to be only mimmicking the transfer (hence instantly seeing status=ready).
And supposedly there's also some unknown command for directly writing to the hidden sector, or maybe more likely, for forwarding the page buffer to the hidden sector. If 38h,D0h is reading, then the opposite direction might be 39h,D0h or 28h,D0h or the like. Or if 0C,lo,hi is writing to normal flash, then something like 3C,lo,hi might be writing to hidden flash.
But considering that Macronix chips seem to be only mimmicking those commands, it doesn't look to inviting to guess that stuff on Macronix chips, without first testing how it's working on actual Sharp chips.

For the satellaview, the only photo of the hardware appears to be this poor picture: http://www.dforce3000.de/index.php?p=fdsingle&uid=412 which doesn't really tell if it's a Sharp chip or not. The only interesting detail is the PCB name which looks like BSMC-AF-01 or so (=clearly different as BSMC-CR-01, which is also rumored to exist).

And the satellaview wiki page: it looks like some mixup of actual hardware tests on some unspecified chip type, plus info extracted from official datasheets (though renaming the "page buffer" to "vendor info" for some weird reason). The most interesting (=confusing) part is this: 0x0807 = copy vendor information block to current page which isn't mentioned in any known datasheets (and doesn't seem to be used in any existing software either). The 'current page' might be referring to the write address (ie. maybe meant to mean to write one of the bytes to Cxxxxxh rather than C00000h). If so, then it would be similar to the official 0C,lo,hi command - maybe using only an 8bit byte count instead of the 16bit lo,hi values - so 08,07 could mean to write "07+1" bytes from page buffer to FLASH.
Or whatever, hard to tell without having a satellaview flashcart for testing.

> 32M was supported but instead nope, just 8M.

Right. A talented engineer could make a 32M pack, and we can easily make them for emulators, but no official ones exist. Same goes for the other two types of flash that the BS-X BIOS supported.

> Not to mention the japanese Satellaview patents was talking about Hard Drive support via the Satellaview addon... (Yes, that's what the EXT port was supposed to be used for)

Shit! Just out of the blue, just like that!

I've been trying forever to figure out what that EXT port was for. My best guess was that it was for developers.

That makes a lot of sense, given the recessed area that's in that compartment. Would still be a tiny hard drive, but since everything Nintendo is proprietary, that's no problem.

I wonder if the BS-X Town cart has support for the protocol that thing speaks, or if they were just planning to release a BS-X Town 2.0 cart with the hard drive.

I've tried tracing the continuity on the pins, but all I see are Vcc and GND being passed between it and the 28-pin connector. So it obviously has its own register set.

Given there's no way to execute code off it directly, one would imagine it'd be a "long-term storage" situation where it had to use the 4mbit PSRAM to load games back. So if BS-X Town supported it, it wouldn't work with 8mbit games. Of course, a 2.0 cart could have had 8mbit PSRAM.

> clearly different as BSMC-CR-01, which is also rumored to exist

BSMC-CR-01 most certainly exists. I have three of them. They're MaskROM versions that don't respond to the flash commands like the vendor readout mode at all.

This incompatibility actually makes it impossible for the Satellaview service to have offered downloadable character data for Same Game, and possibly for SD Gundam G-Next as well (haven't debugged the code in the latter.) A bit of a shame, because the Tengai Makyou pack is psychotically rare (I've only ever seen two for sale, they go for $400+). Of course the MaskROM would still be expensive, but having a few dozen FlashROM downloads floating around would have allowed more people to enjoy it.

Unless the 8 Mbit game is reprogrammed to load more data at runtime through the expansion port. Case in point: Nintendo changed the Super Mario Bros. engine to load extra 4-world blocks of level data from the disk drive at various points in Super Mario Bros. 2. It's not quite as big as the 6 Mbit in the Sega CD, but hard disks are still a lot faster than the 1x CD-ROM drives of the time.

Uh, the imaginary satellaview harddisk is getting a bit offtopic. Stuff that would be more interesting would be:

1) getting a photo of the satellaview PCB and FLASH chip and eventually finding a matching datasheet for it
2) dumping the values stored in the satellaview FLASH chip's custom/extra area & finding out which capacity it has
3) finding out how to use the page buffer feature to write to the normal satellaview FLASH memory
4) finding out how if it's also possible to write to the custom/extra satellaview memory

Step 4 might be impossible if the extra satellaview memory is read-only, but if it would work, then it would be worth trying the same thing on nintendo power carts. If Step 2 would reveal a hidden serial number in the extra memory, then that would imply that Step 4 would be also possibly. Step 1-3 should be relative simple, but I doubt that such stuff will happen in next some years.

Best other approach might be writing variations of the known Macronix/Sharp commands to the nintendo power flash chips, hoping that some command will write or erase the mapping data. I've tried some hundreds of command variations, but without luck yet (that is, a handful of variantions with command/bytes ranging from 0 to 255).

I worked off this datasheet writing the superfamicom wiki page: http://www.datasheetcatalog.com/datashe ... T-70.shtml
It's the "generic" equivalent of the Nintendo part, unfortunately lacking the 38 D0 command but it becomes apparent that these work with "page buffers". Basically you copy the "vendor info" block into the currently selected (cmd 0x72) page buffer, then write to the page buffer using cmd 0x74. However I haven't found a way to write the page buffer back to the vendor info block.

Some random information I came across while googling:

- the official Nintendo Game Boy Dev/Prototype Carts also had Sharp flash memory(Datasheet, Useless but nice to look at decap)

Source: http://atariage.com/forums/topic/170272 ... boy-proto/

- Here is the source code for some homebrew GB Flashcart writer that supports them, just search for "LH28F800SU" and "LH28F032": http://www.reinerziegler.de/download/Readpnew.c and http://www.reinerziegler.de/download/re ... 27.tar.bz2
For example some interesting parts:There is also a Gameboy Dev cart in the code with Intel DA28F320 chips (datasheet) that uses 0xe8 to write to the buffer and 0xd0 to write the buffer to the flash.

- In the LH28F800SU datasheet it states "Refer to the LH28F800SU User’s Manual", so there seems to be a second document that actually explains how things work.

Good findings. The source code's byte_count value (FF,00) for 256 byte writes does somewhat confirm that Sharp's byte_count is meant to be "number of bytes minus 1".

And here are the two photos compared, FLASH chips in Gameboy dev cart vs Satellaview FLASH cart,

even without legible text on the second photo, the chip layout's are looking identical, so it' should be about 99% sure that the satellaview carts have used whatever Sharp chips (for knowing the exact part number, one would need a screwdriver & one of those carts).

I have a couple memory packs lying around, maybe I can take some pics later.

That would be great.

More random google finds:
- after sending the 128bytes to the MX29F1610 you are supposed to wait 100us according to this application note http://www.prom-electric.ru/data/upload ... 10-app.pdf
- on page 31 of this MX29GL128 datasheet there is an example on how macronix handles writes to the page buffer, maybe they used similar commands for the Nintendo Power cart's flash? http://www.zlgmcu.com/mxic/pdf/NOR_Flas ... _DS_EN.pdf

Well, whaddayaknow.
This thing responds to a lot more commands that given in the datasheet so there seems to be undocumented stuff, maybe information about that is given in the "User's Manual" which seems to be unavailable.
Then again, -Z1 is a strange speed rating... judging from the LH28F004SUT-Z1 datasheet it just seems to mean 100ns though.

Nice, the LH28F004SUT-Z1 datasheet even has some flow charts that are missing from the LH28F800's datasheet.

Yes, that's mentioned in the regular MX29F1610 datasheet, too. It's starting writing if you don't send further bytes for min 30us .. max 100us (the tolerance is probably due to not having precision oscillators in the chip).
However, the nintendo-specific chips are starting writing when writing the last byte twice, so you don't need the 30-100us delay (as a side effect, nintendo's macronix chips are a bit faster (and less timing-critical) than normal macronix chips).


I thought the normal macronix chips were internally having a 128-byte page buffer for the normal page/byte write command, too. But this datasheet does actually seem to come up with extra page buffer commands. The datasheet is much newer, and it's using normal macronix-style addresses (ie. the 555 stuff) instead of the sharp-style addresses used in nintendo power carts, so no idea if any of the extra commands in that newer datasheet are working on older nintendo power carts...
Interestingly, the MX29GL128 datasheet is mentioning a 128-word extra sector for "security", so the concept of adding a hidden sector doesn't seem to be restricted solely to customized nintendo chips.


Cool, thanks for the photo! The BSMC-AF-01 PCB's text layer is a little different as on the d4s photo. And the FLASH is a Sharp LH28F800SUT-ZI or LH28F800SUT-Z1. The suffix looks more like -ZI to me (though the "1" in the datecode might be just using a different font). But -Z1 would also make sense in relation to the LH28F004SUT-Z1 datasheet (which is for a smaller 4Mbit chip, not the 8Mbit chip in nintendo power carts, and not containing info about the hidden sector).


There are even a lot more commands? I knew only about the 38,D0 one, and the 08,07 one that you've mentioned on the wiki page (btw. does that command write the whole 256 bytes to some flash address, or could 07 be the byte-count, so it would only write 7 or 7+1 bytes?)

Before you try to overwrite the hidden sector, could you dump it? Using the same procedure as in the satellaview bios, but reading the whole 256 bytes instead of the just the handful of bytes used by the bios - would be interesting if there's more data stored in there (and if it's a Type 1 or Type 3 or Type 4 chip).

Here's the mapping details for my latest batch of NP carts:

So I finally ran thru all the 4-byte sequences looking for changes in the hidden mapping area of the flash chip. After a week of searching sequences, I found that the chip only responds to the sequence of 0x38, 0xD0, 0x71 when it comes to the hidden area. I ran all 2, 3, 4 byte sequences then also added the 0x38, 0xD0 and 0x38, 0xD0, 0x71 before the 2-byte and 3-byte sequences. I quit looking after that and there's no way that I'm running another 4-byte (or greater) search. Either my search code is wrong or there's something else that needs to be done to change the mapping.

I decided to search the port commands. I ran all the commands to 0x2400 and found something interesting:
CMD:20: 2A 0 2A 2A FE 61 A5 0
CMD:21: 2A 8 2A 2A FE 61 A5 0
..
CMD:40: 2A 8 2A 2A FE 61 A5 0
CMD:41: 2A 8 2A 2A FE 61 A5 0
CMD:42: 2A 8 2A 2A FE 61 A5 0
CMD:43: 2A 8 2A 2A FE 61 A5 0
CMD:44: 2A 8 2A 2A FE 61 A5 0
CMD:45: 2A 8 2A 2A FE 61 A5 0
CMD:46: 2A 8 2A 2A FE 61 A5 0
CMD:47: 2A 8 2A 2A FE 61 A5 0
CMD:48: 2A 8 2A 2A FE 61 A5 0
CMD:49: 2A 8 2A 2A FE 61 A5 0
CMD:4A: 2A 8 2A 2A FE 61 A5 0
CMD:4B: 2A 8 2A 2A FE 61 A5 0
CMD:4C: 2A 8 2A 2A FE 61 A5 0
CMD:4D: 2A 8 2A 2A FE 61 A5 0
CMD:4E: 2A 8 2A 2A FE 61 A5 0
CMD:4F: 2A 8 2A 2A FE 61 A5 0

These commands show that bit 3 for Port 0x2401 is toggled. This appears to be something new. CMD 0x20 turns off bit 3, CMD 0x21 turns on bit 3. You can even use CMD 0x21 with CMD 0x02 and the resulting Port 2401 output will be 0x0C. The 0x40-4F commands are the same number of entries as the 0x80-0x8F game selection commands.

The other command that returns weird data is CMD 0xFF. I get varied results after sending that command - generally something along the lines of:
CMD:FF: 2A E0 2A 2A 8F 8F 9F 9F
or
CMD:FF: 2A F0 2A 2A 8F 8F 8F 9F
or
CMD:FF: 2A F0 2A 2A 8F 8F 9F 9F

I'll have to do more testing.

Hi Everyone,

I know this is a little off topic but still Nintendo Power cart related. I'm trying to re-flash my GB NP cart but there is very little info on the protocols. I've thoroughly read through all that has been posted regarding the MX flash IC's and it is very good work you have all done on reversing and discovering the non-standard flash features.

The GB cart also holds ROM information outside of the standard flash ROM space. I've probed the WR and CE lines while requesting a read of this data and there is no activity so I don't believe the data is stored in the Flash IC at all.

Perhaps it is in the SRAM, or even inside the custom controller IC. More effort will need to be put into this to get to the bottom of it.

My biggest issue is the flash protocol used in the MX chips. I cannot get any response from the chip when trying with all the standard flash protocols, Macronix, Sharp, Intel, even the SNES flash IC instruction set seems to be ignored.

I know the data bus is direct from the edge connector to the Flash IC, I know that my instructions are passing through to the IC and the magic sequence is working as I get bus activity on the chip when issuing my commands. It seems it is the commands that are not correct.

Has anyone had experience with this particular flash IC? or could possibly point me in the direction of a datasheet?

Thanks!

Edit-

I've spent the last couple of hours disassembling Mootan's program to try find the protocol. Not having GiveIO.sys, or a compatible system to install it, or the supported cart interface has slowed me down a little. I have not returned empty handed though, here is what I have found:

There are 7 functions written to communicate with the NP cart. I'll list them as discovered in the binary.

1:
[0120] <- 0F
[0125] <- Address Hi
[0126] <- Address Lo
[0127] <- Databyte
[013F] <- A5

2:
[0120] <- 09
[0121] <- AA
[0122] <- 55
[013F] <- A5

3:
[0120] <- 08
[013F] <- A5

4:
[0120] <- 0A
[0125] <- 62
[0126] <- 04
[0127] <- 00
[013F] <- A5
[0120] <- 01
[013F] <- A5
[0120] <- 02
[013F] <- A5

5:
[0120] <- 10
[013F] <- A5
[0121] <- 01
Following Data bytes are passed through to flash using Function #1
5555 <- AA
2AAA <- 55
5555 <- Databyte (passed to the function as variable)

6:
[0120] <- (0xC0 & Databyte) passed to function as variable
[013F] <- A5

7:
Following Data bytes are passed through Function #1
4555 <- AA
42AA <- 55
4555 <- Databyte (passed to the function as a variable)

From the work Nitro has done, and some logic and trial and error on my Joey, Function 1 is a raw write access function to the Flash IC. Before you can issue Function 1, you need to execute function 2 & 4.

Function 3 returns the cart back to a read only mode.

Function 4 differs slightly to what Nitro has documented as does 1.

Function 5 seems like a generic flash preamble

Function 6 swaps out ROM blocks within the flash. This is how the custom IC changes games.

Function 7, similar to 5 except is write to the high bank of the GB cart, maybe used for writing to sectors other than bank 0??

Still more work to do, like find out why I can't get a response from my Flash IC... At first I though maybe the CE line must remain active the whole command sequence but Mootan doesn't seem to adhere to that logic...

And where is the ROM data stored if not the Flash??!?!?

Hopefully hear back from Nitro soon.

One mystery solved.

I coded a bootstrap program on the gameboy, hot-swapped carts to the NP then tried the usual 5555/2AAA flash instruction set. Success!

Now out with the logic analyser to compare pulse timing with the gameboy vs my Joey. Maybe 480ns WR pulses are too quick for the MX flash IC.

Once I get my cart interface debugged, I can find where they hide the magic info.

Not sure if it helps but on the SNES NP cart I do the WR pulses like so:


Ofc since the Arduino is kinda slow, it will end up to be more than 375ns.

And writing I do like this

Good findings! I didn't have tried CMD 20h/21h. But tested them today, setting/clearing bit3 happens here, too. And the effect... it looks as if FLASH reads are disabled when bit3=1 (on a SNES, I am getting open-bus values when reading the ROM area, ie. retrieving the MSB of the ROM address as open bus data value).

CMD 40h-4Fh are just aren't doing anything special? Ah, or is their "special" effect that they don't reset the chip to return 7Dh bytes when reading port 2400h-2407h (unlike most other CMDs which do have that "reset to 7Dh" effect)?

CMD FFh doesn't seem to work for me. It doesn't change the port 2400h-2407h values, and also doesn't issue a RESET. Maybe it works only in relation to other values being sent prior to CMD FFh? And you are sure that you've used CMD FFh, aren't you? Asking because CMD 00h would have roughly the same effect as what've described (setting the 8 registers to "2A E0 2A 2A FF FF FF FF" in my cart).
The 'variable' bytes that you are receiving (E0 or F0, and 8F and 9F) are looking like some unstable/uninitialized stuff. Are there any cases where you are always getting the SAME values? Like always getting the same values after power-up? Or getting different values only when using different cartridges?

That's about same as in the "appendix" on the http://blog.gg8.se/wordpress/2013/02/25 ... and-tears/ page (apart from the extra "[0120]=02" on that page). The thing that is really confusing me is how one could address an 8Mbit(?) chip with two address bytes - unless the address is meant to be an 14bit offset within the gameboy's current 16K-byte bank?

Some other stuff that would be interesting about the gameboy FLASH chip would be if it's requiring that "write-last-byte-twice" thing, too. And just for curiosity, which manufacturer/device IDs it's having. And of course, if it's returning hidden data when sending those "38h, D0h, 71h..." values, too.

Addressing is done via the MBC, set the bank then a write to $4000 = Bank offset + $0000, $4001 = Bank Offset + $0001 etc...

Not sure if Bank0 is bank zero or 1 on this MBC, need to confirm that too.

ID's are $C2 and $83.

I'll get back to you with the hidden data string.

Yes, when I turn bit3 on, I only get FFs back from the flash (at least in the mapping area - that's where I've been looking for changes).

I can't tell if 0x40-0x4F are doing anything. You're right that I noticed them because they return values other than 0x7D on the ports. I've had times where CMDs 0x44-0x47 give back other values (sequences of 0xF0 and 0x7D) than the normal 2A type sequence. I was hammering commands to 0x2400 when I got those other values so I need to go back and try to isolate what caused those changes to see if there's any significance.

For CMD 0xFF, I get those strange values when incrementing up from CMD 0x0. So the preceding CMD is 0xFE. Must be an invalid command?

I've basically been using two different carts for testing. The Blank cartridge and the 2nd Derby 98 cart. If I screw those carts up, then there's really no loss. Results have been the same between the carts.

The mystery is now more... Mysterious!

We know flash writing is exclusively via Function 1. We also know that the Flash I/O bus is tied directly to the cart bus. The question now becomes, how can both the final byte of Function 1 (0xA5) be written AND the controller IC take control of the Flash I/O bus? Is there an internal clock/timer that waits for x uS then issues the command, expecting the game boy to be done with the bus?

Does the controller issue the flash command on the rising edge of WR when the game boy releases control of the cart bus?

A quick probe with the logic analyser will get to the bottom of it, but at least now I know why my interface isn't communicating with the flash like the game boy does...

Edit -

After much tweaking of my code it appears the controller IC waits 1 time constant as determined by an external R/C network - from the rising edge of WR to when the Flash command is issued. I'll find the exact number when I get home. Now that's sorted I can talk to the Flash IC from the PC.

Do you think the SNES cart works on a similar principal?

Next up, get to the bottom of this un-mapped ROM info. I'm hesitant in erasing the cart as I've read (Mootans site) that a chip erase also erases the ROM info as well as a serial number. As this is an original cart I'd like to at least note the data before it's gone forever!

No reply with instruction 71,38 or D0

I'll write some code to cycle through them all. 70, 90, F0 are all valid flash commands. I think the data on the GB cart is stored in SRAM, only half of it is accessible via the game boy.

To get the magic ROM data you talk only with the controller IC, not the flash. And initial probes don't show any WR activity when getting the data. WR between flash and SRAM are linked. I'll monitor SRAM CE + OE when issuing the request. If it's stored in there I'll need to find the controller command to modify it.

I might dig through Mootans program again to see if I missed anything.

Ok, got some interesting results fooling around with flash commands.

I was trying different commands for the flash command sequence third data cycle. The flash chip seems to respond to a couple undocumented commands.

Data 0x55, 0xAA, 0x60.
Data 0x55, 0xAA, 0x77.

EDIT: More testing to do...

Are they the first half of the instruction, or the second?

The 0x60 is used for sector protect/unprotect, I used this one myself to unlock sector 0.

Not sure if this has been covered, but when writing to the flash in byte/buffer mode, don't send the last byte twice. If that byte happens to be 0xF0 it will terminate the write sequence. I've had no issues sending 0x00 as the confirmation byte to the last address.

Found this, could be of interest. Some Macronix chips seems to have internal bank switching to expand the addressable ROM space. GBA specific but could easily be used on other Nintendo contracted flash chips.

Bank Switching (devices bigger than 64K only)
[E005555h]=AAh, [E002AAAh]=55h, [E005555h]=B0h (select bank command)
[E000000h]=bnk (write bank number 0..1)
Specifies 64K bank number for read/write/erase operations.
Required because gamepak flash/sram addressbus is limited to 16bit width.

Finally got around to dumping my GB Memory carts. If you're disassembling Mootan's program, then the options to load and save the NP register are under the menu that appears when you right-click the FlashManager window. Using Mootan's FlashManager and my version of the EZ-USB adapter, I dumped the "NP Register" for my 6 NP carts.


For the multi-game carts, the games are listed as they appear in the menu.

The Beat Mania and Spy vs Spy registers are interesting in that they have the name/date/time/location programming information in the register area. The multi-game carts all have the programming info stored in the Menu.

EDIT: Corrected Spy vs Spy register.

I dont have the hardware so I don't get to see what you see in mootans software, I just see the hex and machine code...

Can you trace the instruction set to get that data? See what commands are issued?

I must have cut and pasted the wrong register data for Spy vs Spy. Corrected the data in my preceding post.

I'm terrible at assembly code and have limited experience with IDA but I'll look further to see if I can make sense of anything. The associated text is "Load NP Register" and "Save NP Register". There are other strings "Open NP Register File" and "Save NP Register File".

I'll take a look for those strings, thanks.

Maybe install a port sniffer / traffic analyser etc and dump all lpt data to a file? Would be the easiest method as you have all the right hardware.

It will reveal the correct flash command sequence to read and write this magic data. Hopefully the same command set for the snes chips

https://technet.microsoft.com/en-us/sys ... 96644.aspx

Didn't knew that mootan's tool can read/write the hidden mapping data - that stuff might be very useful to figure out how it works.
Which utility are you using exactly, and do you have the source code for it, or only the .exe file?

I have checked http://mootan.hg.to/fmgbx/ and there is "FlashManager for GBx v1.10 (English Ver.)" (plain .exe) and "FlashManager for GBx v0.01 (VC7 MFC Project) (Source code, but it looks old... does that version include nintendo power stuff?).
EDIT: Going by the japanese text underneath of the download links, it looks as if "NP 8M" support was added in v1.00, so there seems to be no source code released for it.

I've had a look at the .exe, and it seems to be pushing function parameters (eg. address and data) on stack (prior to the function calls). So, when searching for opcodes like "push 00005555", the following "call" opcode might be the "write_data_to_address" function, and putting a breakpoint on that function could be useful to see what gets written to the cart.
Of course, if it's doing a lot of initialization & card detection prior to the "interesting" stuff, then it could be difficult to find the relevant writes.
Searching for "push 00000038" and "push 000000D0" opcodes might also reveal something (there are some such pushes, but I haven't spotted any eye-catching "push 38" being followed by a "push D0" shortly thereafter).

For executing the "Load/Save NP Register" functions, I guess that would only work when having the corresponding hardware connected? I could connect an old bung GBx reader to my PC, but it would probably still refuse to do anything without having a gameboy NP cart attached - or does the "Load/Save NP Register" stuff work without cartridge connected?

No, No source. I don't have the hardware either so I can't debug it in real time. I've been searching for the flash writethrough command, once found I mark the routines it uses then work backwards looking for calls etc... Haven't had much luck yet, If someone has the hardware and a real LPT port they could sniff the data using portmon.

Skaman has sent me USB traffic to and from his EZ-USB adaptor but a lot of the important stuff is obscured with the overhead to control the EZ-USB.

One thing I did notice is the software sets SRAM Bank 0x0A, then bank 0x00 3 times, then reads from the cart. I've replicated this and I've found data from 0x2000 when reading with CS active (not RD)

This is interesting because I've erased my Flash, and written 0xFF to the entire SRAM yet this data is still there and it is static, not just noise.

I can't tell if this is the magic data because I have no way of getting the correct data out of the cart, it doesn't look like Skaman's dumps though my cart came with a single ROM, no boot menu.

Success! A big thanks to skaman!!

(must write 0x77 twice)

NP Data from what was once Mario Bros.

B5 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 08 00 40 00 43 47 42 20 2D 41 48 59 4A 2D 20 20 82 4F 82 57 82 60 83 58 81 5B 83 70 81 5B 83 7D 83 8A 83 49 83 75 83 89 83 55 81 5B 83 59 83 66 83 89 83 62 83 4E 83 58 20 20 20 20 30 37 2F 33 31 2F 32 30 30 30 31 33 3A 33 31 3A 33 38 4C 41 57 30 33 33 34 37 01 00 30 25 00 03 01 00 12 57 FF FF FF FF FF FF 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Now to erase it, and re-write it! Oh, and issuing a chip erase will not destroy this data.

From the data skaman has sent I think I have it decoded. Untested...


0x0120<01, 0x013F<A5 - Unknown

0x0120<02, 0x013F<A5 - unknown

[0x5555] < AA
[0x2AAA] < 55
[0x5555] < F5 or A0.... Not sure which is a write, the bus log is bi-directional with no indication.

Read bus and wait for something

[0x5555]<AA
[0x2AAA]<55
[0x5555]<60

Read bus and wait for something...

[0x5555]<AA
[0x2AAA]<55
[0x5555]<E0

Read bus and wait for something

0x0120<03, 0x013F<A5
0x0120<08, 0x013F<A5

Send 256 bytes of NP Magic Data ......

There may be a verification command following

How did you do that exactly? And does it work stable?

I am assuming that "write 0x77" does mean a AA-55-77 sequence like this:
Right? That is, using SNES addressing, with the C00000h as base address for HIROM area, and with the 5555h/2AAAh values multiplied by two for the 16bit FLASH chips being used in SNES.

Whenever executing the above sequence (once, or twice, or several times), and then reading from [C0FFxxh], I am just receiving C8h bytes from the chip (occassionally with a few CAh or FFh bytes inserted on some reads).When reading from [C000xxh], I am getting C0h instead C8h. Anyways, that are just garbage or status values, not the hidden data.
Another odd thing is that, after sending the above sequence, the chip stops responding to any normal commands (eg. command AA-55-F0 doesn't return to normal FLASH data read mode anymore).

However, if I remove the whole write AA-55-77 stuff, and re-upload my test program to the SNES, then it does sometimes pop up with the hidden data - although I haven't issued the AA-55-77 stuff (nor the 38h,D0h stuff) in that situations at all.
So, it does look as if the 77h is starting to enter the hidden data mode on SNES, but it does still require whatever random bus traffic before completely reaching the hidden data read state.
I've tried to insert extra reads & writes & delays here and there, but haven't been able to reproduce that effect yet.

EDIT: Thinking about it. When I re-upload (and reboot) my test program, then MX15001 chip might automatically issue the 38h,D0h stuff (if it's doing so when receiving a /RESET from SNES side). So that might also explain where the hidden data is coming from even when NOT requesting it (ie. on the SNES, the AA-55-77 might be just causing the FLASH chip to fail to return to normal data mode after having received the 38h,D0h stuff from the MX15001).

Btw, does the SNES-sytle method for reading hidden data work on gameboy, too?

On SNES, with 16bit FLASH chips, it works like this:


For the gameboy's 8bit FLASH chips, one would probably need to divide the 0AAAAh, 05555h, and 00004h values by two, so it should work as so:

Does that work?

I call these functions, then read 256 bytes from address 0x0000
main_JPN_F2()
main_JPN_F4()
main_JPN_F5(0x77)
main_JPN_F5(0x77)

Where F2() is the WE line enable, F4() is the WP disable. You don't need to do this on the SNES, it doesn't have the little brain inside the MBC.

F5(0x77) is a write to 0x5555<0xAA, 0x2AAA<0x55, 0x5555<0x77

And yes, after issuing that command I am unable to perform a chip erase, write byte etc without first issuing a F5(0xF0) command.

I'll try your 0x38,0xD0,0x71 sequence now and report back

And no, that command sequence enabled nothing. Also, reading from 0xFF00 on a GBcart is not valid, I bank switched to access 0xFF00 and still it was just ROM data being read out. Likewise from 0x0000. There was no status byte returned either so I don't think the flash IC recognises that command set as valid.

In a way, the SF magic "0x38" does show up in the GB sequence. The flash commands that allow overwriting of the GB NP Register is a sequence with 0x60 (sector unprotect/protect) and 0xE0 (sequential load to page buffer). Following the 0xE0 command, 0x3 and 0x8 are sent to 0x120. See the last section of BennVenn's post (viewtopic.php?f=12&t=11453&start=105#p158687).

In regards to the 256byte NP register write - it is unusual that the MBC allows a flash write through where every other command write to the flash needs to be done using command 0x0F... I might look into this, could make for faster cart flashing

I can't see a 38 in there. If you meant the 3 and 8 bytes, that are three different things: 3 and 8 isn't 38, the 3 and 8 are written to the mx15002 chip (not to the flash chip), and the 3 and 8 were used with the hidden-write sequence (not the hidden read sequence).


That seems to be different on SNES. After command 70, I can't send any further commands, specifically: even F0 doesn't work anymore.


Yup, the gameboy would need some sort of bank switching for reading/writing FF00h. Maybe also for writing 0000h (assuming that writes to first 16K might be passed to the mx15002/mbc registers, instead of to flash).

I am still miles away from having an idea how the flash addressing would work on gameboy. For example, if you wanted to write a byte to flash address 8000h, then you would need writes to flash addresses 5555,2AAA,8000, which would be three different 16K banks. Assuming the gameboy address 0000-3FFF is reserved for mx/mbc I/O ports, then you would probably need to squeeze all three writes through gameboy address 4000-7FFF, each preceeded by a write to the mbc rom bank register (at 2180 or the like)?
Or wait, you mentioned something about special mx/mbc addresses for writing to 5555,2AAA, so that registers could be written at any time, regardless of the current bank for data access?

The purpose of the special write command (that with lo,hi,data parameters) isn't clear to me. If the flash chip connects directly to the gameboy databus, then it should be possible to do direct writes without needing that command... unless nintendo has totally screwed up the mx15002 chip design. Seeing the pinout of the mx15002 chip would be very interesting to figure out how the hardware works - and if there is any good (or bad) reason for using direct or indirect writes.

Flash addressing is a pain, and yes, it involves lots of writes to the flash, bank swapping, flash, bank swapping. And here lies the problem. If you write say 5555,AA, then bank swap, if the flash IC see's the bank swap write it will abort the instruction you are trying to pass to it.

This is why most flash carts use an unused pin on the edge connector to control the flash WE, so you are free to bank switch as you like and issue flash commands only to the flash IC.

Nintendo seem to have got around this by using the MBC IC to do all flash commands. The NP IC works like this:

You write the command instruction to the IC (0x0F), then load registers with the Address and data you wish to send to the flash IC, then write the execute command [0x013F]. Then the IC takes over, it waits 1 R/C constant as defined by the external RC circuit, by this stage it expects the gameboy bus to be high impedance. It then takes over the bus, sends the Address to the Flash Address bus, the data to the data bus, then triggers the flash WE pin for a few nS.

Using this technique, you can address the full 16bit ROM size, with the extra bits controlled via the bank controller.

I haven't looked into it yet, but command 0x03 and 0x08 must pass the Gameboy's WE signal straight through to the Flash IC, or else it wouldnt be able to send the NP data to the flash buffer... There must be complementary instructions to stop this.

Some older flash carts will respond to address 0x555 and 0x2AA which means no bank switching is required for the flash preamble. This is how the SharkMX cart works.

Looks like the SFC and GB flash chips are similar but very different. I'd day the NP structure would be the same though.

Looking forward to the dumps Skaman is working on!

I hooked up a logic analyzer to my GB cart interface that sits between the GB cart and the GB XChanger.

Here's the command sequences used when loading a new NP register:


This sequence loads the first 0x80 bytes of the new NP register.

Now to the end of the 1st half of the new register file:

Here's the end of the "Load NP Register" sequence. This code section starts with writing the end of the 2nd half of the new register file (all FFs). The subsequent commands read the entire new register file back (uses the 0x77 command).

Using the commands that I posted previously, I was able to write a new mapping sequence to the GB Memory cart. In the summary below, F# is BennVenn's function numbering as posted earlier in the thread.

Here's a summary:


Some other stuff I learned working with the code:


I'm going to look into fully decoding the mapping. I think I've figured out most of it except for the 8-byte sequence at 0x70.

Now let's hope that some of this applies to the SF Memory carts.

Cool, congrats on getting that working!

I am trying to figure out the memory map of the gameboy cart - just guessing - but it seems to look like so:

If that's right, then you would need to write to 2100h and 3000h only when accessing the memory window at 4000h..7FFFh. The code that you've posted isn't doing that at all - so I guess you could completely remove the 2100h/3000h stuff from it, right?

The hidden erase function consists of two (almost) identical steps: The first with [5555h]=40h, the second with [5555h]=04h. What's that about? One erasing the first 80h bytes of the 100h-byte hidden data, and the other one erasing the remaining 80h bytes?

The hidden write function is using not less than three writes to 5555h-2AAAh-5555h, that's a bit more than usually. Looking closer at it, the first write with data "AA-55-A0-FF-FF" isn't a hidden command at all! It's just the standard write command (writing two FFh bytes to addresss 0000h, which means it's just a dummy write; since writing FFh won't change any bits from "1-to-0").
The next two commands, with data "AA-55-60" and "AA-55-E0" seem to be invoking the actual hidden write.
What happens if you remove the "AA-55-A0-FF-FF" part? It looks like a useless dummy thing... unless it's some secret prefix needed to unlock the following secret hidden write command.

For both the dummy command (writing one dummy byte to 0000h), and the hidden write command (writing 80h bytes to 0000h), your code is having that "write-last-byte-twice" effect in it. That's unexpected because, as far as I remember, BennVenn said that the gameboy cart wouldn't need that effect (and wouldn't work at all when trying to do so).
If you are writing normal flash sectors (not the hidden sectors), are you getting that working with and/or without "last-byte-twice"?
EDIT: Sorry, I've misunderstood what you were saying. The extra write to last address is needed, but the data must be other than F0h, so, for the gameboy version, it would be "write-a-value-other-than-F0h-to-last-address" instead "write-last-byte-twice".

Oh, and about the actual mapping: Currently you can only map the menu, or alternately map a selected game (which works only for memory regions that ARE defined in the hidden sector).
But there's no way to map the WHOLE memory yet (like the HIROM:ALL feature in SNES version)? Having such a feature could be useful in several cases.

I removed the 2100/3000 stuff and the code still works.
I thought that too but the functions appear to do different things. If I use only 0x40, then the contents of the register becomes the result of merging the two register files (original and new) like using a bitwise AND. If I use only 0x04, then the register get erased to FFs but only 0x80-0xFF is written the first time. I have to add another 0x04, then 0x0-0x7F is written. It looks like the 0x40 function can be replaced by a 2nd 0x04 function.
I removed the 0xA0 flash command sequence and the code still works.
I haven't written to the regular flash yet. I'm still working on getting the reader code working for normal carts. I've got a good base for the normal mappers so I'll build off it to work with the NP cart.
The program appears to use 0xCF (1st command sequence in the original list) so that might address the entire flash. I haven't tested it yet.

More testing to do.

Great work!

Just something to keep in mind when re-flashing the flash. Unlock sector 0 first.

main_JPN_F1(0x5555,0xAA)
main_JPN_F1(0x2AAA,0x55)
main_JPN_F1(0x5555,0x60)
main_JPN_F1(0x5555,0xAA)
main_JPN_F1(0x2AAA,0x55)
main_JPN_F1(0x0000,0x40)

Okay, the bitwise ANDing would be the normal case when erase didn't occur.
On a normal flash chip, that six-byte sequence (AA-55-60 plus AA-55-40) would be the sector unprotect command. The sixth byte (40h) should be normally written to the desired sector address (not to AAAAh) though, but I guess the chip might accept any address in range 0..1FFFFh for unprotecting the first 128Kbyte-page.
Maybe the command is just doing the same thing on the chip in the gameboy cart, too. Maybe that command (or some other command) does also allow to protect/unprotect the hidden sector. But either way, if you have the /WP pin switched high (did you?) then the whole chip should be always write-able (going by the datasheet, the protect flags are used only when /WP=LOW).


Odd. The first write to 00h..7Fh is ignored, and only the second write to 80h..FFh is taken?
Sounds a bit as if the erase wasn't finished yet, so the chip refused the first write command when erase was still busy.

How are you handling the Write/Erase busy stuff? Ie. those "Loop (0x100 times) ... until 0x0000 reads 0x80" parts?
Correct should be reading until Bit7 of the returned data becomes 1=Ready. You may also add a timeout so that the program won't hang if something gets wrong, but make sure that the timeout is big enough (like one second, or at least several milliseconds). Doing the timeout after looping "0x100 times" sounds a bit short (depends on how much time your program needs to execute one of those loop cycles, of course).

Btw. also in the Write/Erase busy stuff: Is that "Write 0x03" really needed for anything? Normally it should be enough to READ the status byte several times (until it indicates ready), but without needing to write anything during (or after) that period.


Yes, just mentioned that sector protect stuff too, while you've sent your post. I think it's needed only when /WP=LOW though.

That are different chips with different IDs?


If you have spare time to do more soldering... How about wiring it up directly to the GB cart - and then logging what happens when running the cart on a real gameboy?
Theoretically it should read the hidden data on power-up, and also after selecting a game in the menu. Going by mootan's code, that would be done by sending AA-55-77 twice, but as far as I understand, mootan has found that command by trial-and-error - which is great - but it would be also interesting if Nintendo is really using the exact same sequence.

All of the carts that I have on hand report C2/89 which matches what Nitro found.

I did some logging with the cart interface sitting between the cart and Gameboy. I'll look and see what is there.

Here's what I've got so far on the GB NP mapping:


EDIT: Fixed the SRAM Size. Uses 3 bits spread across Byte 00 and 01.

Looks good! And looks as if you've already found out everything. Or do you still have some games that have non-zero bits in unexpected locations (like bit5-6 of byte1, for example)?

One thing that is missing is the RAM size. Common would be None, 2K, 8K, 32K (maybe also 128K in some newer titles), maybe that's somehow encoded in the 2bit "SRAM Flag" entry... do you have games with different size in your collection? The size can be seen in the gameboy cart ROM header (entry 0149h).

MBC1, MBC2, MBC3 and MBC5 should cover the most common mappers, do you have NP games of all those types in your collection, for confirming that they are all supported?

There are few more mappers like Huc1 or MBC4, but they are rarely used, so Nintendo might have considered as not worth being implemented in NP cartridges.

What is MBC0? Does that mean small games with only 32Kbyte ROM (=without any ROM bank switching)? Don't know if Nintendo sold any such small games as NP titles - or did they sell only newer/bigger titles? Oh, and did they sold both classic monochrome games and gameboy color games, or only color ones?

The SRAM Flag could be the RAM Size. I only have games that use 8KB saves. So those 2 bits could be used to encode something larger. The minimum RAM size would be 8KB (like the minimum ROM size is 128KB) due to the block size.


I have carts with MBC 0, 1, 2, 3 and 5. Entries for MBC 4, 6, and 7 are possible but I'm not sure if they're actually supported. I'll have to give those mappers a try when I find some time.

Yes, MBC0 = No Mapper. Sorry, went with the MBC# theme when typing it out. In my multi-game carts, I have NO_MBC games: Alleyway, Tennis and Yakuman.

I looked at the startup sequence and also when the cart switches between games.

The cart does use the AA-55-77 sequence.

Nice to see that the gameboy chip is holding reset low (like the snes version), and that it does really use twice AA-55-77 (unlike snes version).

The address 8000h and the /RD LOW stuff are logged that values from the cart-edge connector? Ie. those values are coming from the gameboy cpu during reset... which would be don't care since the cartridge is internally using it's own address bus and /RD and /WR signals for communicating between the FLASH and MX15002 chip.

For the data values, the leading/trailing FF's might be just openbus. The F0's might be the "reset-to-read-mode" command, though that should be three bytes long, AA-55-F0. Don't know what's happening there, maybe one can omit "AA-55" for command? I guess your logging hardware is more than fast enough, so it couldn't have missed the AA-55 bytes (even if they were only half as long in duration as the other bytes).

And the FF-00 (after the second AA-55-77 command, and before reading the 3-byte mapping data)... what could that be? Some status byte and/or open-bus? Or something read from the hidden flash sector? The latter one could be verified by filling the whole hidden sector values with some other value (like all bytes set to 33 for example), and then checking if the cart is still coming up with FF-00.

Found a GB Memory cart with a game that uses a 32KB SRAM. The SRAM size is actually 3 bits. The last two bits of Byte 00 (bit1..bit0) and the uppermost bit of Byte 01 (bit7) make up the SRAM size. The uppermost bit of Byte 01 (bit7) by itself appears to only be used for MBC2 games.

I'll update my earlier post with the corrected mapping details some time.

Going back to work on the SF Memory cart, I found the Intel Software Driver for the 16Mbit Flash Family (28F016). The command set appears identical to the Sharp (and Elisra) chips cited previously by nocash and includes the page buffer commands. The PDF is Intel Application Note 377 which includes C and ASM code: ftp://download.intel.com/design/archive ... 212603.pdf

I also extracted a copy of the Intel 28F016SA User's Manual (297372) from the Intel FlashBuilder software. I'll try to convert it from the current Windows help file format to PDF.

I've got a Nintendo Power cart for gameboy, too (thanks again, skaman). First thing that I've looked at are the pinouts of the chips:

The "MEM" pins are meant to be shared for FLASH and SRAM.
Don't know what pin 54, 55, 58, 59, 60, 67, 79, 80 on the MX15002 chip are good for.

And, tested some software stuff, too. I've been using an old parallel port cart reader from Bung, getting that thing to do what it should was a bit difficult (bung seems to have used a MODE byte that can be 00h,80h,81h,82h,83h, bit7 seems to control the /RESET line, and bit1 seems to be auto-incremented on write, and bit0 auto-increment on read - sending nintendo power commands seems to work best with those two bits cleared, and bit7 set to release /RESET). Some of the nintendo power commands take over control of the databus - but seems to be no problem with the bung hardware (ie. it seems to disable its databus output shortly after each writing).

The command values for port 0120h-013Fh known so far:

CMD_09h (Wakeup) is probably needed before sending any other commands, and, more eye-catching: It's activating read-access to port 0120h..013Fh. That's making it impossible to read normal ROM data from that locations, unless using CMD_08h (Undo Wakeup), or CMD_0Ch (seems to act same/similar as CMD_08h).

CMD_0Ah and CMD_02h seem to be both required for switching /WP to HIGH. They seem to be working only when sending them in order first CMD_0Ah, followed by CMD02h.

CMD_80h..BFh and CMD_C0h..FFh are used for mapping a selected game. The menu contains three different mapping methods (depending on what console it's running on):
For CGB and GBA consoles: Mapping is done via CMD_8xh, this selects game "x", and issues a /RESET to the gameboy. The advantage is that /RESET does reinitialize everything, AND, allows to switch between color gameboy and monochrome gameboy mode (which possible only after /RESET or power-up). The downside is that it's displaying the "Nintendo" logo another time after game selection.
For classic gameboy and gameboy pocket consoles: Mapping is done via CMD_Cxh, that selects game "x", but doesn't issue a /RESET (maybe because the /RESET pin doesn't work as input on older consoles). Instead, the menu is reinitializing some stuff by software, and does then jump to 0100h (the game entrypoint).
For SGB and SGB consoles: These are using CMD_Cxh, too, ie. without /RESET issued by the MX15002 chip, but instead doing some special SGB stuff: Uploading some code to SNES memory, and then executing that code on the SNES cpu (and that code does issue a /RESET to the gameboy cpu (via SNES port 6003h) and does restart the SNES (via jump to [FFFCh] on SNES side)).
In all three cases, for CMD_8xh/CXh, the final write to [013Fh] is done by code in the gameboy's High RAM at FF80h and up, followed by a short delay also executed in High RAM - that allows the MX15002 chip to read mapping info from the FLASH chip via databus without running into conflicts with the gameboy cpu's opcode fetches.

CMD_0Fh allows to write a single byte to FLASH memory. From the older posts, my impressions has been that it's needed only for writing to 5555h and 2AAAh, and that it's main purpose would be to access those two addresses regardless of the current ROM bank setting...
But, I seem to have been wrong on both. Using CMD_0Fh to write to 5555h is getting redirected to "RomBank*4000h+1555h", ie. the RomBank must be previously set via [2000h]=01h (or actually and ODD value written to [2xxxh] appears to be working).
And, after sending a data write command via CMD_0Fh, the actual data seems to be needed to be written via CMD_0Fh, too. skaman? BennVenn? Is that right? When writing 128 bytes of data, does one NEED to issue CMD_0Fh 128 times? Or is there some way to write the data part directly?

CMD_04h (Map Entire) does map the whole 1024Kbyte of FLASH memory, and CMD_05h (Map Menu) restores the normal mapping. The menu is using CMD_04h to "preview" the cartridge header of the different games (namely, checking header entry 143h via reading "Bank(N):4143h", if the byte is C0h=CGB only, then it's supposedly preventing to select that games on non-CGB consoles).
Theoretically, CMD_04h should be also nice for dumping the whole 1024Kbytes of FLASH memory. But somehow, I am having problems to get that working, CMD_04h is in fact mapping the MENU and GAME and unused sectors on my cart. But, it appears to be also causing the cart to return several FFh-filled 100h-byte blocks at random locations.
Am I doing something wrong, or is that happening to other people, too? And is there some way around it? My overall dumping code seems to be okay, ie. dumping only the MENU (without CMD_04h) does work without problems.

Oh, and reading ports 0120h..13Fh returns these values (when enabled via CMD_09h):
Whereas, when using CMD_04h (Map Entire), the mapping bytes at 0122h..0124h are changing to 9A,80,00 = Whole ("MBC4", 1024K ROM at block 0, whatever SRAM). Note that the 3bit mapper type is "4", which should probably mean "MBC4". The problem is that nobody seems to know how a "MBC4" is working, and there don't seem to be any gameboy titles known to be using a "MBC4" mapper - so maybe MBC4 didn't exist at all, or it did exist only as prototype. Anyways, maybe that "MBC4" mapping mode is causing the problems that I am having when trying to dump the whole 1024Kbytes.

Oh, and skaman, what did you mean by saying that the program uses CMD_CFh? The MENU program doesn't seem to use it... or did you mean mootan's tool using it... for dumping the whole 1024Kbytes?
The way how CMD_CFh is affecting the status bits at 0121h makes me think that it's just selecting "game 15" using the mapping data at hidden sector address 0Fh*3, which would be normally FFh-filled since the menu uses only entry 0..7. The FFh-filled values would probably map the biggest possible ROM size (ie. all 1024K), starting at the LAST 128K-block (and then wrap to the first block at higher ROM bank numbers), so CMD_CFh could be probably really used to dump the whole memory (when reordering the 128K blocks accordingly).
The only issue would be when the corresponding mapping bytes aren't FFh-filled (eg. the cartridges WITHOUT menu are having ASCII strings in that location, so one should avoid using CMD_CFh on such carts; instead one could just leave the default mapping mode for file 0, which should map all 1024Kbytes for menu-less single-game carts).

Lots of good info to read.

Thanks for identifying the differences between the game selection modes. I tried 0x8xh and 0xCxh but couldn't get my GB cart reader switching between games like I can with my SF cart reader. I'll try to apply your findings to get this working. There's something satisfying about watching a cart switch between menu and the selected game while running on my cart reader.

Things make more sense after reading your notes and looking at the logic analyzer captures. The 2100, 01 (WR LOW) stuff prior to CMD_0Fh is in the logs that I typed out. viewtopic.php?f=12&t=11453&start=128

CMD_0Fh doesn't need to be called repeatedly to write bytes. I think it depends on the last flash command sent to the chip. The termination is generally a read of 0x0000 (waiting for 0x80) followed by a write of 0x3 to 0x0000. Or sometimes the program writes to 0x2100 again.

I couldn't get CMD_CFh to work on my cart reader but then again I couldn't get any game selections working. Mootan's program sends 0xCF when initializing the cart so I assumed it was setting up the cart to read the entire flash.

Great work!

Thanks for confirming! And good to know that it's possible to write data directly. Allowing to do that must be related to the MX15002 chip (not to the MX29F080), ie. it must be enabled via some command written to [0120h] (not by writing anything to 5555h or 2AAAh).
Let's see, at the end of the viewtopic.php?f=12&t=11453&start=128 post, you've logged this:

So CMD_08h seems to be the important part for activating direct ROM writes (and unlike the "normal" state, it should even disable the "standard" functions like writing [2000h]=RomBank). Maybe the difference between CMD_08h and CMD_0Ch is that the latter one does disable only port 0120h..013Fh, but keeps ports like 2000h working as usually? Gotta test that!

Anyways, going on with the bytes that were sent after the above logged stuff:

So the above CMD_09h seems to be terminating the direct-rom-write mode. However, in order to issue that command, one needs to write to 0120h..013Fh (which are apparently recognized by the MX15002 chip, but which are theoretically also still sent to the MX29F080 chip).
In so far, the special sequence "09,AA,55,A5" might be intended distinguish the command-write from normal FLASH data-writes (rather than being intended as secret "password" for preventing hackers to access the chip).
The chip might get confused when you try to program those 09,AA,55,A5 values to the corresponding FLASH memory addresses; but that should never happen in practice since those addresses are containing the Nintendo logo, which consists of different values.

And, before doing a write to the RomBank register, a few more commands are sent:

In the above part, CMD_0Ah and CMD_02h should be needed only if the cart has somehow forgetten the /WP state (which probably isn't the case, so I guess they aren't really needed here; the commands should have no effect on RomBank writes either).
And CMD_01h, I've no clue what that command is doing... theoretically it could be needed for reactivating RomBank writes (instead of, or additionally to CMD_09h).

One issue solved: I've been using [2000h] for ROM bank selection, that's working okay in MBC5 mode (eg. when mapping the MENU). But, it doesn't work stable in "MBC4" mode (when mapping WHOLE 1024K, activated via CMD_04h), in that mode, [2000h] does map the desired bank, but it does cause weird read errors at random locations. On the other hand, using CMD_04h combined with [2100h] for bank selection does work fine - I can now dump the entire cart without read errors.

For direct ROM writes, CMD_10h seems to disable writes to the ROM Bank register at 2100h (and instead, any writes to 2100h are probably directly going to FLASH memory address 2100h). There are probably two commands needed for direct ROM writes:
- CMD_10h disable writes to normal MBC registers (such like 2100h)
- CMD_08h disable writes/reads to/from special Nintendo Power registers (those at 0120h..013Fh)

Okay so far, but I can't figure out how to undo CMD_10h and re-enable writes to ROM bank register. Going by skaman's logged code shown above, CMD_01h would look like a good candidate, but it doesn't seem to work. I've also tried to reproduce the whole log (except the data write): Ie. using CMD_10h, CMD_08h, CMD_09h, CMD_0Ah, CMD_01h, CMD_02h (in that order), but the cart still doesn't react to ROM bank writes (and stays stuck in the most recently ROM bank).

Solved that issue, too. CMD_11h does re-enable writes to the ROM Bank register. Ie. the full procedure for recovering from direct ROM write mode should be:
- CMD_09h: re-enable access to port 0120h..013Fh
- CMD_11h: re-enable access to MBC registers like 2100h

The write to 2100h in the logged hidden-data-write sequence probably doesn't work since the log doesn't contain CMD_11h. But then, hidden-data-writes don't require any rom banks at all (except that, the bank must be 01h (or some other odd value) for writes to 5555h).
Writing the whole 1024K flash memory is a different thing: That does definitely require writing different values to the ROM bank register - so that would require using CMD_11h (or maybe one could work around it by issuing a /RESET to the cart instead of using that command). Would be (slightly) interesting if mootan's tool used CMD_11h for flash memory writing.

EDIT: And, two other details concerning clearing bit0 and bit1 in the status register at [0121h]:
CMD_03h does clear status bit1.
CMD_09h (the "Wakeup" command) does clear status bit0.

Nintendo Power Directory for Gameboy version
Located at ROM offset 1C000h (aka 7:4000h in gameboy memory).
Entries are 200h bytes in size, the GUI supports max 8 entries at 7:4000h..7:4FFFh.
The first entry is a dummy entry for the menu, the other entries are for game(s), unused entries are FFh-filled.
The format is almost exactly same as in SNES version (but using only 200h bytes per entry, using a smaller bitmap, and without the SNES's weird overlapping bitmap tiles, and with different granularity for the ROM/SRAM values).

For the SRAM sizes, the "xx" means that the GUI ignores those 8bit fragments. And no matter of what values that bits have, it does support only four different SRAM sizes: 0, "MBC2", 8K, 32K. Anyways, the "xx" should be probably set to some specific values - skaman, did you check which games use which SRAM size settings in the directory?

News Ticker
Aside from the directory, the programming stations are also updating data at bank 6:4000h (ROM offset 18000h). Which contains the scrolling text that is shown at the bottom of the menu. There are at least two variants, one found in blank carts (with only the menu installed), and one other variant found in my cart with Puyo Puyo 2 installed.
Don't know how often that text has been updated. Skaman, if you compare the ROM offsets at 18000h..1BFFFFh from your cartridge collection, are there lots of different variants?

Selftest Function
The Menu contains some selftest function which seems to be activated when pressing all four buttons plus all four DPAD directions (which normally isn't mechanically possible). The test is barely testing the MENU's memory mapping, not testing the mapping or checksums of the other installed games. And, the test is working ONLY on blank carts, for two reasons:
The checksum in cart header isn't adjusted for changed data at 6:4000h (news ticker) or 7:4000h (directory).
The bank test expects 7:4000h to contain 07h (whilst non-empty carts are storing the menu index (00h) in that location).

Nocash, no need to lock out bank select registers when flashing as writing to bank0 at $6000 is the same as $2000 and the mbc won't trap the write.

Your earlier question regarding writing a dummy byte to actually write to the flash. Yes you must do it every byte written unless using the write buffer then its just once per 32bytes written.

That's working? You can write data to any FLASH address using "[2100h]=(Addr/4000h)" combined with "[4000h+(Addr AND 3FFFh)]=Data"? That would be neat - but it doesn't seem to work for me. Did you test that on a real Nintendo Power cart? If it would work, then it should be possible to access the 2AAAh/5555h addresses using the same technique, ie. for requesting the FLASH chip ID, one could do either this (tested/working):or this (tested, but not working for me):One possible issue is that 4000h..5FFFh is the MBC5 SRAM Bank register, so writing to that area won't ever reach the FLASH chip... unless the cart is passing the write both to SRAM Bank register and to FLASH chip, or unless there's some way to disable the SRAM Bank register(?)


Uh, I lost track of what I was asking about which dummy byte.
There's a dummy byte needed every byte written? And there's a 32-byte write buffer in nintendo power carts? Was that already mentioned anywhere? Maybe I haven't followed the gameboy-stuff too carefully before getting my own cartridge (I've tried to review the gameboy related posts last week though).

Sorry, I misread. Yes, issue it 128 times.

Here's the News Ticker text that I've found:

I've found some ways for writing data to the gameboy cart. Nothing really new, but just some notes about how to do writes in practice, and notes about possible problems.

First of, issue the chip erase command. BennVenn has been right about needing to unprotect sector 0 first (some macronix datasheet sounded as if the protect flags would be don't care when /WP=HIGH, but that seems to have been wrong, or doesn't apply for the chip used in the gameboy cart; the first 128Kbyte will remain unerase without the unprotect). Also as BennVenn mentioned, the chip erase command does erase only the 1024-Kbyte area (not the 256-byte hidden sector).

For writing 128-byte fragments:
- Use CMD_09h + CMD_11h to enable I/O access
- Use CMD_0Ah + CMD_02h to get /WP=HIGH
- Set Bank 01h and use CMD_0Fh to send the FLASH write command to 5555h/2AAAh/5555h
- Set Bank (addr/4000h) for the write destination
- Do the 128-byte data write (see below, method 1 and 2)
- Read status and wait until bit7=1
Then repeat for next 128-byte fragment.
Bank 0 must be written to 0000h..3FFFh. Trying to write bank 0 to 0:4000h..7FFFh doesn't work (at least not when using CMD_04h to map the entire FLASH memory; it might work in MBC5 mode, but that won't help since CMD_04h doesn't use MBC5 mapping).

Data Write Method 1 - direct writes:
- Send CMD_10h + CMD_08h to disable I/O ports and get direct FLASH write access
- Send 128 bytes, then terminate by writing FFh to the last written address
Normally: That method is best & fastest. It should be also the easiest way if you have direct access to the gameboy cartridge bus.
With Bung hardware: It can be a bit difficult when squeezing the data through the Bung parallel port device: Transferring address+data through parallel port works, but it's rather slow. Better would be using Bung's auto-incrementing address mode (done setting bung's mode byte to 81h, 82h, or 83h). Write+Increment is normally done by using 82h or 83h, but that didn't seemed to work at all, the Nintendo Power cart totally ignored all written bytes (and instead it did eventually write the following control bytes like 55h and AAh to unintended addresses). The mode value 81h is normally used for Read+Increment, but for some reason that value does work well for writing to Nintendo Power carts. And, another issue with Bung+DirectWrites (with or without auto-increment) is that the programming does occassionally start before writing all 128 bytes (so the last bytes of that area stay FFh-filled), that's probably some timing issue where the cart believes to have received two /WE pulses at the same address. I've got around that effect by inserting an extra OUT opcode: The SPP-mode write_data is: OUT port+0,data; OUT port+2,03h; OUT port+2,01h. Inserting a OUT port+2,00h at the begin of that sequence fixed the problem (that extra OUT would temporarily set read-direction, which appears to avoid wrong /WE signals). Only way around that problem seems to be to retry writing in case of verify errors (there should be no erase required on retry since the missing bytes are still FFh). Anyways, that issues are all bung-related. Don't care if you have a different hardware setup.

Data Write Method 2 - indirect writes via CMD_0Fh:
- Send 128 bytes via CMD_0Fh, then terminate by writing FFh to the last write address also via CMD_0Fh
That's just endless slow (with the bung hardware in SPP mode it's taking about 5 seconds per 16Kbyte). And, it turned that CMD_0Fh can't write to 0120h..013Fh (so any cart programmed that way won't boot due to invalid Nintendo logo in cart header); in MBC5 mode it might be possible to write that area via 0:4120h..413Fh, but that would require the mapping info in hidden sector to be (re-)programmed to use MBC5 mapping for file 0. So essentially, CMD_0Fh would be painfully slow and overcomplicated.

Oh, and the above japanese text translated via google, just to get an idea what the scrolling text is about:

I've also tested reading/writing/erasing the hidden data on the gameboy cart. It's just working as seen in skaman's logs, so I can only confirm that everything works as expect, and that the hidden stuff isn't more difficult than normal FLASH access.

For reading hidden data, send 55-AA-55-77 twice, then read 100h bytes from 0000h..00FFh (though that 100h bytes seem to be mirrored to all other FLASH addresses, too).

For erasing hidden data, send AA-55-60, then AA-55-04h.
In skaman's log, that's preceeded by AA-55-60 and AA-55-40h, that command is somewhat required for unprotecting the first 128Kbytes, but it isn't directly related to erasing hidden data (unless, maybe it's also unprotecting the hidden data, but anyways, there's no need to use that command as prefix right before sending the hidden erase command).

For writing hidden data, send AA-55-60, then AA-55-E0, followed by 128-byte data (transferred the same way as normal writes mentioned two posts earlier).
In skaman's log, that's preceeded by AA-55-A0h-FFh-FFh, ie. writing FFh (=nothing) to some FLASH address, which really isn't required.

Alltogether, everything seems to be working. Except, I should spend some more time on making my transfer program more stable, and write some documentation that summarizes all the NP commands and FLASH commands and data structures. And, just for curiosity, test if there some more hidden commands, like [0120h]=12h..7Fh. And of course write/erase is still needed for the SNES cart (although skaman seems to have already managed to get a SNES cart erased via some relative simple looking command sequence, and writing is hopefully not much more complex).

Got the hidden write/erase working on the SNES cart. The code that skaman used when he got a chip erased looked as so, with only two unknown variables:

Based on that, I made my own brute force program, testing all combinations for "x" and "y". Aside from the official macronix commands, I've found only two undocumented commands:

The sharp-style leading 38-D0-71-72 turned out to be not required for writing/erasing.

Great work!

My search code on the SF cart must be faulty. I'll have to modify my code with your findings and get it working.

Thank you for all of your help!

Thank you for all your work, too! To be honest, I've given up on writing/erasing the SNES cart about 3 months ago, the nonstandard sharp-style commands in a nonstandard macronix chip made me think that's almost impossible to find the correct commands. Probably it would have remained impossible - if you wouldn't have continued searching until actually finding a way to erase the hidden data.

Also thanks to sanni (especially for the initial databus log with the 38h-D0h values), and to BennVenn for details on the gameboy cart (especially the don't-write-F0h part), and credits to mootan for originally hacking the gameboy cart (which doesn't have the confusing sharp-style commands, but looks even more difficult than the SNES cart in other aspects).

Simply amazing, big thanks to all of you.

The code I'm using right now seems to be doing something wrong though but strangely it only affects the first flashrom.
While all works perfectly fine with the second flashrom(0xE0 when in HiRom All mode) for me the first flashrom(0xC0) always locks up when I try to erase/write the hidden mapping information.
Even weirder I got the same issue with the sector protection. I can set/remove the sector protection byte for the 0xE0 chip just fine but the 0xC0 chip always locks up.
I tested two different NP carts, both behave the same.

I was getting the same results. The 0xE0 chip could be erased and programmed using the commands but the 0xC0 chip refused to be programmed.

I switched the code to use Bank 0xD0 and the 1st chip can be erased and programmed.



Thanks nocash!

Success! Programmed my blank SF cart with US versions of Super Mario World and Super Mario All Stars (including English game names in the menu). The cart fully works with the new mapping.

Thanks to everyone that contributed to the project!

Did you figure out why C0h didn't work (or got it working with C0h?). I've tested only writing/erasing the E0h chip yet (and didn't expect any differences for the C0h chip). The FLASH chips should be same (and wired up the same), and the MX15001 probably can't prevent hidden writes (that would require it to be able to separate between normal & hidden flash writes). So I think that problem could be only due to different initialization of the flash chips.

If it's working with D0h but not with C0h... that sounds a bit as if the sector protect flag for the normal flash sector at C0h-C1h might also prevent accessing the hidden sector in that area... did you try clearing the sector protect flag? It's set by default/by nintendo, so you may need to clear it - and best keep it cleared forever since it's only disturbing normal writes (and maybe also hidden writes).

Problems with clearing the sector protect flag normally shouldn't happen - did you get that working, sanni? And released the /WP pin before doing so?

I can't erase nor write the sector protection flag on the first flash chip. I'm using CMD 0x02 to unlock /WP, both /WP's of two flashchips are connected together and using CMD 0x02 does have an effect on the second flashchip as without it I can't erase the sector protection, but with I can.

Also I do have a Nintendo Power cart that doesn't have any protected sectors by default and one with two protected sectors(two as seen in hirom). Both behave the same, I can't set/erase the sector protection nor delete/write the hidden area of the first chip. Using bank 0xD0 also doesn't work for me.

Here is my current Arduino Cart Reader Shield code for the NP cart, it can write the 2MB flashroms in one minute each thanks to using direct port manipulation instead of the Arduino functions I used before. PORTE3 (Arduino Pin 5) is used for generating the clock signal and needs to be connected to the CLK input of the NP cart.
Besides the non working sector protection/reading and writing the hidden area on the first flashrom it works quite reliable.

Edit: I can erase/set the sector protection by using bank 0xC1 instead of 0xC0. Guess I'll try all banks to see if any work for the hidden mapping area.

Congratulations! Now please be sure to buy up all the cheap $20 NP games, reprogram them with Wizardry 1-2-3, and make yourself $360 per reprogramming.

And also thank you. Now I have a definitive reason not to purchase any NP games ever. Verification of their contents is completely meaningless and impossible now. Saves me a lot of money ;)

I'll probably use this knowledge to make a nicer serial UART dev cart for myself as well :D
(Will need that for investigating the behavior of expansion port devices like the Satellaview.)

I haven't investigated the 0xC0/0xD0 further. I need to test on some of my other NP carts. I've been exclusively working on the blank cart so maybe that's the difference. 0xD0 works perfectly on the blank cart. EDIT: Tested on one of my other carts - Derby 98 and the mapping using 0xD0 works on it as well.

@byuu, you can get carts for less than $20. Unfortunately, no one (outside of those in this thread) is dumping the complete menu AND mapping for the NP carts. Non-menu carts like Wizardry only need the mapping data which is basically 16 bytes in the hidden area. Creating multi-game carts would probably leave signs in the menu data that they're not original. Someone would need to accurately reproduce the menu entries including the SJIS, bitmap, and Nintendo/Lawson date and time stamp. I'm not really interested in faking the carts but at $360 a pop, anyone interested in a Derby 98 Wizardry cart?

Looks as if you forgot to call the "busyCheck" in eraseMapping, unlockSectorProtection, and setSectorProtection - so that functions won't work (no matter what bank value you are using).
The various write/erase/lock/unlock commands (including hidden erase/write) are automatically switching to status mode (so you don't need the AA-55-70 in the busyCheck function).

The MX29F16xx datasheets specify 0.9ms per 128-byte page write (=avarage 7us per byte), so writing 2MB should take about 14 seconds, plus some more time for the chip erase (the datasheet says 1.3s per 128Kbyte sector, that would be 20.8s for the whole chip - but the chip erase command is hopefully faster, maybe taking only 1.3s for the whole chip).
And mind that you can program both chips simultaneously (issue write/erase to both chips, and - then - do busyCheck on both chips. So 14 seconds per 2Mbyte means that 4Mbyte will also take only 14 seconds (not 28 seconds).

I got it working now too, thanks to you and ofc skaman.

Followed your advise and updated the code in the link above. It now takes only 85s to flash a 4MB file instead of 125s like before thanks to flashing both roms in parallel.
With the busycheck commented out it takes 33s but ofc you only get write errors this way, but it means that all the sd reading code and sending the bytes out over the Arduino takes 33s while the additional 52s are spend in the busyloop waiting for the flashrom to send the "finished" command.

Just released no$sns v1.6, and alongsides updated the Nintendo Power flashcart documention: http://problemkaputt.de/fullsnes.htm#sn ... rflashcard
The nintendo power chapters are still a bit messy, containing some unsorted scratch notes, but anyways, they should somehow contain everything that's known about those cartridges (unless I forgot to mention something in there).

Hey nocash, I believe your documentation on the title bitmap is slightly wrong, while each section is indeed 30h bytes, I believe the first two tiles are created in line by line pairs (line 1 tile a, tile b, line 2 tile a, tile b) until the first two tiles are complete, it then moves on to the third tile but uses 1 bit of padding between 2nd and 4th tile code, for example, writing FF 00 would result in the output looking like F0 with potential garbage caused by the first F being in the padding area, if we instead write as 0F F0 (inserting 1 bit padding at the start that shifts over the hex by 1 bit), then we have space to do all 12 lines of the tile within 0 padding before returning to the standard side by side tiles for tiles 4,5,7,8,10,11,13,14,16,17,19,20,22,23

I have demonstrated this here : http://i.imgur.com/DBKu5wo.jpg
using this hex:

Yes it's two tiles line by line (hence the "y*2" in the formula; "y" is the line number). I think the formula is okay (for deciphering the bitmaps, which is probably opposite of what you are doing; assuming that you want to create those bitmaps). There is no "1 bit" padding/shifting (mind that hex-digits are 4bit wide).

I made a short video: https://www.youtube.com/watch?v=YGsC28IBr2A&t=8m5s

Hello!
I have bought one of Sanni's version 2 cart readers and I'm loving it:)
I want to thank all of you for the work you have put in to the project and especially figuring out the nintendo power cartridges, which are the reason I bought the shield.

What are the current goals people are working towards? I wanted to start figuring out the menu system myself by comparing different dumps but it looks like it's been done. I also don't think I ever would have figured out the bitmaps, and I'll admit it's still over my head even having read how it works..

Is anyone interested in a dump of 16 random NP SFC carts? Hoping to contribute to some sort of menu tool being created for easy customisation of NP carts.
I've just archived them in a .rar with the flash, map and rom dumps with a text file containing the game names and order.

Here's a compilation of some stuff I wrote for someone awhile back.

There isn't an automated way to make a multi-game ROM yet. I know one person was planning to write a program to create multi-game ROMs but I haven't heard of any progress for a couple months. To do it manually, you'll need to gather the games that you want and then create the menu entries starting at 0x62000. You'll need to know the ROM and RAM sizes and place those into the game entry. As you add each game, then the offset to the ROM and RAM needs to be calculated. Once the sizes and offsets are in the game entry, then you need to create the game title for the menu. Final step would be to create the mapping file which would also include the offsets for each game and the LoROM/HiROM setting.

I'd start out with a list of games and write down their characteristics:
Game 1: LoROM 512KB ROM, 8KB RAM
Game 2: HiROM 512KB ROM
Game 3: LoROM 512KB ROM, 2KB RAM
and so on.

Then write the corresponding bytes into each menu entry. Game 1 would be at 0x62000, Game 2 would be at 0x64000, Game 3 would be at 0x66000, and each subsequent game +0x2000. Keep in mind that the Menu uses ROM Block 0 when calculating the ROM offset.

===============================
If you look at a multi-game cart dump, then the first 0x80000 bytes are the "MENU PROGRAM". Within the Menu Program, there are entries used by the menu. The Menu entry is at address 0x60000. The Game 1 entry is at address 0x62000. The Game 2 entry is at address 0x64000. If there were more games, then they would be at +0x2000 bytes (0x66000, 0x68000, and so on).

Each game entry basically has 0x1D8 bytes of unique data within the 0x2000 bytes. At the end of the block, there is the "MULTICASSETTE 32" text.

The full documentation is in nocash's FullSNES here: http://problemkaputt.de/fullsnes.htm#sn ... rdirectory


You'll need to understand bytes 0x0-0x6. Byte 0 is the Game Entry#. Byte 1 is the ROM block offset. Byte 2 is the SRAM block offset. Bytes 3-4 are the number of ROM blocks used by the game. Bytes 5-6 are the number of RAM blocks used by the game. The game code at 0x7 can be anything but I'd suggest using the Nintendo assigned game code. The Shift-JIS text at 0x13 can be anything or padded out. The title bitmap at 0x3F is the text that is shown in the Menu. You'll have to convert your game title text to the format that the menu uses. The time/date/location stamp at 0x1BF can be left the same as you already have.

For example, a multi-game cart with 2 games (Shin Megami Tensei 1 & Shin Megami Tensei 2):

0x62000: 01 01 00 0C 00 40 00: Entry 1, ROM Block 1, RAM Block 0, ROM Blocks 0xC, RAM Blocks 0x40
0x64000: 02 04 04 10 00 40 00: Entry 2, ROM Block 4, RAM Block 4, ROM Blocks 0x10, RAM Blocks 0x40

If you look at Game 2, the game starts at ROM Block 4 because Game 1 uses 3 (0xC/4) ROM Blocks. Same goes for the RAM, Game 2 start at RAM Block 4 because Game 1 uses 4 (0x40/16) RAM Blocks.

Good Luck!

Is this cartridge can only programming 10 times?

You can reprogram it 100.000 times.

But when I write flash command to my gameboy np cart,and always return 0xcd,
only flash id command return normal data : C2 89 00 , others always return cd cd cd...

byemu,

I suggest you review BennVenn's posts along with my posts in response in this thread where we worked out of the GB flash commands.

To access the flash you need to use the NP commands. To read the flash ID, use what BennVenn numbered Function 1 (F1) and Function 2 (F2).



Use those two functions in the following manner.


Good Luck!

skaman,
I see,thank you.

I finally got around to soldering a 3rd Flash chip to empty location on the SF Memory Cassette PCB.

Over a year ago, I bought several 29F1601MC chips off a vendor on AliExpress (unfortunately the vendor no longer lists the part). The chips were used as part of my experiments that unlocked the hidden page that holds the mapping used by the NP carts. I always intended on soldering a chip to the PCB to increase the capacity to 6MB (48Mbit) but I never found the time to do it. I managed to find some time to work on it over the last couple weekends.

I programmed the new 3rd chip with some test patterns and soldered it (and a decoupling cap) to a SHVC-MMS-02 board. I ran tests trying to locate the flash but I could not find the test data anywhere. I thought that the 3rd flash might map to bank 0x40 like an ExHiROM but that didn't work. I ran extensive searches modifying elements of the NP commands to see if anything would map the 3rd chip but none of the changes made any difference in mapping the chip.

Since I hit a dead end software wise, I looked at sanni's SF Memory schematic and saw that there are a couple pins on the MX15001TFC that can be configured as pullup or pulldown. The MX15001 pins are Pin 38 and Pin 97 with both configured to pullup using R11 and R9, respectively.

I decided to test Pin 97 as a pulldown and moved the 10K resistor from R9 to R10. With R10 pulling Pin 97 down, the contents of the 3rd chip are now visible. The contents of the chip are interleaved with alternating bytes between the 1st MB and the 2nd MB. The chip appears to map at bank 0xA0 with a mirror at bank 0x20. Portions of the data also appear in banks 0x00 and 0x80. A side effect of the change is that the contents of the 1st (0xC0) and 2nd chip (0xE0) are no longer recognizable. Interestingly, the hidden mapping for both chips (0xC0 and 0xE0) still read out properly so that confirms where they sit. It appears that the game data written to the flash chips will need be modified in order to work in 6MB (48Mbit) mode.

After testing Pin 97, I decided to test Pin 38 and moved R11 to R12. The flash contents didn't seem to be affected. I'm not sure but I think it might be related to the SRAM? I'll be moving the resistor back to the original pullup configuration since it didn't appear to make a difference with the flash.

More testing to do...

EDIT: The flash chip data seems to be read 0xA0, 0xC0, 0xE0 when mapping to HiROM.

Are you using the HIROM:ALL mapping mode when doing that tests? Normally that should be the "best" mapping mode to access all memory, at least for normal carts with 2 chips.

Can you explain the interleave a bit more detailed? Do you mean something like this...
SNES address A08000h = Chip3, offset 000000h
SNES address A08001h = Chip3, offset 100000h
SNES address A08002h = Chip3, offset 000001h
SNES address A08003h = Chip3, offset 100000h
If it's mapped in bank A0h..BFh, with 8000h bytes/bank, then you still get only 1Mbyte (half of the 2Mbyte chip) mapped, right?

And what happened at bank C0h...E0h...FFh? Is there still any data in there... from chip1/chip2?

The default mapping (without HIROM:ALL mode) for bank 00h might be also interesting, just to confirm that the cart can still load the boot menu after swapping the pin97 resistor. Which, you could simply test that by booting the cart in SNES, and check if it's displaying the menu... and also check if it's still allowing to play the games from chip1/chip2.

I programmed the new 3rd chip with different data patterns for the 1st MB and 2nd MB using an external programmer board before soldering it to the PCB. The 1st MB was programmed with an initial 0x100 bytes of 0x55 followed by a repeating block of ascending bytes 0x00 to 0xFF. The 2nd MB was programmed with an initial 0x100 bytes of 0xAA followed by a repeating block of descending bytes 0xFF to 0x00.

After moving the resistor on Pin 97, the contents of the chip appeared when dumping using the HIROM:ALL mode. The data showed up in Banks 0x00, 0x20, 0x80, 0xA0. The data showed up as 0x55, 0xAA, 0x55, 0xAA and so on followed by the ascending and descending bytes also interleaved. To use your example:

SNES address A00000h = Chip3, offset 000000h
SNES address A00001h = Chip3, offset 100000h
SNES address A00002h = Chip3, offset 000001h
SNES address A00003h = Chip3, offset 100001h

What's weird is that the Chip1 and Chip2 data doesn't match even if I check for interleaving. All of the chips report valid Flash IDs and I can see their individual hidden mapping data but the data for Chips 1 and 2 don't resemble the game data that was programmed to them.

One significant difference is that prior to the hardware change, valid flash IDs were reported only for Banks 0x40, 0x50, 0x60, 0x70, 0xC0, 0xD0, 0xE0, and 0xF0. After the hardware change, valid flash IDs are reported for all Banks 0x00 to 0xF0.

More testing to do...

Hmm... I tried to erase the chips and it worked for the most part. Chips 1 and 2 erased to 0xFF. Chip 3 also erased to 0xFF BUT when I read back the contents starting in Bank 0xA0, I see unique data at 0xA06000-0xA07FFF, 0xA16000-0xA17FFF, 0xA26000-0xA27FFF, 0xA36000-0xA37FFF and that data repeats at addresses +0x10000. I assume that this must be SRAM data. When I checked the other banks, the data mirrors in Banks 0x20, 0x30, 0xA0, and 0xB0. The Chip 3 data must need to be read from Bank 0x80 (Bank 0x00 returns the Port Status bytes at 0x2400-2407).

More testing to do...

Oops, that isn't possible, at least not on a SNES console (which would map WRAM to that address). But if the HIROM:ALL mapping mode is supposed to be used ONLY by programming stations (which don't do that WRAM mapping), then it might work as, ie. mapping "HiROM" in banks A0h..FFh.

But it as you said, it might confilict with SRAM. Maybe there's some command that can disable SRAM, ie. by writing something to port 2400h. I haven't spotted such a feature, but I've focused on FLASH mapping, and didn't check if/which commands affect SRAM mapping (and of course, didn't do any SRAM tests with pin97 toggled).
So it might be worth searching for commands that can disable SRAM. You could also try to toggle pin38, maybe that could solve the SRAM conflict in the HIROM:ALL mode (and hopefully still allow to access SRAM in normal mapping modes).

Apropos normal mapping modes, did you try if the card/games still worked on SNES after installing the extra chip & toggling pin97?

Still trying to figure the 3rd chip out.

Here's what I found. R10 makes the flash chips visible in all banks.

With the resistor on R11 (original position), flash chip IDs are found in banks 40,50,60,70,C0,D0,E0,F0. We know that there are two chips at 0xC0/0xD0 (mirror 0x40/0x50) and 0xE0/0xF0 (mirror 0x60/0x70). The 3rd chip was nowhere to be found.

With the resistor moved to R10, flash chip IDs are found in all banks. I removed the 3rd chip to confirm that the first two chips are still in banks 40,50,60,70,C0,D0,E0,F0. So that means that the 3rd chip is found in 00,10,20,30,80,90,A0,B0. The 3rd chip becomes visible but the data in banks 40,50,60,70,C0,D0,E0,F0 is not correct. It appears that the contents between the 3rd chip and the other flash chips are combined.

What is interesting is that I replaced the third 1601 flash with a 1610 flash, the flash ID check showed C2F1 (1610) in all banks. There was no C2F3 flash ID in any bank and that was confirmed by the lack of mapping data.

I reprogrammed the third chip externally and confirmed that the data when read on the cart is interleaved as I mentioned previously.

All of my write tests have been using the HIROM:ALL mapping but it doesn't appear to be possible to properly write all 3 chips using this mode. I'm going to attempt to program each game slot individually and let the MX15001 handle the mapping. Hopefully involving the MX15001 will eliminate the problem with the data combining between flash chips.

Wish me luck!

Yes, test the normal mapping apart from the HIROM:ALL stuff! Basic test would be to just program the cart with the menu on 1st chip and with normal resistor setting. That should supposedly work even if the 3rd chip is installed (?)
And then change the resistor, theoretically, the cart should then still be able to read the menu from the 1st chip - if it doesn't work then there strange things happening.

Did you try the unknown Port[2400h] commands to see if they affect the mapping. And especially, did you try Port[2400h]=21h, since that command is known to disable ROM on a cart with 2 chips (and might thus activate the 3rd chip on a cart with 3 chips).

Might be best to try the above stuff with the resistor both at default & special locations (as by now, the special resistor setting didn't seem to do what it was expected to do, so maybe it's having some different purpose as expected, like activating a special mode with one large FLASH instead of 2-3 small FLASH chips, or whatever).

Are you sure that your 1610 chip outputs F1h as device ID? And what's its exact part number? The device IDs known to me are:
FAh = MX29F1610A ;\with sector_protect, suspend/resume, without sleep/abort
FBh = MX29F1610B ;/
F7h = MX29F1611 ;-with sector_protect, suspend/resume, sleep/abort
6Bh = MX29F1615 ;-without sector_protect, suspend/resume, sleep/abort
F3h = MX29F1601MC ;<-- undocumented, used in SNES nintendo power carts
If two chipselect's are triggered simultaneously, then you might get two ID's ANDed together.
On the other hand, with above values, that would never result in F1h. So yeah, I guess must have some chip that isn't in the above ID list.

I am not sure if I can follow you on the what-is-in-which-bank stuff. Having data in banks 40,50,60,70,C0,D0,E0,F0 makes sense to me - but didn't clearly say when there is no data in those banks.
Normal HiROM mapping should mirror the upper 32K-halves to those banks, or is that different in "HIROM:ALL" mode (with default resistor setting), and there's nothing mirrored to bank 00-3F and 80-BF in that case?

Btw. if you want to use the FLASH commands with port AAAAh and 5554h, did you recurse that bank 00-3F and 80-BF are only 32Kbyte in size? Ie. the FLASH commands would be then written to 01AAAAh and 0D554h. And chio ID would be read from 00800xh.
EDIT: Or as you said you get that weird interleaved mapping at A00000h and up when changing the resistor: That's apparently not following the normal 32Kbyte mapping. On the other hand, in that case, AAAAh and 5554h would need to be converted to interleaved addresses, which should be A05555h and A02AAAh (ie. divided by 2, plus A00000h). Hope that's right, the interleave effect is quite weird & confusing.

If everything doesn't help: Maybe nintendo has mis-wired the PCB (to me, FLASH_CS3 would look better at pin73 instead of pin71, but I hope that they knew what they were doing, and then pin71 should be okay).

Hello everybody! I drew letters for the menu using the tile molester. To compose a bitmap with the name I use the command line
For example - "Super metroid"

Then I use the HEX editor, copy the contents of the final file, excluding the last byte and paste it into the menu at 0x6203f

Archive contains only uppercase letters and a space

For anyone interested, I started working on a little application for quickly creating a ROM + MAP for the menu and additional games
or MAP files for standalone ROMs up to 1024kB

https://github.com/Infinest/GB-Memory-Binary-Maker

infinest does it also work with SF Memory as basically its the same chip ?

Nope the information written on the SF Memory is very different from the GB Memory from what I've seen in earlier posts.
Somebody else would have to program another application for that.

Hm, interesting. Ok then, can this GB Memory Cart hold GBA (advance) games ? Or only GB and GBC?

Only GB(C) games. The GBA cartridge interface is completely different (voltage, data bus, cartridge shape, etc).

Made a couple edits to the GB Memory News Ticker text.

The Puyo Puyo/5in1 had a typo at the end of the 5th line and the 2in1 Harvest Moon text was incomplete. The Harvest Moon News Ticker text lists the top 5 rewrites for first half of 2000. Super Mario Brothers Deluxe, Legend of Zelda DX, Kirby's Dream Land 2, Kirby's Dream Land, and Metroid 2.

I've dumped about 50 GB Memory carts with menus and the news ticker text is always one of the 5 variations posted. I can also confirm the news ticker text that was posted on the Japanese BB.

Seems like this can be done with "Super Ufo Pro 8". Here is the instructions and programs for it:
Rewriting
Menu entry offset
Source page and other stuff for Super Ufo

I would be very happy to see some more clearer and simplified English instructions on this for regular us people.. I would also be interested to know if anyone has tried to populate the missing mx29f1601mc for these?

Colleagues,

what is the format of map file. Which being dumped along with ROM. How can I create my own?

GB Memory mapping details here: viewtopic.php?f=12&t=11453&start=135#p161062

Colleagues, thanks to Infinest, I forked his GB Memory solution and adopted it for SF Memory.
So now You can easily create ROM and map file for Your SF Memory cart.

Obviously the code is a bit messy, so I will clean it up ASAP. Also bugs are expected, so I will try to fix them also.

https://github.com/moldov/SF-Memory-Binary-Maker/ if You need binary it's on "Release" tab.

Don't forget to put "Menu.sfc" 512Kb Menu file from NP cart in the same directory with program.

Thanks to:

sanni - for his masterpiece which gathered all the community solutions for scattered ROMS and platforms

skaman - SNES rom and mapping details

alex_n00b - bitmap letters for Menu

and all community's creative work which allows to find those hidden gems and undocumented abilities in retro platforms

Hi,

Thank you guys for the amazing work everyone put in. I have been working on some Gameboy Nintendo Power cartridges and have been able to Read/Write the Flash and the Mapping and everything works perfectly. The only thing I would like to do is Read and Write the SRAM for saves. None of the code available for the GB NP cart seems to show how to manage the SRAM save data.

I am looking to replace the aging batteries on some of the carts but don't want to lose all my save data.
I have BennVenns Joey Joebags, GBxCart RW by Inside Gadgets and also the Sanni card reader.

If there is any options or settings for either of these, please let me know.

Kind Regards
Jamie

If you are using the cartridge for a single game then you would access the SRAM like a regular cartridge, depending on the MBC.

If you had it as a Multi-game cart, then you need to switch to each game like you were selecting it on the GB, probably wait a little bit, read the game header to check it's changed and read the SRAM like a regular cartridge once again.

To switch between each game, you send these commands:
// Enable flash chip access
0x120, 0x09
0x121, 0xaa
0x122, 0x55
0x13f, 0xa5

// Switch to game 1
0x120, 0x81
0x13f, 0xa5

For game 2, it would be 0x82, etc.