iNES header: size 255 == 256?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
iNES header: size 255 == 256?
by on (#197015)
Should values of 255 for number of PRG/CHR pages be treated as the number 256?
Re: iNES header: size 255 == 256?
by on (#197020)
No. If you're going to change your header logic, you might as well add NES2.0 byte9 support… in which case it's $FFF=$1000 instead of $FF=$100 that you'd be asking the question on.
Re: iNES header: size 255 == 256?
by on (#197023)
Dwedit wrote:
Should values of 255 for number of PRG/CHR pages be treated as the number 256?

Is there a ROM with a 4MB PRG / 2MB CHR that you are trying to accommodate? Is this something other emulators currently do?

Unless that's the case, I don't see why you should special case one value to not mean what it says. (...and iNES 2 is sufficient for new homebrew, if it should ever arise.)
Re: iNES header: size 255 == 256?
by on (#197039)
I think it would be confusing as hell to give special treatment to a single value, while many others are just as useless. The proper way to handle PRG-ROM of sizes 4MB and up, as well as CHR-ROM of sizes 2MB and up, is the NES 2.0 format.
Re: iNES header: size 255 == 256?
by on (#197054)
tokumaru wrote:
The proper way to handle PRG-ROM of sizes 4MB and up, as well as CHR-ROM of sizes 2MB and up, is the NES 2.0 format.

Might also point out that in the new header format the "old" PRG byte will be 0, so if you're going to special case something to be 4 MB a value of 0 might make more sense than 255? (For PRG, at least.)

(Though I still don't understand its purpose unless an existing common ROM already uses it.)
Re: iNES header: size 255 == 256?
by on (#197058)
rainwarrior wrote:
Might also point out that in the new header format the "old" PRG byte will be 0, so if you're going to special case something to be 4 MB a value of 0 might make more sense than 255? (For PRG, at least.)

Good point.

Quote:
(Though I still don't understand its purpose unless an existing common ROM already uses it.)

Yeah, still waiting for clarification on whether this is a suggestion for a new "feature" (in which case "absolutely no" would be my answer - if you're gonna add something to an emulator, better add NES 2.0 support than this hack) or if some existing ROM expects this to be the case.
Re: iNES header: size 255 == 256?
by on (#197120)
I do kind of agree with the sentiment that the spec is very wasteful, since there's only maybe 13 useful values in the 12-bit bitfield (or 9 in the 8-bit iNES 1 version).

It's also kind of hilarious that there is already a homebrew release that is 16k too large to fit in iNES 2:
http://www.retrousb.com/product_info.php?cPath=36&products_id=143

Feels like those 4 bits would have been better spent as a PRG * 2x multiplier instead of PRG * x. :P

In that respect, maybe not a 255 to 256 promotion since we do have a format that supports 4MB ROMs already, but what about 4095 to 4096 at the limit of the new format? Or you could add 4 more bits to the spec and wait for somebody to make the 1GB ROM that breaks it. :S
Re: iNES header: size 255 == 256?
by on (#197135)
rainwarrior wrote:
Feels like those 4 bits would have been better spent as a PRG * 2x multiplier instead of PRG * x. :P

I agree, however it is still theoretically possible to combine different sized EPROMs get non-power-of-2 sizes on the NES, even if I don't think it was ever done. The only few Nintendo-made game that combines EPROMs combines two of the same size. On the SNES it was done frequently.
Re: iNES header: size 255 == 256?
by on (#197138)
Action 52 used 3 PRG ROMs. That's the only one I know of but there might be others. That's actually why I said 9 useful values instead of just 8.

Though, even that one is fine with theoretical power of 2 multiplier scheme I just proposed as a whim. The multiplier would just change the smallest representable multi-ROM unit from 16k to some other power of 2 size... you could still specify e.g. 113 * 1MB ROMs, for example, if that somehow wasn't insane. What's the downside? Overdumps if some very strange multi-ROM combination ever comes up? Is that even a real problem? We already have to do that for one 8k Famicom ROM. Any non-power-of-2 ROM size is going to be a custom mapper anyway to specify what happens to the "missing" address space (duplicate? open bus? used to control something else? ignored?), what does it matter if the ROM has slightly more data than necessary in it...? It'll just be zero fill that compresses to nothing anyway.

Anyhow, I'm not really proposing to change iNES 2, I'm just pointing out that it's already "not good enough" for one real homebrew, for basically the same reason OP started this thread. (How many existing ROMs are relying on the extended PRG size bits at this point anyway? Is it not too late to change? Would anyone want to?)
Re: iNES header: size 255 == 256?
by on (#202863)
A floating-point encoding would be very efficient here. With just six bits, PRG/CHR-ROM size (in bytes) could be encoded as 1.mm * 2eeee+13 (mm = mantissa bits, eeee = exponent bits), and we'd have the following options:

8 kB, 10 kB, 12 kB, 14 kB,
16 kB, 20 kB, 24 kB, 28 kB,
32 kB, 40 kB, 48 kB, 56 kB,
64 kB, 80 kB, 96 kB, 112 kB,
128 kB, 160 kB, 192 kB, 224 kB,
256 kB, 320 kB, 384 kB, 448 kB,
512 kB, 640 kB, 768 kB, 896 kB,
1 MB, 1.25 MB, 1.5 MB, 1.75 MB,
2 MB, 2.5 MB, 3 MB, 3.5 MB,
4 MB, 5 MB, 6 MB, 7 MB,
8 MB, 10 MB, 12 MB, 14 MB,
16 MB, 20 MB, 24 MB, 28 MB,
32 MB, 40 MB, 48 MB, 56 MB,
64 MB, 80 MB, 96 MB, 112 MB,
128 MB, 160 MB, 192 MB, 224 MB,
256 MB, 320 MB, 384 MB, 448 MB

[edit: of course there'd have to be a special code for no CHR-ROM]
Re: iNES header: size 255 == 256?
by on (#202898)
qalle wrote:
[edit: of course there'd have to be a special code for no CHR-ROM]

And of course, it breaks compatibility with existing iNES headers, unless I've seriously mistaken something.
Re: iNES header: size 255 == 256?
by on (#202934)
Instead of re-interpreting bits that have already been defined, it would be easier to simply take advantage of the still-reserved bytes in the header. Bytes 14 and 15 are still undefined. If Byte 14's 8 bits were defined to be bits 13-20 of the PRG size field, then NES 2.0 would be able to specify 16 gigabytes of PRG. If we wanted to split byte 14 between PRG and CHR, then growing PRG's size field from 12 to 16 bits would still specify up to gigabyte of PRG.
Re: iNES header: size 255 == 256?
by on (#202943)
How likely are we to get multi-GB memories in a cartridge that aren't "seek and read a stream" memories like SPI, eMMC, or microSD flash? And a cartridge that does end up using seekable memory will still need a boot ROM. The other instances involving a boot ROM use two files, one for the boot ROM and one for the rest of the data.

  • Famicom Disk System: The menu is in one ROM file and the disk images are in other files.
  • PowerPak: The menu is in one file (whose source code is loader.asm here), the loadable modules are in other files (.map), and executables are in other files (.nes).

So I'd not be too hasty about defining a single-file format for these until we actually have an example. The first emulator for a game that uses seekable memory could use two files, just as emulators already do for FDS.
Re: iNES header: size 255 == 256?
by on (#202954)
Bregalad wrote:
And of course, it breaks compatibility with existing iNES headers, unless I've seriously mistaken something.

Yeah, I was just thinking in hindsight how the size fields should've been implemented. I don't propose breaking the format.
Re: iNES header: size 255 == 256?
by on (#203133)
tepples wrote:
How likely are we to get multi-GB memories in a cartridge that aren't "seek and read a stream" memories like SPI, eMMC, or microSD flash?
Never.

The largest parallel NOR flash ever manufactured is 2 Gibit (256 MiB).

Costs on these huge parallel NOR flash make them the ≈wrong choice for any modern design. There just isn't the demand for larger systems that use ROM and XIP instead of having a memory controller, so it's more economical to choose a microprocessor with the ability to boot from NAND flash and copy stuff on demand into RAM.