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:
Galaxian:
http://bootgod.dyndns.org:7777/profile.php?id=1808
Take a look at the PCB pics. Note that I haven't updated the ROM info to reflect it as 8KB ROM.
On a side note, regarding the site, it shouldn't be terribly much longer before the new version goes live. Lots of new functionality!
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.
So how would you deal with VS Tetris?
Is the bottom 8K mirrored, or the top 8K?
Al
The 24k is mapped to the last 3 8k pages. No clue what goes in the first 8k.
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.
What about interpreating iNES with "0 8kb PRG ROM banks" as a 8kb PRGROM ? Of course this will disallow 4kb and below, as well as 24kb.
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".
There are those reserved bytes at the end of the ines header, don't tell me nobody's ever going to use them.
Drag wrote:
There are those reserved bytes at the end of the ines header, don't tell me nobody's ever going to use them.
Nope, those are only reserved for the string "DiskDude!"
Drag wrote:
There are those reserved bytes at the end of the ines header, don't tell me nobody's ever going to use them.
The last time I heard about iNES 2.0 it used some of the bytes. I just don't know if any of them had anything to do with PRG-ROM smaller than 16KB.
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.
Quote:
There are actually quite a few games that stored their content on ROMs larger than needed, padding them out with mirrored data.
Wo can tell if it's not 2 ROMs of different sizes plus a decoder in a single IC package ?
Bregalad wrote:
Quote:
There are actually quite a few games that stored their content on ROMs larger than needed, padding them out with mirrored data.
Wo can tell if it's not 2 ROMs of different sizes plus a decoder in a single IC package ?
Back then, it would've been cheaper to just have a rom, bigger or not.