NES 2.0 Additions Proposal

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 Additions Proposal

Post by rainwarrior »

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

Re: NES 2.0 Additions Proposal

Post by tepples »

The only practical sizes for PRG ROM or CHR ROM are 1, 3, and 5 times a power of 2.
  • 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).
A ROM size leading with $F is none of these.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 Additions Proposal

Post by rainwarrior »

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.
VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 Additions Proposal

Post by VEG »

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.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

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.
VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 Additions Proposal

Post by VEG »

Yeah, let's make the messy NES 2.0 header format even more messier. More kludges, more hacks, more ugliness. For the sake of chaos and increasing of entropy. :twisted:

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

Re: NES 2.0 Additions Proposal

Post by rainwarrior »

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.
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.
Just a reminder of the proposition:
There is no need to duplicate that large block again here.
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: NES 2.0 Additions Proposal

Post by Eugene.S »

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
VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 Additions Proposal

Post by VEG »

I have created a dedicated topic about it, with some additional details: viewtopic.php?f=3&t=18060
I hope that it will help to involve other people into the discussion.
VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 Additions Proposal

Post by VEG »

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.
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.
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: NES 2.0 Additions Proposal

Post by Great Hierophant »

Regarding the exponent * multiplier way of determining ROM size, I think this is how it works :

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
Vs. Mahjong 48 = 2^14 * 3
Pegasus 5 in 1 1280 = 2^18 * 5
Action 52 1536 = 2^19 * 3
I can't get it to work for these PRG-ROM sizes, but fortunately they are encompassed within a single submapper :

Nantettatte!! Baseball Ko-Game Set '91 Kaimakuban 144
Nantettatte!! Baseball OB All Star Hen 144
Last edited by Great Hierophant on Fri Dec 07, 2018 3:55 pm, edited 2 times in total.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

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.
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: NES 2.0 Additions Proposal

Post by Great Hierophant »

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

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

Re: NES 2.0 Additions Proposal

Post by lidnariq »

In hindsight, having the table be {1,3,5,9} would make more sense than {1,3,5,7} — you can only get 7 by having three ROMs — but I really don't care enough to do anything more than point this out.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

How I love it when people care enough to post how much they don't care. :P
Great Hierophant wrote: I forgot that original system is 16K * 2^(Byte 4).
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)).
Post Reply