nesdev.org

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.

Markfrizb wrote: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.

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.

Markfrizb wrote: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.

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.

Markfrizb wrote:I swapped the chips from derby stallion 98 to the DKC3 cart. Game works.

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

byuu wrote:Does anyone have an SFC NP menu ROM handy?

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.

Ramsis wrote:I have three games on my NP cart: Torneco no Daibouken – Fushigi no Dungeon, Super Trump Collection 2, and Shanghai III

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.

Markfrizb wrote:The MX29F1601MC I wonder if the OE and CE are reversed maybe???

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?

byuu wrote: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.)

.

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