iNES header: size 255 == 256?

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

iNES header: size 255 == 256?

Post by Dwedit »

Should values of 255 for number of PRG/CHR pages be treated as the number 256?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: iNES header: size 255 == 256?

Post by Myask »

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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: iNES header: size 255 == 256?

Post by rainwarrior »

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.)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: iNES header: size 255 == 256?

Post by tokumaru »

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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: iNES header: size 255 == 256?

Post by rainwarrior »

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.)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: iNES header: size 255 == 256?

Post by tokumaru »

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.
(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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: iNES header: size 255 == 256?

Post by rainwarrior »

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.ph ... cts_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
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: iNES header: size 255 == 256?

Post by Bregalad »

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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: iNES header: size 255 == 256?

Post by rainwarrior »

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?)
qalle
Posts: 50
Joined: Wed Aug 16, 2017 12:15 am

Re: iNES header: size 255 == 256?

Post by qalle »

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]
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: iNES header: size 255 == 256?

Post by Bregalad »

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.
User avatar
LightStruk
Posts: 45
Joined: Sat May 04, 2013 6:44 am

Re: iNES header: size 255 == 256?

Post by LightStruk »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: iNES header: size 255 == 256?

Post by tepples »

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.
qalle
Posts: 50
Joined: Wed Aug 16, 2017 12:15 am

Re: iNES header: size 255 == 256?

Post by qalle »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: iNES header: size 255 == 256?

Post by lidnariq »

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.
Post Reply