When dealing with the iNES format, do you have any option besides mirroring it out to 16KB? I've actually come across a game that only uses an 8KB PRG:
As for the iNES header, I'm no expert but what I know is that you can only set 16k banks only.
BootGod wrote:On a side note, regarding the site, it shouldn't be terribly much longer before the new version goes live. Lots of new functionality!
I have a question regarding your site. Is it possible to have a local version or do you plan do do one? That would be sometime useful and that would avoid to burn your bandwidth limit when we do mindless search in it
There's nothing to do but mirror it while noting the true size. Galaxian is the best known 8KB PRG game, but there are probably a few others not to mention a ton of firmware. It's just not something that could ever be enforced without widespread emulator hacks.
If you assume that no actual ROM will ever contain exactly mirrored contents (or don't mind if such a ROM looks like a smaller one of the unmirrored contents), then iNES can represent PRG ROM sizes of any power of 2, down to 1 byte. To "decode" such sizes, if the iNES file has 16K PRG then the data must be scanned to determine how many times the contents are mirrored. This isn't much of a problem since the size of the ROM rarely needs to be determined (certainly not for running the program). It may be less clean this way, but it really does represent the same information that a file with no mirroring would represent.
VS Tetris has a PRG size of 24k.
For that matter, VS Tetris is really weird since it's a licensed version of Tengen's [Atari Games's] version of Tetris.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Either the ROMs are decoded with A14 and A13 and the first page is open bus (unless there are 3x 8K ROMs where it'd be possible to partially decode one of them with dual decoders) or only A14 is used and the low data is mirrored. It's probably mirrored.
That would break compatibility with current programs. Why do that when you don't have to? (as I described in my previous message) Anyway, treating zero specially only adds direct support for one other size between 1 and 16384 bytes; it still doesn't directly handle all the other possible sizes in that range.
This is a job for iNES 2.0! Seriously, did it have provisions for small ROMs? The 0 could mean "smaller than 16KB, go get the exact size from some other byte".
blargg wrote:If you assume that no actual ROM will ever contain exactly mirrored contents (or don't mind if such a ROM looks like a smaller one of the unmirrored contents), then iNES can represent PRG ROM sizes of any power of 2, down to 1 byte. To "decode" such sizes, if the iNES file has 16K PRG then the data must be scanned to determine how many times the contents are mirrored. This isn't much of a problem since the size of the ROM rarely needs to be determined (certainly not for running the program). It may be less clean this way, but it really does represent the same information that a file with no mirroring would represent.
There are actually quite a few games that stored their content on ROMs larger than needed, padding them out with mirrored data. The new DB records physical ROM size in addition to the size of the utilized data, so you can easily find games like that.
It's certainly easy enough to simply mirror the data when writing in the iNES format, the crappy part is you would still have to keep a copy of the 16K CRC in order to detect the mirrored ROM again in a scan.
