NES 2.0 "Official" Specification

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 "Official" Specification

Post by VEG »

My interpretation (with the proposed Dendy flag):

Code: Select all

Byte 12:
7       0
---------
xxxx xDBP
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
0000 0100 - Dendy only, but if Dendy mode isn't available in the emulator, use NTSC
0000 0101 - Dendy only, but if Dendy mode isn't available in the emulator, use PAL
0000 0110 - Supports Dendy, NTSC and PAL. Dendy mode is preferred, but if Dendy mode isn't available in the emulator, it will use NTSC
0000 0111 - Supports Dendy, NTSC and PAL. Dendy mode is preferred, but if Dendy mode isn't available in the emulator, it will use PAL
It's simple and almost all cases are covered. The only drawback that I can see is that we can't indicate that the ROM supports, for example, Dendy and NTSC modes only. But I don't know why it may be needed.
IMHO, the bit B is not a very useful flag. I doubt if it is used by any emulator.
Last edited by VEG on Sun Oct 09, 2016 11:49 pm, edited 4 times in total.
VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 "Official" Specification

Post by VEG »

Myask wrote:Still think that NTSC should have its own bit instead of this extensibility-poor "both" here. A Dendy bit would be fine too.
The idea to have some kind of mask of which systems are supported in this ROM is nice. So, it will be bits N for NTSC, P for PAL, and D for Dendy. As the result we will be able to set only P and D, or N and D, or N and P, or all of them. Also we have to have a way to tell the emulator which mode is preferred. For example, Unchained Nostalgia supports PAL, NTSC and Dendy, but Dendy mode is preferred, and if it is not supported, NTSC mode is preferred.

We have to take into account how B and P bits are treated by modern emulators. As far as I understand, they use NTSC when bit P is clear, and PAL when bit P is set. Am I right? How modern emulators treat the B bit? If they ignore this bit, maybe it is possible to change the meaning of this bit.
VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 "Official" Specification

Post by VEG »

NSF spec:
$07A 1 BYTE PAL/NTSC bits
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
NSFe spec:
$0006 1 BYTE PAL/NTSC bits
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
So, this byte is similar everywhere and new extension will be applicable to these formats also =)
VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 "Official" Specification

Post by VEG »

NSFe has an additional regn section for Dendy support now: https://wiki.nesdev.com/w/index.php/NSFe#regn
But I believe that we could extend the byte which describes which systems are supported and preferred in the NES, NSF and NSFe. Everywhere in the same way.

My old proposition (with the Dendy flag):

Code: Select all

Byte 12:
7       0
---------
xxxx xDBP
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
0000 0100 - Dendy only, but if Dendy mode isn't available in the emulator, use NTSC
0000 0101 - Dendy only, but if Dendy mode isn't available in the emulator, use PAL
0000 0110 - Supports Dendy, NTSC and PAL. Dendy mode is preferred, but if Dendy mode isn't available in the emulator, it will use NTSC
0000 0111 - Supports Dendy, NTSC and PAL. Dendy mode is preferred, but if Dendy mode isn't available in the emulator, it will use PAL
It's simple and almost all cases are covered. But still, it has a drawback: you can't state that a ROM supports Dendy and NTSC only, and can't choose a preferred system separately from the list of supported systems.

So, I have an improved proposition. Let's divide the byte into two nibbles. One part describes which systems are supported, the other one describes which system is preferred.

Code: Select all

Byte 12:
7       0
---------
xdpn xxBP

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 (a legacy emulator will use NTSC, and it is good, because Dendy is closer to NTSC)

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.
It seems, that the latter proposition has no drawbacks. It should work perfectly in legacy and in new emulators which support the new NES specification.

Let's extend meaning of this byte in the NES, NSF and NSFe formats! A lot of emulators support Dendy, but this mode can't be utilized in convenient way for ROMs which were designed for Dendy. We really need this extension.

Also I'm curious, why NES 2.0 devotes byte 12 for the TV System while the original iNES 1.0 devotes byte 9 for the same purpose?
Post Reply