Emulators that haven't implemented that different meaning for $F aren't treating $F in a different way, they're not treating $F at all. It's simply an invalid size for a ROM, and no such ROM will ever exist. There is no conflict of meaning for it.

Also, hypothetically if there ever was a counterexample to this, for whatever insane reason, the only negative consequence is a small amount of padding (relative to the file size).

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.

Guys, don't be so short-sighted. 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 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.

You are not breaking compatibility with existing emulators: Along with the large ROM size must come a mapper that supports such large ROMs. An emulator not supporting the $F notation will also not support such mappers. When loading such a ROM, it will merely print "Mapper #342 not supported" and quit, not caring about the ROM size at all. A completely new NES header would instead produce a message such as "not a NES file" or "invalid file", which is much more confusing to the user. In the worst case, the old emulator compares the file size against the header ROM size before looking at the mapper number, and it would then complain about an unexpected end of file, which is no worse than getting "not a NES file".

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.

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.

Similar fields are already available in the NSFe format in the regn section. It would be nice to have the same ability in NES format also.

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.

Last edited by VEG on Sat Nov 17, 2018 12:55 am, edited 4 times in total.

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.

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.

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

I think than VEG's proposal is better. 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

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.

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.

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum