TV System byte extension in iNES, NES 2.0, UNIF, NSF, NSFe

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

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

Re: TV System byte extension in iNES, NES 2.0, UNIF, NSF, NS

Post by VEG » Fri Dec 21, 2018 3:10 pm

Sour wrote:What's the benefit "Dendy with NTSC fallback"?
If an emulator doesn't support Dendy for some reason, it will use NTSC. Also, if an old emulator (which isn't aware of changes in the spec) treats bit 0 to distinguish between NTSC and PAL ROMs (as spec says), it will use NTSC. We shouldn't change meaning of bit 0 if we care about compatibility. Old emulators should handle new files which use new features (and old mappers) properly. Otherwise I would not use the new features of the format.

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

Re: TV System byte extension in iNES, NES 2.0, UNIF, NSF, NS

Post by rainwarrior » Fri Dec 21, 2018 3:39 pm

I said this already but most old emulators don't use any bits of the header to determine PAL vs NTSC.

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

Re: TV System byte extension in iNES, NES 2.0, UNIF, NSF, NS

Post by VEG » Thu Jan 10, 2019 1:13 am

rainwarrior wrote:I said this already but most old emulators don't use any bits of the header to determine PAL vs NTSC.
It is not true. I have checked at least a few emulators (Mesen, FCEUX), and they use this bit. "Old emulators" means not only emulators from 90's and 00's, it means all the emulators before 2019, when the extension probably will be added to the spec.

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

Re: TV System byte extension in iNES, NES 2.0, UNIF, NSF, NS

Post by VEG » Thu Jan 10, 2019 1:26 am

Oh, I see that NewRisingSun has already forced his own proposal to the NES 2.0 spec on the nesdev wiki. Congratulations. You've just made NES 2.0 worse. I was interested in the feature of the format, but I won't use this extension because of its drawbacks and poor backward compatibility.

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

Re: TV System byte extension in iNES, NES 2.0, UNIF, NSF, NS

Post by rainwarrior » Fri Jan 11, 2019 2:03 am

VEG wrote:
rainwarrior wrote:I said this already but most old emulators don't use any bits of the header to determine PAL vs NTSC.
It is not true. I have checked at least a few emulators (Mesen, FCEUX), and they use this bit. "Old emulators" means not only emulators from 90's and 00's, it means all the emulators before 2019, when the extension probably will be added to the spec.
FCEUX does not use the old late addition iNES 1 TV field. It either uses iNES 2, or it uses the filename:
https://github.com/TASVideos/fceux/blob ... s.cpp#L916

Mesen does have this code, though also seems to have header sanitization that clears it out before even looking at it, which is a bizarre paradox? However, whether or not it actually could use byte 9, Mesen is not an old emulator, not even close.

The vast majority of PAL ROMs out there do not use this field, and a lot of NTSC ROMs have garbage here too, so in almost all cases it's useless for identifying when to use PAL mode. I'm not going to spend hours digging up more code examples, but IIRC Nestopia just used a ROM CRC and header database to figure this out. FCEUX used the filename, like I just pointed out. Other solutions are just as ad-hoc. Byte 9 was never a de-facto standard solution for determining iNES 1 region.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: TV System byte extension in iNES, NES 2.0, UNIF, NSF, NS

Post by Sour » Fri Jan 11, 2019 5:25 am

rainwarrior wrote:Mesen does have this code, though also seems to have header sanitization that clears it out before even looking at it, which is a bizarre paradox?
That code is only run if the header's PRG size is greater than the ROM's actual size (to prevent out of bounds memory accesses), so byte 9 isn't set to 0 normally.

That being said, I don't think I've ever actually seen a rom that used byte 9 to specify NTSC vs PAL..

Post Reply