NSF - Initializing a tune

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

NSF - Initializing a tune

Post by zeroone »

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?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF - Initializing a tune

Post by rainwarrior »

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.
Rahsennor
Posts: 479
Joined: Thu Aug 20, 2015 3:09 am

Re: NSF - Initializing a tune

Post by Rahsennor »

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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF - Initializing a tune

Post by rainwarrior »

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: Select all

    // 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.
Last edited by rainwarrior on Tue Sep 06, 2016 3:08 pm, edited 1 time in total.
Rahsennor
Posts: 479
Joined: Thu Aug 20, 2015 3:09 am

Re: NSF - Initializing a tune

Post by Rahsennor »

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).
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF - Initializing a tune

Post by rainwarrior »

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).
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: NSF - Initializing a tune

Post by zeroone »

@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.
Post Reply