Nintendo Power Emulation

Strictly for discussing ZSNES development and for submitting code. You can also join us on IRC at irc.libera.chat in #zsnes.
Please, no requests here.

Moderator: ZSNES Mods

Y~K
Hazed
Posts: 54
Joined: Mon Jan 22, 2007 3:27 am

Nintendo Power Emulation

Post by Y~K »

Nintendo Power Emulation

All is explained here:

http://forums.no.intro.free.fr/showthread.php?t=1180
byuu

Post by byuu »

Looks neat, I'll see if I can get them running this weekend. Do all Nintendo Power cartridges have this menu, or is there a way to tell which do and which were released as actual cartridges?

I could also use the PCB ID printed on the boards of these games / and or screenshots of the PCB front, if you have access to a gamebit to open the cases. If you don't have one, don't break them or anything, definitely not that important.
Y~K
Hazed
Posts: 54
Joined: Mon Jan 22, 2007 3:27 am

Post by Y~K »

Some games don't have that menu because they are too big. I explain:

All the NP carts I bought so far have 32Mbit of max capacity altho there is a placeholder for another 16Mbit flash rom.
The games that are smaller than 32Mbit all have the menu while the games which are 32Mbit don't have it simply because there is no ROM space left for it.

The highlighted [F] boxes represent the ROM space left of the cart.
8 boxes for 32Mbit, 1 box = 4Mbit
The menu itself is 4Mbit so by default there is always 1 missing box

I'll attach the scans on the No-Intro forums, if you don't want to register, let me know by PM & I will email you the scans. (note, the scans are pretty big)
byuu

Post by byuu »

