- For making cartridges of your Super NES games, see Reproduction.
I noticed I have 2 different versions carts..
SHVC- MMS - X1. (SF2)
SHVC -MMS - 02. Dkc3
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.
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.....
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).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.
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?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.
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.
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?
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).
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).Markfrizb wrote:I swapped the chips from derby stallion 98 to the DKC3 cart. Game works.
Here you go.byuu wrote:Does anyone have an SFC NP menu ROM handy?
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?Ramsis wrote:I have three games on my NP cart: Torneco no Daibouken – Fushigi no Dungeon, Super Trump Collection 2, and Shanghai III
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=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 =04, that confirms that  contains the SRAM base address, counted in 2Kbyte units. So the format of the directory entries is now fully known:
Code: Select all
0000h 1 Directory index (00h..07h for Entry 0..7) (or FFh=Unused Entry) 0001h 1 First 512K-FLASH block (00h..07h for block 0..7) 0002h 1 First 2K-SRAM block (00h..0Fh for block 0..15) 0003h 2 Number of 512K-FLASH blocks (mul 4) (=0004h..001Ch for 1..7 blks) 0005h 2 Number of 2K-SRAM blocks (mul 16) (=0000h..0100h for 0..16 blks) 0007h 12 Gamecode (eg. "SHVC-MENU- ", "SHVC-AGPJ- ", or "SHVC-CS - ") 0013h 44 Title in Shift-JIS format (padded with 00h's) (not used by Menu) 003Fh 384 Title Bitmap (192x12 pixels, in 30h*8 bytes, ie. 180h bytes) 01BFh 10 Date "MM/DD/YYYY" 01C9h 8 Time "HH:MM:SS" 01D1h 8 Law "LAWnnnnn" or "NINnnnnn" (eg. "LAW01712", or "NIN11001") 01D9h 7703 Unused (1E17h bytes, FFh-filled) 1FF0h 16 For File0: "MULTICASSETTE 32" / For Files 1-7: Unused (FFh-filled)
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).
Your overall wiring seems to be okay since you have successfully managed to send the erase command to the chip.Markfrizb wrote:The MX29F1601MC I wonder if the OE and CE are reversed maybe???
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..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.)