- 1 * 2k represents 1 ROM or 2 of equal size (e.g. After Burner CHR).
- 3 * 2k represents 3 ROMs (e.g. Action 52 PRG) or 2 ROMs, the first twice as big as the second (many Super NES games).
- 5 * 2k usually represents 2 ROMs, the first four times as big as the second (many Super NES games including Mega Man X and Street Fighter II Turbo).
BTW the PowerPak ROM loader relies on only power of 2 sizes in these fields, because it constructs its bank bitmask as "size-1". That's actually a pretty reasonable implementation that will cover all but a small handful of ROMs which mostly couldn't run on the PowerPak anyway.
And you argue with the least important point. The most important point is that it does not make any sense to imitate iNES header in this case. Introduction of such kludges have no any advantages over a completely new header format. Let's create a new proper header without these ugly hacks to cover situations which aren't covered by current NES 2.0 and can't be covered without breaking compatibility with old emulators.
Also, there already was a now-deprecrated iNES replacement that had DWORD size specifiers, called UNIF. One of the reasons for its deprecation was lack of popularity. That problem will be even greater here: nobody is going to support a new format just for a few large-size homebrew and pirate ROMs, but they might support an extension to an existing format plus one or two new mappers.
Let's get back to the TV System byte, because it is the extension which would be really useful if added to the iNES, NES2.0 and UNIF formats.
Just a reminder of the proposition:
Code: Select all
Byte 12 in NES 2.0 (or Byte 9 in iNES, or TVCI byte in UNIF): 7 0 --------- xdpn xxBP The byte consists of two nibbles. The higher nibble describes which systems are supported, the lower nibble describes which system is preferred. If higher nibble is 0, use legacy interpretation: 0000 0000 - NTSC only 0000 0001 - PAL only 0000 0010 - Supports NTSC and PAL, but NTSC is preferred 0000 0011 - Supports NTSC and PAL, but PAL is preferred Otherwise, higher nibble describes supported systems: d - Dendy p - PAL n - NTSC Lower nibble (bits BP) describes preferred system: 00 - NTSC (a legacy emulator will use NTSC) 01 - PAL (a legacy emulator will use PAL) 10 - Dendy with fallback to NTSC (a legacy emulator will use NTSC) 11 - Dendy with fallback to PAL (a legacy emulator will use PAL), or just reserved If the lower nibble chooses the system which is not marked as a supported system in the higher nibble, fallback to the legacy behavior. Bits 2,3 and 7 should be ignored by emulators, and should be 0 in ROMs.
There is a list of supported systems by a ROM, and a preferred system selected in the ROM. A user of an emulator can choose a preferred system in the settings of the emulator: Auto, NTSC, PAL, Dendy, Force NTSC, Force PAL, Force Dendy. If Auto is specified, emulator will always use the preferred system specified in the ROM itself. If the user chooses NTSC/PAL/Dendy as preferred, the emulator checks if the preferred by user system is supported by the ROM, and if it is, it should use the preferred by user system. Otherwise, it should use preferred by ROM system. And if the user chooses to force NTSC/PAL/Dendy, the emulator just ignores the byte in the header and always uses the forced system.
I know that NewRisingSun don't like this proposal, he has an own one which extends the same byte in a different way. This comment is an invite for others to state their opinions about such an extension.
There are a lot of things preventing this. The primary thing is that it would be cheaper and easier to build a 128K cartridge than a 64+8 cartridge. You're making an argument based on a thing that is more or less absurd to make, and nobody is going to.VEG wrote:Nothing prevents anybody from creation of a custom cartridge with 64+8KiB of PRG ROM, for example. I provide this amount of ROM as an example because I considered creation of such a mapper for some special purposes just a few months ago.
...and even if you DID build such a cart, you wouldn't need to use the extended bits anyway. It would just be listed as an 80k cartridge with the regular iNES 1 PRG size field, and there'd be 8k of padding. The point of the iNES 2 field (with or without the special $F proposal) is to extend the range of representable sizes, not accommodate pathologically hypothetical ROM sizes that fall in between the useful ones.
There is no need to duplicate that large block again here.Just a reminder of the proposition:
The same data (list of supported and a preferred system) is already available in the NSFe format.
So, it will be a feature parity between at least NSFe and NES 2.0
First of all, UNIF is supported by popular emulators. And I see no any reasons to remove its support. Second, it is not a mere header, it is much more complex. This format is an overkill for most cases, that's why it is not wide adopted. But it is used on special cases. For example, COOLGIRL multicarts use it, and UNIF really suits better this rare case.NewRisingSun wrote:Also, there already was a now-deprecrated iNES replacement that had DWORD size specifiers, called UNIF. One of the reasons for its deprecation was lack of popularity. That problem will be even greater here: nobody is going to support a new format just for a few large-size homebrew and pirate ROMs, but they might support an extension to an existing format plus one or two new mappers.
Galaxian 8KB PRG-ROM = 2^13 * 1 = #00110100 = $34
Here are some non-power of 2 PRG-ROM sizes I know of that can be represented by this system :
Vs. Tetris 24 = 2^13 * 3
Vs. Gumshoe 40 = 2^13 * 5
Vs. Raid on Bungeling Bay 40 = 2^13 * 5
I can't get it to work for these PRG-ROM sizes, but fortunately they are encompassed within a single submapper :
I was trying to get the number using the exponent-multiplier system, but it only went up to seven. I forgot that original system is 16K * 2^(Byte 4).NewRisingSun wrote:For 144 KiB, you just denote 9 16 KiB banks. The exponent-multiplier system is only used for sizes that could not be expressed before.
I am pleased we can finally express Galaxian's 8KB in an understandable format. Now everyone just needs to shut up and embrace the future of NES ROM identification
No, the original iNES system is just 16K *(Byte 4), and with NES 2.0, 16K * (Byte 4 OR ((Byte 9 AND $0F) SHL 8)).Great Hierophant wrote: I forgot that original system is 16K * 2^(Byte 4).