When I first tested my emulator with Blargg's ROMS, I noticed that I could hear the beeps, but there was no output on the display. Looking into it I realized that his roms use mapper 0, but they expect to be able to write to CHR-RAM.
Once I modified my mapper 0 to setup 8 kiB of CHR-RAM for roms that don't have any CHR-ROM, it worked fine.
My concern is that I have broken some mapper 0 games by doing this (do any of them inadvertently write to CHR-ROM?). What are the criteria for deciding whether or not to enable CHR writes for mapper 0? Is this something I should just hack in for Blargg's ROMs or are there real games that use this?
Shamashmuddamiq wrote:
Once I modified my mapper 0 to setup 8 kiB of CHR-RAM for roms that don't have any CHR-ROM, it worked fine.
This hack will work in most emulators that accept iNES format. In effect, what you're doing is treating mapper 0 with no CHR ROM as a 32 KB
BNROM.
Quote:
My concern is that I have broken some mapper 0 games by doing this (do any of them inadvertently write to CHR-ROM?). What are the criteria for deciding whether or not to enable CHR writes for mapper 0?
If it's RAM, enable writes. If it's ROM, don't.
Quote:
Is this something I should just hack in for Blargg's ROMs or are there real games that use this?
Given that BNROM could stand for Blargg NROM...
Quote:
Quote:
My concern is that I have broken some mapper 0 games by doing this (do any of them inadvertently write to CHR-ROM?). What are the criteria for deciding whether or not to enable CHR writes for mapper 0?
If it's RAM, enable writes. If it's ROM, don't.
Okay, I had already done this, but I was momentarily confused, thinking that there were possibly ROMs out there that didn't expect/use either CHR-ROM or CHR-RAM. Silly.
Thanks for the quick reply.
There are a few games that use both chr rom and chr ram.
I've wondered about this issue myself. I never really paid much attention to what iNES flags I used for the test ROMs. I figure if a cartridge file has no CHR data, you pretty much have to assume it's using CHR RAM. I've considered using CHR ROM but that'd only be possible on some of the tests. Using CHR RAM for everything allows a single general configuration (which matches my devcart that I test them on). I also figure that an emulator that's at the point where my tests will help will be well beyond the point of supporting CHR RAM properly.
Actually, if the iNES header brings a non-zero number for the CHR-ROM pages, writes to PPU 0000-1FFFh are ignored. There are a few carts that uses both by the way. This is something "standard" AFAIK. A good example of "missing" gfx is the game Fantasy Zone (CHR-RAM writes enabled when CHR-ROM is present).
The iNES header format is so uninformative, and the variety of ROM images out there so chaotic, that it's best to simply ignore the header entirely if at all possible. Instead, a large database of all known CRC32 (or MD5 if you prefer) hashes should be included in the emulator, and mapper routines selected on this basis. An advantage of this is that the emulator can also display the full game name in the title bar or About menu, and can automatically select devices such as the Zapper or Power Pad when appropriate.
The header should only be used if a CRC match fails.
How about "If header[7] & 0x0F >= 3" treat as a "DiskDude!" rom and ignore bytes 7-15?
I'm not a fan of DiskDude hacks. And I'm even less of a fan of CRC or other hash/checksum methods. It seems to me it'd be better to attack this problem at its source (ie: the bad headers themselves). Rather than working on a way to make bad headers work... we should be working on a way to correct the bad headers.
Instead of a CRC database.... why not an IPS database? Most emus already have softpatching, so why not distribute a bunch of common problem header fixing IPS patches? They would only be like 25 bytes each -- which would .7z down to practically nothing.
That's something I thought of doing in the past, anyway.
Josh wrote:
The iNES header format is so uninformative, and the variety of ROM images out there so chaotic, that it's best to simply ignore the header entirely if at all possible. Instead, a large database of all known CRC32 (or MD5 if you prefer) hashes should be included in the emulator
Then how will homebrew developers register each build's CRC with the developer of each emulator?
Quote:
The header should only be used if a CRC match fails.
So what happens when a homebrew program matches a commercial game's CRC by coincidence? It's not unlikely given the number of commercial NES/Famicom games, both licensed and not, and pirate versions, hacks, and other images recognized by Cowering's GoodNES.
Or are you targeting your emulator only at people who want to play illegal copies of commercial NES games? In that case, you may be "inducing" piracy under the U.S. Supreme Court's interpretation of copyright law, which is persuasive though not binding in some other English-speaking countries.
Josh wrote:
The iNES header format is so uninformative, and the variety of ROM images out there so chaotic, that it's best to simply ignore the header entirely if at all possible. Instead, a large database of all known CRC32 (or MD5 if you prefer) hashes should be included in the emulator, and mapper routines selected on this basis. An advantage of this is that the emulator can also display the full game name in the title bar or About menu, and can automatically select devices such as the Zapper or Power Pad when appropriate.
Nope. Those who write emulators with checksum databases are making the problems worse. The reason that invalid iNES headers are so common is because they don't NEED to be valid on Joe Blo's 1337 Emulator (because it has a kewl MD5 database!) Stop supporting invalid ROMs!
A better idea would be to provide the ultimate cross-platform iNES to UNIF conversion utility (this probably already exists, minus the cross-platform part) that uses the MD5 database. Then when people have questions about why DiskDude ROM #20858 doesn't work on my emulator, I can point them to this utility which converts it into a corresponding UNIF ROM that works on any modern emulator. That way I don't have to maintain a ROM database.
I agree for the most part -- although an iNES->UNIF converter doesn't seem like a feasable option.
There simply aren't enough established UNIF board names to make it a reasonable replacement for iNES. While generally most US releases will fit neatly into a UNIF file, more obscure games won't. Some iNES ROMs just simply do not have a UNIF equivilent. One of the reasons I never fully got on board with UNIF.
That's not to say UNIF couldn't be a viable replacement if it were more complete. But as it stands now, it just doesn't fit the bill.
Disch wrote:
I agree for the most part -- although an iNES->UNIF converter doesn't seem like a feasable option.
There simply aren't enough established UNIF board names to make it a reasonable replacement for iNES.
There are regions BTL, HVC, and NES. For conversion of boards whose names are unknown, make a new region "INES" where the boards correspond to the mapper numbers. For instance, "INES-000" would be interpreted as a synonym for NES-NROM-256 or (if lacking CHR ROM) NES-BNROM, "INES-002" would be equivalent to NES-UOROM, etc. True, this isn't the best option in the long term, so a ROM checker would not classify a ROM using an INES-* board name as a [!] (verified good dump).
If you maintain the iNES mapper numbers, that pretty much defeats the whole point of using UNIF in the first place.
IMO, anyway.
In the same way that HTML 4.01 Transitional allegedly defeats the purpose of HTML + CSS?
Oh TNINES utility... A great old utility that was able to detect & repair bad iNES headers... Good times. ^_^;;
tepples wrote:
In the same way that HTML 4.01 Transitional allegedly defeats the purpose of HTML + CSS?
If I knew more about what you're talking about I might be able to comment =P
What I'm saying is... the whole purpose of UNIF was to avoid the ambiuity that comes with iNES. If you're just going to carry the ambiguities over to UNIF, what's the point of leaving iNES in the first place?
Adding a bunch of INES board names single-handedly defeats everything UNIF set out to accomplish. Mapper classification would be just as half-assed and unclear as it is in iNES -- and you'd have the added pain of
zero emulators supporting the new region.
You'd be better off sticking with iNES and just fixing the header so that the appropriate 'seldom-used' values are set properly. At least then the ROM will be treated properly in most emus (and probably still be runnable in emus which ignore the seldom-used bytes). That will make the ROM more "proper" without breaking its compatibility with existing emulators... or having to bastardize UNIF in the process.
tepples wrote:
In the same way that HTML 4.01 Transitional allegedly defeats the purpose of HTML + CSS?
With HTML the content is likely being semi-regularly updated, so conversion to HTML + CSS can be done over time and you can finally eliminate legacy support from browsers. With NES cartridges, very little change is going on to the library of (mostly copyright-infringing) content available, so any legacy support will pretty much be forever. Converting iNES to UNIF by merely doing the equivalent of embedding the raw iNES file data into a UNIF file offers little advantage over the original iNES file. The only real point of making a UNIF out of the iNES PRG and CHR data is to allow proper specification of the cartridge's hardware.
(grasping at straws to keep it on-topic)
Then shouldn't your test ROMs be mapper 34 (BNROM), not mapper 0 (strictly NROM)?
34 seems a little weird.
If 0 is unsatisfactory, I'd say go with mapper 2 instead (more common -- same job)
Mapper 2 is good for 16 KB ROMs, but because $8000-$BFFF is undefined at power on, it's not for 32 KB ROMs unless you do a mapper write before reading $8000-$BFFF. BNROM is closer to the behavior of "mapper 0 without CHR ROM".
But aren't all blargg's test ROMs 16k anyway?
They are really 8K, since that's all my devcart has. I doubt I'll switch to mapper 24 or 2, since I want them to work with the most primitive mapper (i.e. none). Unless mapper 0 with no CHR ROM is really out of spec, I don't see a problem with it.
The NROM boards allegedly don't have the CHR write enable lines wired up. (A modded NROM board does, but not even UNIF has a structure to represent wirewrap modifications that don't correspond to the behavior of a commercial game's PCB.) The most primitive official board allowing CHR writing is BNROM; the second most primitive is the much more common UNROM/UOROM (which adds a 74*32 quad-OR gate to create a fixed section). With a PRG ROM of 16 KB (or less), behavior of B*ROM and U*ROM is identical.