WedNESday wrote:I think that it is unreasonable just to check to see how much PRG bank there are too see if a ROM has UNROM or UOROM.
You think wrong. I'm under the impression that memory sizes are exactly what Nintendo used to decide which board to use when manufacturing a game. Look at all the SxROM and TxROM boards that differ only in memory size. For example, MMC1 + PRG ROM over 256 KiB + 8 KiB CHR RAM + 8 KiB PRG RAM = SUROM.
How on earth are we going to go back and find all of these ROMs and actually update them so that they are 2.0 compatible?
bsnes includes a "purify" tool that scans ROMs and corrects their headers. (In the case of Super NES ROMs, "correcting" involves stripping the copier header entirely.) A similar tool for NES emulation could scan a collection of iNES ROMs, possibly using a database of commercial releases prior to 1997 as lidnariq mentioned, and convert them to the equivalent NES 2.0 header.
Under where it says 'proposed' solution. Should that adjective still be there or is it safe to assume that all data present can be safely implemented?
As far as I can tell, it's been a stable spec for several years, and even implemented in a few emulators.
Regardless of what iNES was ever supposed to be, it is what it needs to be and that is to carry all of the necessary cartridge information that would influence its emulation.
Which in turn is also all of the necessary cartridge information that would influence its reproduction, apart from label graphics. Tetris by Tengen is CNROM unless you don't consider Tengen's clone board to be CNROM. Battle Kid 1 is UOROM unless you don't consider the ReproPak board to be UOROM.
I care whether a ROM is UNROM or UOROM (Mapper 2 btw) because UOROM uses an extra bit when mapping ROM to 8000. I consider checking to see whether a ROM is either 128kB or 256kB a sloppy way of checking a mapper's board.
Then Nintendo was sloppy.
To be more precise I'm more interested in mappers that have a lot of boards like MMC3.
If you look at the TxROM page on the wiki, you'll find that apart from TxSROM and TQROM, the only difference between most of them and TSROM/TLROM is the maximum supported ROM size.
lidnariq wrote:It is only "sloppy" if you think it is meaningful to talk about how UxROM is actually a subset of mapper 78 or something.
Or, for a more extreme example, how AMROM, ANROM, AOROM, BNROM, CNROM, NROM, UNROM, and UOROM have been retroactively made subsets by multicart mapper 28. I'm aware of one FPGA implementation of the NES that uses the mapper 28 code path to emulate mappers 0, 2, 3, 7, and 34 (CHR RAM variant).