Also I'd like to discuss this part:
Code: Select all
Byte 9: Upper bits of ROM size
7 0
---------
CCCC PPPP
C: 4 more CHR ROM size bits
P: 4 more PRG ROM size bits
If P/C has the value $F, header bytes $4/$5 changes meaning from number of 16 KiB/8 KiB PRG/CHR banks to the following floating-point-like format:
7 0
---------
EEEE EEMM
|||| ||++- Multiplier, actual value is MM*2+1 (1,3,5,7)
++++ ++--- Exponent (2^E), 0-63
The actual PRG- or CHR-ROM size therefore becomes 2^E * (MM*2+1). This allows for ROM sizes larger than the current maximum of 64 MiB without too much padding.
I believe that this change of meaning of $F should be removed completely. There are a lot of reasons:
1. It breaks compatibility with old specification which allowed $F.
2. So, it reduces the maximum effective size which is possible to specify if you want to keep compatibility with the de facto NES 2.0 specification. It reduces it twice.
3. It makes a complicated and tangled format even more complicated and tangled.
4. It is very approximate, you can't specify precise size.
5. None of the old emulators understand it. It is effectively the same as creation of an absolutely new header format. It makes no sense to imitate the structure of the iNES header in this case.
6. Actually, it is even worse. Old emulators will try to load it because it tries to imitate iNES format, and a file which uses the proposed change would look like a usual iNES file for them.
To handle the case when the ROM is so huge that the de facto NES 2.0 can't handle it, just increase the header size twice and put DWORDs for every value in question. To prevent old emulators from using this files with increased headers, and to distinguish files with default header size and with increased header size, just use NES 0x1B instead of NES 0x1A as a signature. It will prevent old software from loading this file with extended header size, because it would not be able to load it anyway.
Conclusion: we have 16 bytes in the default iNES header. It makes sense to add new fields which preserve compatibility with iNES, otherwise it does make no sense to keep ourselves in the window of 16 bytes. So, adding a field which describes which input device is preferred is a nice idea. If I specify this field, newer emulators would take advantage of it, older emulators would just work as before, everyone is happy. But changing format in a way which literally breaks everything makes no sense if you try to keep compatibility with iNES. Just increase the header size, make it intentionally incompatible by changing of the signature, and the problem is solved. Moreover, it will not introduce additional problems, because old software will understand that it don't know how to handle such files right from the beginning of reading a file, because of the signature.