Why do most/all NSF players seem to ignore the speed fields?

A while (about a year) ago I ripped a Gauntlet II NSF that included all of the sampled sound effects. Originally I thought to just set the NTSC/PAL playback periods to a much lower value than normal to simulate the samples being updated multiple times per frame, but no NSF player I tried seemed to actually honor those values and the NSF just played back at 60 Hz like normal.

I ended up ditching that idea and just cycle-timing the playback instead (and IIRC tried to simulate the somewhat uneven timing that occurs in the game itself), but it would have been nice to be able to use an actual timer like I originally planned. Are there any NSF players out there that would have actually played back my original rip attempt correctly?

I do tend to use the "correct" 60/50 Hz period values in my other NSF rips as well, regardless of whether or not it's actually needed, at least.

1. Because almost zero game rips use anything but the default. (The few that do may arguably be improper rips, too.) The speed field is largely only used by recently made music, and a lot of emulator authors just don't care about that stuff, I guess.

2. Because almost every NTSC rip uses a slightly inaccurate speed value (16666 vs 16639), so there's some justification for overriding what it says, anyway. This is the reason Disch deliberately omitted it from the NSFe format).

3. Some NSF rips have 0 in these fields, requiring a default substitute. You can't divide by zero, so this is one case where you're forced to ignore what's there.


IMO every software NSF player should support the speed value, but i think you'll find that in addition to ignoring that field, a lot of them don't support PAL at all, either, which is an even worse problem. My own solution was to give an option you can turn on to override the default values, but otherwise just use what's in the file.


The proposed NSF2 format would add an IRQ capability to the specification, that you could potentially use for sample playback, but it's not really been nailed down yet (nobody's done a fully implemented version). When I'm done my game, I'm hoping to have time to spend on NSFPlay that I might be able to implement that during.


Deflemask also uses a cheezy/clever trick to run a timed sample loop interrupted by the play routine. By using SEI to mask interrupts, it can poll $4015 for the IRQ flag. This creates a nice pollable 60 Hz timer that you can check in your sample loop. I don't think this is technically a valid NSF (interrupts should be reserved for the implementation/hardware?) but it works on players that correctly implement the APU status and frame counter, and works on some hardware players like the PowerPak.

This was the reason I wrote my own NSF player: all the existing players I could find for Linux supported either expansion audio or nonstandard playback rates, which meant a large chunk of the Famicompo homebrew NSFs played correctly on exactly zero of them. PAL worked just fine on all of them, though.


Never heard of that one before. Do you have an NSF I can use to test my player? I haven't implemented IRQs, but I do have the APU IRQ flag.

I do plan to make Linux and Mac versions of NSFPlay eventually; mostly this requires a total rewrite of the user interface and better separation of the core stuff. (It's currently very dependent on MFC.)

Sorry, I don't have a suitable NSF to test the Deflemask trick at the ready. It's been a few years since I had to figure out that issue, but I would presume that there are demo NES songs that come with Deflemask that use PCM samples and could be exported to NSF. Deflemask is a free tracker, and it does run on Linux, AFAIK.