Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
I'm running into a strange interaction between FamiTracker-exported NTSC NSF files and FCEUX.
When FamiTracker exports an NTSC NSF, it sets the NSF header's 0x7A byte value to "2". According to the NSF header spec, setting bit 0 to "0" means NTSC, setting bit 0 to "1" means PAL, and setting bit 1 to "1" means "dual PAL/NTSC". I can't find any explanation for what dual PAL/NTSC means, but it seems to me that this bitmapped specification is ambiguous -- what would be the difference between a byte value of "2" and "3", for example?
When FamiTracker exports a PAL NSF, if sets the 0x7A header byte value to "1". Nothing seems ambiguous about that.
The strange interaction happens when I use FCEUX play these NTSC NSFs with a 0x7A byte value of "2". In Windows, FCEUX interprets "2" as "nonzero", and thus sets the "PAL Emulation" menu option to on (which is a bug), but then it goes ahead and plays the file as NTSC. In Linux, FCEUX also interprets "2" as "nonzero", and thus PAL (same bug), but then it goes ahead and plays parts of the file as PAL (another bug). The PAL behavior I noticed is that it uses PAL noise wavelengths instead of the NTSC.
I've looked at the FCEUX source, and I'll talk to the FCEUX crowd about that bug, but my question for FamiTracker fans is: why does FamiTracker use a 0x7A "2" instead of a "0" for NTSC NSFs?
Versions used:
FamiTracker 0.3.6
FCEUX 2.1.5 Windows
FCEUX 2.1.5 Linux (SDL)
Have you made sure to leave the "set PAL flag in the NSF header" check box unchecked when exporting NTSC NSF files?
As for the bit value, you have to look at it in two digits:
00
If the left-most digit is set to 0, that tells the ROM/NSF that it's programmed for a single TV system. Setting it to 1 will tell the ROM that it can run on both systems.
If the right-most digit is set to 0, the primary system is NTSC. Setting it to 1 makes the primary system PAL.
00 means NTSC only. 01 means PAL only. 10 means dual NTSC/PAL, with the primary system as NTSC. 11 means NTSC/PAL, with the primary system as PAL.
As you can tell, if the ROM is dual NTSC/PAL, it's kind of redundant to set a primary TV system, as it's supposed to work on both without any frequency changes (unless the ROM itself isn't programmed to compensate for any frequency change when run on different NES consoles).
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
In other words, my question is: why is the dual bit set by default on NTSC? Or, more practically: is there any way for me to clear that bit?
It's just that with the previously-mentioned FCEUX bug, I have to manually edit the 0x7A byte from "2" to "0" to get songs to fully behave as NTSC. If/when FCEUX fixes the bug I won't have to do that anymore, of course.
Hi Phytopep. The dual mode bit is set because the driver is capable of playing the tune on both NTSC and PAL systems, the playback speed and pitch table is adjusted according to the system. There is no way to clear that bit other than selecting PAL. Maybe it would be a good idea to let the user select this in future releases.
The reason the bit is not set when PAL mode is selected is because it appears most NSF players can't handle that. Ideally both bit's set would mean a dual mode song with PAL emulation selected, but I don't think any NSF player does that.
Just interpreting the byte as PAL mode when it's non-zero is indeed a bug and should be corrected, as you mentioned.
Well, if the dual mode bit is set, the NTSC/PAL bit is meaningless, isn't it? They're for supported platforms, I think, not a preference. It's up to the user/program to decide which to use in dual mode. (Emulators I've tried do seem to treat it this way).
) 
