It is currently Wed Oct 18, 2017 11:48 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Mon Aug 29, 2016 2:53 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 709
Location: New York, NY
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?


Top
 Profile  
 
PostPosted: Mon Aug 29, 2016 3:11 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5717
Location: Canada
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.


Top
 Profile  
 
PostPosted: Mon Aug 29, 2016 10:50 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Aug 30, 2016 12:07 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5717
Location: Canada
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.


Last edited by rainwarrior on Tue Sep 06, 2016 3:08 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Aug 30, 2016 1:41 am 
Offline

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


Top
 Profile  
 
PostPosted: Tue Aug 30, 2016 3:23 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5717
Location: Canada
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).


Top
 Profile  
 
PostPosted: Tue Sep 06, 2016 1:15 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 709
Location: New York, NY
@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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group