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?
FHorse wrote:
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).
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.
WedNESday wrote:
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.
Quote:
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
I strongly disagree to use CRCs to detect mapper. This kind of stuff prevents homebrew and is extremly annoying.
oRBIT2002 wrote:
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.
Zepper wrote:
oRBIT2002 wrote:
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
Quote:
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.
blargg wrote:
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.
Quote:
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.
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.
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.
[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?
WedNESday wrote:
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.
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"?
blargg wrote:
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:
Quote:
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).
tepples wrote:
blargg wrote:
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.
WedNESday wrote:
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))):
tokumaru wrote:
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.
blargg wrote:
(...)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.
Nestopia has a window within the image info patched or not. I do something similar with my emulator, so it's
not being hidden in anyways. However, AFAIK, it's not possible to identify a good dump, except with CRCs but... may get in trouble as blargg pointed out. So, for dirty headers yes, it's fixable.
As far as SHA-1 collisions go, you have to see things in a risk-neutral manner. What's the probability, across all NES roms, of a collision? A quick look on wikipedia suggests that it's significantly smaller than 10^(-18). Such things aren't worthy of mention; might as well talk about why we aren't defending our emulators against lightning strikes or wild zebra attacks. Just talking about it here has already given the question of coincidental SHA1 collisions more time than it ever deserves. (Intentional collisions is a different matter, but not one of interest).
I can use the tool that comes with the source code of Holy Diver Batman to make an entire test suite. Which combinations of PRG ROM size, PRG RAM (battery backed or not) size, CHR ROM size, CHR RAM (battery backed or not) size, mapper, etc. do you want me to make for you?
Although I agree without reservation that a Header > CRC/Choosing a board on load, most ROMs aren't iNES 2.0. By all means implement it so that the newer ROMs can take advantage but just remember that 99% of games that are used (Super Mario Bros., Zelda, Metroid etc.) are still in iNES 1.0 and always will be.
So even though Headers are best emulators are still forced to use CRC/Choosing a board on load to determine how ~99% or so of ROMs are setup.
You're looking at the wrong probability.
The set of CRCs you might collide with is the set of problem ROMs that need to be corrected, which is much, much smaller than the set of all released ROMs.
And yes, as a homebrewer it would be really annoying for that one build you had that happened to trigger a hash collision, but it's extremely unlikely to happen to you more than once. It's already extremely unlikely to happen ever. This really is a non-issue.
That said, I'm completely in favour of iNES 2 support. The more important problem having to do with CRC checks is you can't romhack a game that relies on the CRC check to be run correctly. (This is a really annoying thing about MAME.)
I just thought of a way to integrate hash checking and NES 2.0 into the same framework. For each ROM, someone would find a distinctive part of the PRG ROM that translation hacks are unlikely to change, such as level decoding code. This part would be expressed as a start address and length, with the expected hash value. Each hash match would be mapped to an NES 2.0 header. Separating the database into a self-contained filter that just corrects loaded ROMs in this way would keep the emulator core itself clean, taking whatever NES 2.0 file the front-end gives it.
Each database entry would need 36 bytes:
- Offset from start of PRG ROM of hashed area (4 bytes)
- Length of hashed area (2 bytes)
- SHA-1 value (20 bytes)
- Bytes 6 through 15 of the correct NES 2.0 header (10 bytes)
So what other homebrew ROMs have correct NES 2.0 headers?
Everything I've ever released has NES2.0 headers.
Pretty certain. Might have missed one or two near the beginning.
rainwarrior wrote:
The set of CRCs you might collide with is the set of problem ROMs that need to be corrected, which is much, much smaller than the set of all released ROMs.
Some emulators I believe have a database of
all commercial ROMs.
Quote:
And yes, as a homebrewer it would be really annoying for that one build you had that happened to trigger a hash collision, but it's extremely unlikely to happen to you more than once. It's already extremely unlikely to happen ever. This really is a non-issue.
Again, it's like putting
if ( rand() == 1234 ) corrupt_header(); in your ROM loading code. At the very least, make it OPTIONAL; allow the user to disable this header modification.
lidnariq wrote:
Everything I've ever released has NES2.0 headers.
Pretty certain. Might have missed one or two near the beginning.
Then your collection is missing most games.
WedNESday wrote:
lidnariq wrote:
[Nearly] everything I've ever released has NES2.0 headers.
Then your collection is missing most games.
This is probably the case. Only a small fraction of video games are homebrew. In fact, commercial NES games outnumber homebrew NES games to such an extent that Red Hat's legal department won't let Red Hat include a freely licensed NES emulator in the Fedora repository.
WedNESday wrote:
lidnariq wrote:
[Nearly] everything I've ever released has NES2.0 headers.
Then your collection is missing most games.
Can you read? What did I say? I said
the ROMs I've released. I didn't say anything about anything anyone else has done.
There's "released" as in an author self-publishing his own work, and then there's "released" as in what a software archivist (such as a warez group) does with someone else's work.
lidnariq wrote:
WedNESday wrote:
lidnariq wrote:
[Nearly] everything I've ever released has NES2.0 headers.
Then your collection is missing most games.
Can you read? What did I say? I said
the ROMs I've released. I didn't say anything about anything anyone else has done.
The problem is how certain is the information regarding iNES 2.0 on the NesDev wiki? I've just checked the page about the 4 bits designated to the submapper and I see the words 'draft' and 'proposed' a lot.
WedNESday wrote:
The problem is how certain is the information regarding iNES 2.0 on the NesDev wiki? I've just checked the page about the 4 bits designated to the submapper and I see the words 'draft' and 'proposed' a lot.
The NES 2.0 page itself has settled. A lot of the submappers are settled; others are still being defined as it becomes clearer what is needed. Now that my current campaign in
Cookie Clicker is deep into using wrinklers to distill the dough, I'll go through and see what proposals haven't been edited in a while and gauge how much
consensus I can infer from silence. (On the other hand, I just got the upgrade that gives me more cookie-carrying cervids to shoot.)
There's no "iNES 2.0".
Use "NES 2.0" instead.
blargg wrote:
Some emulators I believe have a database of all commercial ROMs.
To what end? Do these emulators ignore the iNES header entirely and have a complete set of mapper type information for them? I think the problem in this case is not hash collision so much as a poor design choice for the emulator.
I know MAME works this way, with a ROM only format, and it's completely hamstrung the tremendous homebrew potential it could have had.
rainwarrior wrote:
I know MAME works this way, with a ROM only format, and it's completely hamstrung the tremendous homebrew potential it could have had.
What homebrew potential does an arcade cabinet have?
MESS is perfectly capable of loading typical NES-headered ROMs (as well as UNIF), so you can test/develop your homebrew in MESS.
Joe wrote:
What homebrew potential does an arcade cabinet have?
At Midwest Gaming Classic 2011, a homebrew multicart ran on a PlayChoice machine. It was a Contra cart converted to mapper 180, with the MGC 2011 multicart programmed onto it. Games included Concentration Room, Thwaite, Munchie Attack, Pung, and more. There have been a few homebrew Neo Geo games as well.
And even beyond platforms that one would expect both MAME and MESS to support, someone bootlegged Tetris onto Vanguard hardware under the name "Vantris".
rainwarrior wrote:
blargg wrote:
Some emulators I believe have a database of all commercial ROMs.
To what end? Do these emulators ignore the iNES header entirely and have a complete set of mapper type information for them? I think the problem in this case is not hash collision so much as a poor design choice for the emulator.
Yes. Nestopia does, for example, and it is such a pain. He took it as an excuse to completely break mappers 21, 23, 25, and 185. Admittedly, ROM hacks of m185 games should also disable its protection, but this basically prohibits most VRC2 and all VRC4 ROM hacks and translations.
Currently Nestopia supports all of the fields of the NES2.0 header
except submapper, so adding support requires changing some of the object methods.
Joe wrote:
What homebrew potential does an arcade cabinet have?
Why would it have any less potential than the Saturn or Virtual Boy?
tepples wrote:
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).
The implementation of the header made me start a reorganizing and cleaning of a piece of code that has kept me busy, not making me connect to the forum. Tepples, many thanks for the links, it is always a good thing to have something on which to perform the tests.
Thanks. Now that I've finished filling reindeer sprites full of digital lead, I can just sit back, let the cookies click themselves, and get back to helping.
I thought about going back and adding NES 2.0 headers to my existing projects, but most of them are just stock NROM with no 7420+6264. Apart from my graphics editor, which is meant to run on a PowerPak anyway because of its support for multiple save files, I've been avoiding relying on battery save because of replication cost.
oRBIT2002 wrote:
I strongly disagree to use CRCs to detect mapper. This kind of stuff prevents homebrew and is extremly annoying.
I 100% agree, and I refuse to use CRCs to detect mapper or anything else, and I also refuse to
not implement NES 2.0 headers if I write a emulator. I refuse to implement a database of commercial ROMs as part of the emulator for any purpose. It might be useful to have for use with an external program, though, which includes the correct NES 2.0 headers for those games and then it can correct them before loading them in the emulator. If you don't understand NRS/Famicom and just want to play those games using illegal downloads, then too bad. You have to learn how the headers work if you want to play games with bad headers.