NES 2.0 header implementation

[FHorse]

I want add support for the NES 2.0 header in the puNES, someone can tell me where I can find some test roms that uses it?

[WedNESday]

I want add support for the NES 2.0 header in the puNES, someone can tell me where I can find some test roms that uses it?

The greatest reason not to bother implementing the iNES 2.0 header is the fact that so little NES ROMs actually use it. Somebody did tell me in another thread that around 5% of ROMs actually use it but I find that number to be unlikely. Since it is frankly impossibru to hunt down every NES ROM on every hard drive in the world and update it I have chosen not to implement it. If you need to determine which board a certain mapper uses either do a CRC check or get the user to pick a board (which is what WedNESday does).

[tokumaru]

I think you should implement it even if you can't find a single ROM that uses it. I mean, even if you had 200 ROM to test with, I'd expect very few of them to use the more troublesome configurations, so you'd still be mostly in the dark. Even if you can't properly test it, your emulator will have higher chances of running an iNES 2.0 ROM successfully if you did something about it then if you chose to ignore it.

I haven't done much NES programming lately, and haven't really released any finished ROMs, but everything I do uses iNES 2.0. I expect most homebrews to use it as well, so even if nobody goes in a quest of converting and re-releasing all the old commercial ROMs, the number of iNES 2.0 ROMs out there will keep increasing.

It's such a simple thing to do, I don't know why anyone would choose not to implement it.

[tepples]

If you need to determine which board a certain mapper uses either do a CRC check

Which fails on hacks of Holy Diver and homebrew using the Holy Diver board.

or get the user to pick a board (which is what WedNESday does).

I know: let's all port our NROM and CNROM games to the Holy Diver board, mapper 78.3, and report errors to the emulator authors! I could be the first, with a multicart of all of my own games, my cousin's, and a couple other Free ones like NES15 and Lawn Mower. You'll have bug trackers filling up in no time. :p

[oRBIT2002]

I strongly disagree to use CRCs to detect mapper. This kind of stuff prevents homebrew and is extremly annoying.

[Zepper]

I strongly disagree to use CRCs to detect mapper. This kind of stuff prevents homebrew and is extremly annoying.

Unless, of course, there's a bad header or a bad dump. So, a CRC check would help to fix the mapper number and/or the NES header flags properly for that broken game. I do this in RockNES for a few games with incorrect settings in the header. There's a pseudo-hack of F-1 Race: the guy just changed the mirroring in the header to make the game hud be "transparent", but the road is glitchy.

Regarding NES 2.0 header format, it's good a few files for testing the loading & parse the header info. No matter about the small amount of files floating: there's also a good amount of DiskDude corrupted headers.

[blargg]

I strongly disagree to use CRCs to detect mapper. This kind of stuff prevents homebrew and is extremly annoying.

Unless, of course, there's a bad header or a bad dump.

Isn't it a waste of time to try to make corrupt files work? Might as well just look at the filename and have all the full correct ROM dumps built into the emulator

So, a CRC check would help to fix the mapper number and/or the NES header flags properly for that broken game.

For that corrupt file. One downside is that you add yet another chance of something else having the same CRC and thus being "corrected" (broken) by this mechanism. CRC checks like this turn an emulator into a commercial-games-only affair, rather than an emulator aimed at accuracy.

[Zepper]

Isn't it a waste of time to try to make corrupt files work? Might as well just look at the filename and have all the full correct ROM dumps built into the emulator

Like Nestopia does? I don't think so.

For that corrupt file. One downside is that you add yet another chance of something else having the same CRC and thus being "corrected" (broken) by this mechanism. CRC checks like this turn an emulator into a commercial-games-only affair, rather than an emulator aimed at accuracy.

It's unrelated in my opinion. Even Nestopia patches (some) bad headers.

[blargg]

Looking at the ROM's CRC and then modifying its header if it happens to be certain values creates a non-zero chance that some unrelated non-commercial ROM will have the same CRC. Maybe you also look at the filename, but then you make it likely to not correct a ROM which has been renamed slightly. Also, appeal to authority fallacy; even if Nestopia does it, it's still a hack.

[Zepper]

Interesting. Two ROMs with the same CRC. Just as note, the PRG ROM CRC is used in my emu, but you gave me an idea... of disabling automatic patches.

[WedNESday]

[quote="Zepper"]Interesting. Two ROMs with the same CRC./quote]

16384 NES ROMs in the GoodNES set (apparently). How many would have the same CRC blargg?

[tokumaru]

16384 NES ROMs in the GoodNES set (apparently). How many would have the same CRC blargg?

Again you are only thinking about the past. New games are still being made, and during development people run thousands of different builds of their programs. Don't you think the chances of a misdetection becomes significantly higher in this scenario? I know I'd be really pissed if I was testing one of my projects and some emulator decided to patch it. I'd end up wasting a lot of time looking for a nonexistent bug.

Come on, you guys making emulators should think about the homebrewers that might want to use your emulator as a development tool too, and not only about the pirates that will only be playing 25 year old games.

[Zepper]

1. We're going offtopic. The OP has requested files with NES 2.0 header for testing purposes. I agreed.
2. An emulator is for playing games, "from the past" or newest homebrews. Same priority.
3. It was just a offhand comment regarding ROM patching, which the great Nestopia does. I have a minimal set of a must-patch files. Does it bother someone else?
4. Where's the emulator user feedback, as "homebrew developer"?

[tepples]

Looking at the ROM's CRC and then modifying its header if it happens to be certain values creates a non-zero chance that some unrelated non-commercial ROM will have the same CRC.

This is less true of MD5, SHA-1, or SHA-256.

Robin says "Holy diver, Batman! We're way offtopic."

Back to topic:

someone can tell me where I can find some test roms that uses it?

PR8 uses and needs NES 2.0 because it's designed for SXROM.
Holy Diver Batman uses NES 2.0, including a ROM with mapper 78.3 (the Holy Diver board).

[blargg]

Looking at the ROM's CRC and then modifying its header if it happens to be certain values creates a non-zero chance that some unrelated non-commercial ROM will have the same CRC.

This is less true of MD5, SHA-1, or SHA-256.

Actually not. There is still a non-zero chance of collision. And that doesn't even address the fact that making a small patch to the ROM would suddenly break it with no clear evidence as to why. The emulator hid the fact that you had a corrupt dump, and then when you made an innocent patch it decided to stop covering for it being corrupt. Given that there are ways to avoid the gamble, why make it in the first place? It's like throwing if ( rand() == 1234 ) corrupt_header(); into your ROM-loading code.

16384 NES ROMs in the GoodNES set (apparently). How many would have the same CRC blargg?

The probability of there being a pair in the set with the same CRC-32 is 3% (1-e^(-0.5*16384*(16384-1)/(2^32))):

Again you are only thinking about the past. New games are still being made, and during development people run thousands of different builds of their programs. Don't you think the chances of a misdetection becomes significantly higher in this scenario? I know I'd be really pissed if I was testing one of my projects and some emulator decided to patch it. I'd end up wasting a lot of time looking for a nonexistent bug.

Exactly. And you probably wouldn't even realize it. You'd make a minor change, then it would totally bug out, and you'd wonder what the hell. You undo the change and it works fine. You re-apply the change and add a little bit more and it works fine.

In closing, iNES 2.0 is the way to go.