NSF - Initializing a tune

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
NSF - Initializing a tune
by on (#178576)
According to the wiki, initializing a tune involves clearing RAM and resetting APU registers, among a few other things. What about resetting the registers of other sound chips if they are used? Should they be zeroed out?
Re: NSF - Initializing a tune
by on (#178578)
I think the zeroing of the APU is because it's part of the power on state, and as a result when trying to rip NSFs some games actually rely on this, and thus there's no code in the game that initializes it (e.g. the Mega Man vs Game Genie sweep problem). I'm not sure why the spec recommends $0F to $4015, but there are a bunch of old NSF rips which rely on it.

This is not true of any of the expansion chips, if I recall correctly, so I'm not sure there's a similar need to apply this idea to expansions as well. It might be reasonable to expect the NSF to handle any needed initialization in INIT.

If you're writing an emulating player, you might want to create a consistent pre-INIT state anyway, for determinism's sake. If you're writing a hardware player, I dunno what to recommend. If you're making an NSF rip with expansion sound, definitely do the initialization yourself in INIT (existing players are inconsistent about pre-INIT expansion state).

There's a few enable registers that are often not emulated but really important to initialize when testing on hardware:

VRC6 $9003 should be $00 (halt / frequency multipler control).
FDS $4023 should be written with bit 1 set (sound enable).
N163 $E000 bit 6 disables sound if set.
Re: NSF - Initializing a tune
by on (#178598)
My NSF player writes $80 to $4080, $E8 to $408A and clears N163 memory to $00.

Unfortunately, I don't seem to have recorded why. I'm pretty sure the $408A write is required for rips that assume the FDS BIOS has initialized it, and I vaguely recall the rest being hacks to silence stuck notes when switching tracks.
Re: NSF - Initializing a tune
by on (#178602)
Oh yeah, I forgot about the FDS BIOS. According to the notes I left in the NSFplay source code, the BIOS makes 4 pertinent writes:
Code:
    // NOTE: the FDS BIOS reset only does the following related to audio:
    //   $4023 = $00
    //   $4023 = $83 enables master_io
    //   $4080 = $80 output volume = 0, envelope disabled
    //   $408A = $FF master envelope speed set to slowest
    Write(0x4023, 0x00);
    Write(0x4023, 0x83);
    Write(0x4080, 0x80);
    Write(0x408A, 0xE8); ; Edit: this was erroneously FF before.

An FDS implementation should probably pre-initialize to this, since any FDS game could rely on it.

Edit: corrected write to $408A, see below.
Re: NSF - Initializing a tune
by on (#178606)
I think that last one should be $E8, not $FF; check the wiki's talk page on FDS audio and the FDS BIOS disassembly it refers to (ctrl-f $408A).
Re: NSF - Initializing a tune
by on (#178609)
Ah! Thank you for that correction. That's been there on the Wiki since $2009. I'm embarrassed to say I must never have verified it myself, because you are correct, it is $E8. I'll fix the Wiki (and later NSFplay).
Re: NSF - Initializing a tune
by on (#179016)
@rainwarrior @Rahsennor Thanks for the suggestions.

rainwarrior wrote:
If you're writing an emulating player, you might want to create a consistent pre-INIT state anyway, for determinism's sake.


That's what I ultimately decided to do. Instead of resetting the audio modules via memory-mapped register writes, it turned out to be much simpler to just execute a reset routine on them.