Well, I tried to register as `byuu'. The e-mail link to register does nothing when clicked.
Y~K
Hazed
Posts: 54
Joined: Mon Jan 22, 2007 3:27 am

Post by Y~K »

weird... the person whe registered right before you got no problem to activate its account... maybe bad mail format.... I have fixed your account

please post 1 time somewhere as 0 posters have restrictered access
that is the harsh law of the forums :lol:
byuu

Post by byuu »

Hm, ok.

I really like the flash ROM chips, they're very common and easy to get ahold of. Good for homebrew. The BIOS is almost definitely stored on the bottom left chip, so you could flash that and get real poweron tests using that cart. The only thing better would've been if it used socket ICs.

MX B9743
29F1601MC-11C3
M20795
TAIWAN

Ok, the actual program. MAD is:

MegaChips
MX15001TFC
9735

Custom MAD, not seen on any other games. It's obviously a dynamic mapper. It has two registers, $2400 and $2401.

You select a game from the menu, and it writes #$09 to $2400, then reads the value back.

If it gets back anything besides #$7d, it returns immediately from a subroutine, and the game dies in an infinite loop.

If it gets back #$7d, it writes out: $2401 = $8428, $2400 = $813906, and then returns from the subroutine, also dying in an infinite loop, at $80c022.

Neither of those addresses neither directly nor indirectly hold any useful information. It's saying something special to the memory mapper, but unfortunately I don't understand what.

Also, the ROM data itself is interleaved to hell and back inside the complete ROM dumps. For RM7:

left = ROM, right = NP ROM
000000 -> 088000
008000 -> 098000
010000 -> 0a8000

100000 -> 080000
108000 -> 090000
110000 -> 0a0000

I don't know if you dumped the actual EEPROMs, or if you used a copier, but the data is really mangled. We'd need an interleaved mapper to support this out of the box, though it's possible the MAD does this internally as some sort of hackish way of handling both HiROM and LoROM style images.

Lastly, some disassembly:

Code: Select all

80c01e jsl $80c9d5   [$80c9d5] A:a001 X:0000 Y:000c S:1ffd D:1ef0 DB:7e nvMxdIzc V:261 H: 360
80c9d5 rep #$31                A:a001 X:0000 Y:000c S:1ffa D:1ef0 DB:7e nvMxdIzc V:261 H: 422
80c9d7 phd                     A:a001 X:0000 Y:000c S:1ffa D:1ef0 DB:7e nvmxdIzc V:261 H: 444
80c9d8 pha                     A:a001 X:0000 Y:000c S:1ff8 D:1ef0 DB:7e nvmxdIzc V:261 H: 474
80c9d9 tdc                     A:a001 X:0000 Y:000c S:1ff6 D:1ef0 DB:7e nvmxdIzc V:261 H: 504
80c9da adc #$fff1              A:1ef0 X:0000 Y:000c S:1ff6 D:1ef0 DB:7e nvmxdIzc V:261 H: 518
80c9dd tcd                     A:1ee1 X:0000 Y:000c S:1ff6 D:1ef0 DB:7e nvmxdIzC V:261 H: 582
80c9de pla                     A:1ee1 X:0000 Y:000c S:1ff6 D:1ee1 DB:7e nvmxdIzC V:261 H: 596
80c9df sep #$20                A:a001 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvmxdIzC V:261 H: 632
80c9e1 sta $0e       [$001eef] A:a001 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvMxdIzC V:261 H: 654
80c9e3 lda #$09                A:a001 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvMxdIzC V:261 H: 684
80c9e5 sta $002400   [$002400] A:a009 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzC V:261 H: 700
80c9e9 lda $002400   [$002400] A:a009 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzC V:261 H: 738
80c9ed rep #$20                A:a000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIZC V:261 H: 776
80c9ef and #$00ff              A:a000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvmxdIZC V:261 H: 798
80c9f2 cmp #$007d              A:0000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvmxdIZC V:261 H: 822
80c9f5 beq $c9fc     [$80c9fc] A:0000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvmxdIzc V:261 H: 846
80c9f7 lda #$0000              A:0000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvmxdIzc V:261 H: 862
80c9fa bra $ca27     [$80ca27] A:0000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvmxdIZc V:261 H: 886
80ca27 pld                     A:0000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvmxdIZc V:261 H: 908
80ca28 rtl                     A:0000 X:0000 Y:000c S:1ffa D:1ef0 DB:7e nvmxdIzc V:261 H: 944
---
//modified
80c9e9 lda $002400   [$002400] A:a009 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzC V:261 H: 738
80c9ed rep #$20                A:a000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIZC V:261 H: 776
80c9ef and #$00ff              A:a000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvmxdIZC V:261 H: 798
80c9f2 cmp #$007d              A:0000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvmxdIZC V:261 H: 822
80c9f5 bra $c9fc     [$80c9fc] A:0000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvmxdIzc V:261 H: 846
80c9fc sep #$20                A:0000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvmxdIzc V:261 H: 868
80c9fe lda #$28                A:0000 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvMxdIzc V:261 H: 890
80ca00 sta $002401   [$002401] A:0028 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzc V:261 H: 906
80ca04 lda #$84                A:0028 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzc V:261 H: 944
80ca06 sta $002401   [$002401] A:0084 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvMxdIzc V:261 H: 960
80ca0a lda #$06                A:0084 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvMxdIzc V:261 H: 998
80ca0c sta $002400   [$002400] A:0006 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzc V:261 H:1014
80ca10 lda #$39                A:0006 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzc V:261 H:1052
80ca12 sta $002400   [$002400] A:0039 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzc V:261 H:1068
80ca16 lda $0e       [$001eef] A:0039 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzc V:261 H:1106
80ca18 and #$0f                A:0001 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzc V:261 H:1136
80ca1a ora #$80                A:0001 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvMxdIzc V:261 H:1152
80ca1c sta $002400   [$002400] A:0081 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvMxdIzc V:261 H:1168
80ca20 rep #$20                A:0081 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvMxdIzc V:261 H:1206
80ca22 lda #$0001              A:0081 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e NvmxdIzc V:261 H:1228
80ca25 bra $ca27     [$80ca27] A:0001 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvmxdIzc V:261 H:1252
<>
80ca27 pld                     A:0001 X:0000 Y:000c S:1ff8 D:1ee1 DB:7e nvmxdIzc V:261 H:1274
80ca28 rtl                     A:0001 X:0000 Y:000c S:1ffa D:1ef0 DB:7e nvmxdIzc V:261 H:1310
80c022 bra $c022     [$80c022] A:0001 X:0000 Y:000c S:1ffd D:1ef0 DB:7e nvmxdIzc V:261 H:1354
And header info from the true Rockman 7:

Code: Select all

* CRC32    : 2dcd95b9
* Name     : "ROCKMAN 7            "
* PCB      : UNL-LOROM
* ROM Size : 16mbit
* RAM Size : 0bit
* Region   : NTSC
* Coprocessor(s) : None
* Reset:ff98 NMI[n]:ffa8 IRQ[n]:ff90 BRK[n]:ff94 COP[n]:ff94
*            NMI[e]:ff94 IRQ[e]:ff94 BRK[e]:ff94 COP[e]:ff94
Sorry, I have no idea what's going on with this BIOS. It's writing seemingly arbitrary values to its two MMIO registers, and hanging in an infinite loop at an arbitrary address. I can't make heads or tails of it with so little info, so I won't be able to emulate it without more info. My apologies.
Y~K
Hazed
Posts: 54
Joined: Mon Jan 22, 2007 3:27 am

Post by Y~K »

hummm ok too bad :oops:

I'll try to redump several times the menu to be sure there is no problem in the dump. Also I'm waiting for another of those NP carts. A third dump might help you... :oops:
Y~K
Hazed
Posts: 54
Joined: Mon Jan 22, 2007 3:27 am

Post by Y~K »

byuu wrote:Also, the ROM data itself is interleaved to hell and back inside the complete ROM dumps. For RM7:

left = ROM, right = NP ROM
000000 -> 088000
008000 -> 098000
010000 -> 0a8000

100000 -> 080000
108000 -> 090000
110000 -> 0a0000

I don't know if you dumped the actual EEPROMs, or if you used a copier, but the data is really mangled. We'd need an interleaved mapper to support this out of the box, though it's possible the MAD does this internally as some sort of hackish way of handling both HiROM and LoROM style images.
I have no idea what you're talking about
The rom dump I put in the archive is not interleaved at all

Did you get the file directly where i uploaded it or someone sent you a copy
I guarantee you the RM7 rom is totally clean
000000-07ffff = menu program (crc32 = 0549add4)
080000-27ffff = rm7 (crc32 = 31f18dda)
byuu

Post by byuu »

Compare the real Rockman 7 to the one in your archive:

Nintendo Power Menu Program (v1.1) - Rockman 7 (Japan).sfc

Go to offset 0x80000 in a hex editor. This matches Rockman 7 (J).smc at offset 0x100000 in the standalone RM7 ROM. The result is that your ROM has the RM7 ROM interleaved. It's either by design or by accident, I don't know how that memory mapper works as we've never seen it before.

I don't think another cart will help, sadly. I need technical information on that memory mapper and how its' internal registers work.
Jonas Quinn
ZSNES Developer
ZSNES Developer
Posts: 115
Joined: Thu Jul 29, 2004 9:51 pm
Location: Germany

Post by Jonas Quinn »

It isn't interleaved. Either your Rockman 7 ROM is interleaved or you have the wrong NP ROM.
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

No luck deciphering the mapper here either.. Need some text info or some scans of the PCB would be helpful.
Watering ur plants.
byuu

Post by byuu »

Jonas Quinn wrote:It isn't interleaved. Either your Rockman 7 ROM is interleaved or you have the wrong NP ROM.
Son of a bitch. Yes, it's my ROM. My apologies. I assumed the site I grabbed RM7 from was hosting only deinterleaved ROMs.

Ok, my apologies again. The NP ROM is fine.

pagefault, there are PCB scans on that nointro board if you want to register, but they won't help. It's a custom mapper, so we need hardware tests / documents on what the two registers are trying to do if we want to support it :/
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

byuu wrote:
Jonas Quinn wrote:It isn't interleaved. Either your Rockman 7 ROM is interleaved or you have the wrong NP ROM.
Son of a bitch. Yes, it's my ROM. My apologies. I assumed the site I grabbed RM7 from was hosting only deinterleaved ROMs.
Perhaps it's time you bite the bullet and install NSRT. You're not going to find better interleave detection and deinterleaving elsewhere.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Y~K
Hazed
Posts: 54
Joined: Mon Jan 22, 2007 3:27 am

Post by Y~K »

A wise man said: "you shall only grab "No-Intro" labelled ROMs..." :roll:
Jipcy
Veteran
Posts: 768
Joined: Thu Feb 03, 2005 8:18 pm
Contact:

Post by Jipcy »

Y~K wrote:A wise man said: "you shall only grab "No-Intro" labelled ROMs..." :roll:
A wiser man said, "you shall scan your ROMs with a No-Intro DAT, regardless of label."

A yet wiser man said, "you shall scan all your SNES ROMs with NSRT, regardless of label."

A fool said, "you shall grab ROMs ending with [!]."

This is fun.
[url=http://zsnes-docs.sf.net]Official ZSNES Docs[/url] | [url=http://zsnes-docs.sf.net/nsrt]NSRT Guide[/url] | [url=http://endoftransmission.net/phpBB3/viewtopic.php?t=394]Using a Wiimote w/ emulators[/url]
badinsults
"Your thread will be crushed."
Posts: 1236
Joined: Wed Jul 28, 2004 1:49 am
Location: Not in Winnipeg
Contact:

Post by badinsults »

I'm pretty sure I have a pcb of a Nintendo Power cart.

Image


I can dig through my old files to see if I have a larger version if you need it.
<pagefault> i'd break up with my wife if she said FF8 was awesome
Y~K
Hazed
Posts: 54
Joined: Mon Jan 22, 2007 3:27 am

Post by Y~K »

@byuu

I really do not understand the difficulty (probably I'm too stupid xD)
but the method to emulate NP carts seems pretty easy to me

The NP cart has 8 blocks
block 1 = menu program with all required infos: game list, serials, space taken, download date....
block 2 to block 8 = the game roms

when the NP is lauched, if there is a menu, only map the menu into memory

when you select a game on the list, the emulator must read on the menu program where the game is located then REBOOT AND REMAP the memory with only the selected game rom

I'm pretty sure this behavior is accurate because when you soft reset on real hardware AFTER selecting a game, the menu is not rebooted, it goes directly into the game selected previously!!

====

On a not related note, it should be pretty easy to write a program that emulates the NP game download device. It just require to write some bytes into the menu program ROM and join the NP roms to the menu program ROM. That would be pretty neat.
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

You "think" it is that simple, but it is pretty likely that it is more complex internally. The request for the cart scan isn't to prove it exists, rather to see the underlying traces and get an idea of how it is dealt with.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Y~K
Hazed
Posts: 54
Joined: Mon Jan 22, 2007 3:27 am

Post by Y~K »

Deathlike2 wrote:You "think" it is that simple, but it is pretty likely that it is more complex internally. The request for the cart scan isn't to prove it exists, rather to see the underlying traces and get an idea of how it is dealt with.
What makes you think it's more complex than that?
Sometimes the most simple ideas are the best! =P
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Y~K wrote:
Deathlike2 wrote:You "think" it is that simple, but it is pretty likely that it is more complex internally. The request for the cart scan isn't to prove it exists, rather to see the underlying traces and get an idea of how it is dealt with.
What makes you think it's more complex than that?
Sometimes the most simple ideas are the best! =P
Previous history and user idiocy.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
byuu

Post by byuu »

If you want to write a Nintendo Power simulator, you go right ahead and do that. ZSNES is GPL, meaning they'll allow you to do that and release your creation. My license won't allow that, for reasons exactly like this.

There's a huge difference between simulation and emulation, that has unfortunately been blurred by emulators using things like hacks and sound / graphics packs. Not that end users care at all. Note: I'm not saying either approach is better than the other, just that there is an important difference between them.

Sorry again that I was unable to emulate this for you, but unless you have technical documentation on that "MegaChips" mapper, there's nothing I can / will do. "$2401 = $8428, $2400 = $813906" can mean anything.

---

Ok, well just for the sake of completion, I went ahead and traced the other two options in your combo NP ROM.

First, there are only two unmapped register accesses, $2400 and $2401. Both are only accessed right before the game freezes on emulators.

First, #$09 is written to $2400 no matter what. It then reads back the register, and expects to get #$7d. If it dosen't get that, it jumps right to the infinite loop, loading #$0000 into the accumulator first.

If it does, it writes $2401 = #$28, #$84, regardless of which game is selected. It then writes $2400 = #$06, #$39, #$8n and jumps to the infinite loop.

The value written last to $2400 is the game number in the list selected. So you get #$81 for the first game, #$82 for the second game. It then loads #$0001 and jumps to the same infinite loop.

So, if you want to simulate NP support, your best bet is to count the writes to $2400. On the fourth one, mask accumulator with #$7f, and use that to know which game to use. You'll probably need to RE the internal storage data in the NP cart to figure out where in memory each game is really located, and then reload that ROM into the emulator and soft reset. This data seems to be located at $601c0 - $7ffff. Good luck parsing the format.

This is not at all hardware accurate, and I haven't a clue how the game magically switches the games around without writing any info on where the games are located to the mapper. The mapper would have to be reading data directly from the ROMs on its' own (somehow not causing bus conflicts) to figure this out, hence the infinite loop, and when its done, it switches things on its own, somehow not doing so in the middle of an opcode as that could easily crash the SNES. It would have to jump to a special handler as well, that would tell it where the correct reset vector is to jump to. Since we don't have any info on the mapper, we won't be able to get an emulator to execute that additional code that jumps into the game's reset vector. Hell, the cart may even be capable of soft resetting the system somehow. This is theoretically possible, as the cartridge port does have a /reset pin, though I assumed it was one way, read only.
The Dumper
Rookie
Posts: 11
Joined: Wed Jul 28, 2004 5:03 pm

Post by The Dumper »

byuu wrote:Ok, well just for the sake of completion, I went ahead and traced the other two options in your combo NP ROM.
That's the spirit! Thanks byuu, that's how we make progress.

byuu wrote:First, there are only two unmapped register accesses, $2400 and $2401. Both are only accessed right before the game freezes on emulators.
Ah, the beauty of simplicity.
byuu wrote:First, #$09 is written to $2400 no matter what. It then reads back the register, and expects to get #$7d. If it dosen't get that, it jumps right to the infinite loop, loading #$0000 into the accumulator first.

If it does, it writes $2401 = #$28, #$84, regardless of which game is selected. It then writes $2400 = #$06, #$39, #$8n and jumps to the infinite loop.

The value written last to $2400 is the game number in the list selected. So you get #$81 for the first game, #$82 for the second game. It then loads #$0001 and jumps to the same infinite loop.
Ah, but it's not an infinite loop on the NP Cart. It has a way to get out. I looked at this a long time ago and it was quite puzzling at first. You are referring to the MX15001TFC IC as a mapper. It's much more than that. It is a micro-controller. You write to registers on the microcontroller to give it commands and it does something. This isn't too surprising when you think about it. These carts were field programmable by plugging them into a kiosk. The only way this could be done without unsoldering the flash from the PCB was to have a controller on the PCB that could handle sending the right signals to the flash to program it.

byuu wrote:This is not at all hardware accurate, and I haven't a clue how the game magically switches the games around without writing any info on where the games are located to the mapper. The mapper would have to be reading data directly from the ROMs on its' own (somehow not causing bus conflicts) to figure this out, hence the infinite loop, and when its done, it switches things on its own, somehow not doing so in the middle of an opcode as that could easily crash the SNES. It would have to jump to a special handler as well, that would tell it where the correct reset vector is to jump to. Since we don't have any info on the mapper, we won't be able to get an emulator to execute that additional code that jumps into the game's reset vector. Hell, the cart may even be capable of soft resetting the system somehow. This is theoretically possible, as the cartridge port does have a /reset pin, though I assumed it was one way, read only.
BINGO! You've guessed the secret. The microcontroller can, and does, reset the system after reconfiguring the map. I had to put it on a logic analyzer to figure this out. The infinite loop you mentioned -- not so infinite after a reset.

My goal in studying this was to attempt to either figure out how to program the cart through microcontroller commands or through brute force of unsoldering the ROMs, reprogramming them to a new configuration, and soldering them back in. You can imagine my great disappointment after seeing how these carts work. They are beautifully designed. Everything I could want in a programmable cart -- and, they have room for another flash chip so you can make them 48 Mbit. But, alas, the same beautiful design that makes it such a desirable cart, also makes it virtually impossible to change the configuration without inside knowledge. Since, as you observed, the menu only writes a one byte game ID to the microcontroller (and my recollection is that the ROM is not accessed for game config data after this, it just waits to be reset), the microcontroller must contains its own small memory store, most likely flash, but possibly sram, to hold the configuration of the games on the cart. That onboard flash has to be programmed to change the cart configuration and there is no way to do that by unsoldering the microcontroller. You need information on the programming algorithm that Nintendo programmed into it. This information could have been captured by snooping hardware at the time the game was programmed at a Nintendo Kiosk but unfortunately it appears no one did this, and now the Kiosks are gone forever, and with them the chance to gather information on how to re-program these carts. I thought of doing this, but unfortunately, the NP cart Kiosks were only in Japan and I've never been there, so unless some miracle occurs (Nintendo starts providing NP cart programming services again, or someone leaks the information, or someone comes up with a datasheet on the microcontroller and is able to recover its program) this information is lost to us forever.

I do have 4 NP carts of different configurations with menus, and dumps of the 4 menu programs. I ordered them this way to analyze the differences in menu programs. It may be possible to use the menu program for some other purpose. It's pretty cool. If I recall correctly the game name is specified in graphics format so you could replace it with an English (or other language) name pretty easily. If you're interested I can make the menu images available to you.
Y~K
Hazed
Posts: 54
Joined: Mon Jan 22, 2007 3:27 am

Post by Y~K »

byuu wrote:If you want to write a Nintendo Power simulator, you go right ahead and do that. ZSNES is GPL, meaning they'll allow you to do that and release your creation. My license won't allow that, for reasons exactly like this.

There's a huge difference between simulation and emulation, that has unfortunately been blurred by emulators using things like hacks and sound / graphics packs. Not that end users care at all. Note: I'm not saying either approach is better than the other, just that there is an important difference between them.
You are totally right, and I was silly to state it could be accurate. bsnes is an "accuracy-oriented" emulator so keep walking that road, you are totally right.

And, as you stated, zsnes which is more hi-compatibility-oriented can use that unaccurate method to emulate NP carts. I will let the proficient zsnes coders deal with it.

The Dumper wrote:I do have 4 NP carts of different configurations with menus, and dumps of the 4 menu programs. I ordered them this way to analyze the differences in menu programs. It may be possible to use the menu program for some other purpose. It's pretty cool. If I recall correctly the game name is specified in graphics format so you could replace it with an English (or other language) name pretty easily. If you're interested I can make the menu images available to you.
I am interested too ;) I may write a software that simulate NP game download device, and I need more info (especially about the names used in game list)

You know my email ;) If you didn't download my menu program dumps yet, tell me by email so that I send them to you.
byuu

Post by byuu »

You are referring to the MX15001TFC IC as a mapper. It's much more than that. It is a micro-controller. You write to registers on the microcontroller to give it commands and it does something.
Right, as a logic device it could do just about anything. Sorry, I was just meaning that it is personally responsible for accepting cart address fetch requests, and figuring out which byte to actually retrieve from the EEPROMs, as the game is missing an LS or MAD chip. Of course, in our case, it's a super mapper that does a lot of other stuff, such as flashing the carts. Kind of makes me realize just how bad the NES emulation scene had it with their ~256 mappers that added all kinds of IRQ logic and such to themselves.
BINGO! You've guessed the secret. The microcontroller can, and does, reset the system after reconfiguring the map. I had to put it on a logic analyzer to figure this out. The infinite loop you mentioned -- not so infinite after a reset.
Ah, fascinating. I'll ask anomie to update his SNES pin document, he didn't specify either way before.
My goal in studying this was to attempt to either figure out how to program the cart through microcontroller commands or through brute force of unsoldering the ROMs, reprogramming them to a new configuration, and soldering them back in. You can imagine my great disappointment after seeing how these carts work. They are beautifully designed. Everything I could want in a programmable cart -- and, they have room for another flash chip so you can make them 48 Mbit. But, alas, the same beautiful design that makes it such a desirable cart, also makes it virtually impossible to change the configuration without inside knowledge. Since, as you observed, the menu only writes a one byte game ID to the microcontroller (and my recollection is that the ROM is not accessed for game config data after this, it just waits to be reset), the microcontroller must contains its own small memory store, most likely flash, but possibly sram, to hold the configuration of the games on the cart. That onboard flash has to be programmed to change the cart configuration and there is no way to do that by unsoldering the microcontroller. You need information on the programming algorithm that Nintendo programmed into it. This information could have been captured by snooping hardware at the time the game was programmed at a Nintendo Kiosk but unfortunately it appears no one did this, and now the Kiosks are gone forever, and with them the chance to gather information on how to re-program these carts. I thought of doing this, but unfortunately, the NP cart Kiosks were only in Japan and I've never been there, so unless some miracle occurs (Nintendo starts providing NP cart programming services again, or someone leaks the information, or someone comes up with a datasheet on the microcontroller and is able to recover its program) this information is lost to us forever.
Ah, I see. That makes a lot of sense, that has to be what it is: special cart-specific info is stored inside the "MegaChips" IC. Well, if you find a way to dump it (though it will probably involve nitric acid and a microscope, I'm afraid), I will give it my best shot to decode the data stored on the chip. Emulators have typically focused in producing bit-perfect input to bit-perfect output (which only requires perfect bus synchronization), and not on the actual math logic involved, so long as the output is correct. So with the flash data, perhaps we can rig something up. Doesn't help with your problem of reprogramming the chip. Sadly, I'd be afraid that brute force guessing how to write to it could inadvertently "corrupt" the data stored on the "MegaChips" IC and then you'd have a dead NP cart :(
I do have 4 NP carts of different configurations with menus, and dumps of the 4 menu programs. I ordered them this way to analyze the differences in menu programs. It may be possible to use the menu program for some other purpose. It's pretty cool. If I recall correctly the game name is specified in graphics format so you could replace it with an English (or other language) name pretty easily. If you're interested I can make the menu images available to you.
If my services can be of any use to you, please let me know. Just note that my knowledge stops right after the basics of "what a capacitor does" :(
I don't really want to attempt emulation with just the above info, as I'm afraid you're very much correct that there is additional data stored on that IC that we don't have dumped.

For the sake of writing up a document on this, perhaps I should take a look at your dumps to try and figure out how the ROM layout is done. Is it linearly stored one ROM immediately after another, or are there padded gaps between each ROM? Probably the former, which will make detecting them without that IC flash data even harder.
You are totally right, and I was silly to state it could be accurate. bsnes is an "accuracy-oriented" emulator so keep walking that road, you are totally right.

And, as you stated, zsnes which is more hi-compatibility-oriented can use that unaccurate method to emulate NP carts. I will let the proficient zsnes coders deal with it.
Thank you for understanding. ZSNES appears to be focusing more on our niche now, examples being the addition of a cycle-accurate S-CPU core and blargg's subsample S-DSP core. Which is a good thing: if anyone can get such an accurate setup to run fast enough for end users, it's them. But who knows, perhaps they'll add in NP support anyway, we'll have to wait and see. It should be at least doable with the above info.

I liked the Sufami Turbo more myself, that was just implementing a static memory mapper. Not even a single hardware register involved.
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

I have a game booting to the title screen but then it freezes... It's looking at a memory range I have no idea.. Maybe WRAM.
Watering ur plants.
Post Reply