nesdev.org

I found an old list of accurate NES emulators from back in 2012. Well, 3 years later, what emulator is the most accurate? Is it still puNES?

I'm asking because I've got a simple demo that acts differently on different emulators - the demo just displays some static white on green BG text and plays a song using Famitone 2. It has MMC5 enabled and 512k of PRG-ROM but isn't using any of that yet. In puNES, my demo works perfectly fine, in Nintendulator it looks like it has a corrupt nametable and the music doesn't play, and in NESICIDE the music plays fine but the screen is solid white.

While puNES is still generally accepted to be "the most" accurate, since you're seeing significantly different behavior between puNES, Nintendulator, and Nestopia, you will probably have to test on hardware to determine which is actually correct.

In the mean time, to eliminate one variable, I'd try making a (temporary) test build that's something simpler than MMC5; perhaps MMC3, FME7, or mapper 82.

The obvious question is if you are initializing all of the MMC5's registers properly. There are a lot of them and I don't think anyone has written a test for the MMC5 power up state so that wouldn't be included in the accuracy metric.

Even if what you have does work on the real hardware (or on "the most accurate emulator", if there even is such an absolute title), it's worth checking out why it isn't working on some emulators. The demo isn't anything out of this world that relies on super accurate emulation, it's just a static screen with music, something that should work on any emulator. It's probably an initialization issue, and fixing it will make your program overall more stable, which is always good.

I always follow this rule when coding NES stuff: if the program isn't doing anything out of the ordinary that exploits obscure behaviors and isn't extremely timing sensitive, it should work on any decent emulator. If it doesn't, I'm probably doing something wrong, or at the very least not as safely as I could be.

Right. I improved the situation, I had moved my startup code to the very last PRG-ROM bank (since as I was told that's the default bank MMC5 has loaded), but I missed the ROM I was reading the text to display from - that text was still on the very first bank. Odd that puNES worked with that, but once I fixed it, that made it so both puNES and Nintendulator now run the demo correctly. Now I gotta keep playing around to see if I can get Nesicide and FCEUx to run the demo (especially Nesicide, I'm using that as my dev tool).

Of course, once I get the basic demo working on all these emulators and start playing around with special features like the scanline IRQ, the usable emulators may dwindle again...

Has anybody tried the Retron 5? It pulls the ROM off of the cart. You still need the cart..so I guess it kind of qualifies as emulation...

I'm pretty sure the Retron5 is just using the FCEUX source for emulating NES games....

GameFrenzyUSA wrote:I guess it kind of qualifies as emulation...

You can stop guessing. =) Yes, it just dumps the ROM and runs it on an emulator. Apparently this means that homebrews don't work on it unless they're explicitly added to the database of known games, so the Retron 5 know how to dump them.

tokumaru wrote:Apparently this means that homebrews don't work on it unless they're explicitly added to the database of known games, so the Retron 5 know how to dump them.

Or the homebrew is specifically doctored to produce the same checksum as one of the existing games in the database (I believe it uses CRC-32).

For unknown ROMs, why can't the Retron 5 just probe the mirroring registers to see which known mapper is most likely? Or is it just engineering incompetence?

Probabilistic algorithms fail unpredictably... And it wouldn't help for modern multicarts anyway.

But the developer might appreciate being sent an autodetection algorithm. (Maybe. I think it's worth a shot, anyway.)

tepples wrote:...is it just engineering incompetence?

This is awfully judgemental of someone that at worst just has different priorities than you do.

lidnariq wrote:But the developer might appreciate being sent an autodetection algorithm.

My multi-mapper test ROM uses the method taught to me by Paul of InfiniteNESLives.com. For each mapper that has mirroring control (common ASICs and a few discretes such as AOROM and Holy Diver), write to its mirroring ports, and see what value is put on A10 when reading $2000, $2400, $2800, and $2C00. If the mirroring behaves as expected for a particular mapper, dump and emulate it as that mapper.

If mirroring is fixed, and it's not one of the known oddball games, then it's probably either a GNROM subset (such as NROM or CNROM) or a Color Dreams subset (such as BNROM or UNROM, which can be emulated as an oversize BNROM if overdumped). My test ROM cheats by having the bank number at a predefined location in each PRG bank, but the loader can still dump other PRG banks to see where it's CCCCPPPP (Color Dreams, BNROM, UNROM) or PPPPCCCC (GNROM, MHROM, CNROM).

As for engineering priorities, your sense of priorities might change once you have to issue refunds. "I bought a copy of Lizard and it won't even play on my Retron 5. What gives?"

lidnariq wrote:But the developer might appreciate being sent an autodetection algorithm. (Maybe. I think it's worth a shot, anyway.)

The certainly might appreciate it, but they definitely don't deserve it.

tepples wrote:As for engineering priorities, your sense of priorities might change once you have to issue refunds. "I bought a copy of Lizard and it won't even play on my Retron 5. What gives?"

So... are you saying that I'm incompetent?

Honestly, I think much better than a detection algorithm would be UI that lets a user select a mapper for the unrecognized cart (or override for a recognized cart), and add it to the database stored by the machine.

The current system seems to be manual intervention via support? Many homebrew games are already in the database at this point.