It is currently Thu Aug 22, 2019 7:32 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Mon Jul 01, 2019 9:38 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21560
Location: NE Indiana, USA (NTSC)
I'm working on a project related to multichip NSF. One problem I'm seeing is that the Sunsoft 5B's YM2149 data port and the silence registers of the VRC7 and N163 are all at $E000. This means any YM2149 data with bit 6 true will cause N163 and VRC7 to stop playing sound. Should the NSF spec be clarified to explicitly hide $E000 writes from N163 and VRC7?

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 9:59 am 
Offline
User avatar

Joined: Sun Jun 05, 2016 2:10 am
Posts: 234
Location: Canada
The silence registers should be ignored. There's not much practical purpose for them since NSFs not using the expansion audio may just not set the expansion's bit in the header, and if they really do need to completely mute the expansion it isn't so difficult to just zero out all of the chip's registers.


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 10:15 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8533
Location: Seattle
The register mask for the VRC7 is $F028 or $F030, the register mask for the N163 is $F800, and the register mask for the SS5B is $E000. So there's choices that will work to get data into the 5B that won't alias on top of the mute controls.

However, some NSF emulators will fully decode the playback registers to handle multi-expansion NSF.


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 10:16 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7565
Location: Canada
Multi-chip has a ton of little details like this.

A note about it on the wiki in the multi-chip section, like tepples has already added is good. I don't think "resolution is pending" is necessary. The exact solution to use here should be carefully considered by the implementer. Hardware players especially have different necessities here than an emulating player as they have to write to these registers to initialize the cart. Describing the problem is important, but I don't think a specific solution should be specified as if it is a done deal.

Describe the problem, describe what can be done, and also describe what is done if you're able to survey it. See the similar note about FDS write protect.

"Ignore the $E000 register for VRC7/N163 + 5B" is a very reasonable solution for emulators, but don't just give people the expectations that all emulators already do this. "Avoid writing $E000 with bit 6 set" is very compromised might be a viable workaround for an NSF author who wants good backward compatibility.

However, if making that suggestion please explicitly restrict it just to multi-chip. I think you can compatibly just not implement those registers for N163 and VRC7 in general, but for accuracy VRC7's reset actually does have important consequences to synchronization. (N163 less so.)


Last edited by rainwarrior on Mon Jul 01, 2019 10:33 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 10:23 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7565
Location: Canada
lidnariq wrote:
The register mask for the VRC7 is $F028 or $F030, the register mask for the N163 is $F800, and the register mask for the SS5B is $E000. So there's choices that will work to get data into the 5B that won't alias on top of the mute controls.

However, some NSF emulators will fully decode the playback registers to handle multi-expansion NSF.

It's one way to resolve it, but I think more than one NSF emulator currently only accepts the "canonical" (lowest) address for audio device writes, either in multi-chip mode or always. There's a lot of conflicts that that solution resolves with that single rule, and It's been in the suggested implementations for a few years now.

So... it's not really viable in terms of current popular players, IMO. Probably just ignoring the register is a better idea, in general.


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 10:29 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7565
Location: Canada
If anyone has one of the TNS multi-cart devices, we may want to investigate how it addresses this, if it really addresses it. (It claims to support all expansions at once, but that doesn't necessarily mean it does it completely without compromise.)
http://www2s.biglobe.ne.jp/~tns/nr26730801.html

...and always keep in mind that just because some permutation of bits exists in the NSF header spec does not mean that it has to have a real solution. Not all combinations will be reasonable to support. For previous revisions of the TNS devices they had very explicit caveats about certain combinations. Multi-chip was a happy accident more than anything else.


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 10:34 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21560
Location: NE Indiana, USA (NTSC)
$E000 is the lowest address for both the VRC7/N163 silence regs and the 5B data port. Not resolving this would make 5B+N163 and 5B+VRC7 invalid combinations, and making those combinations invalid would trigger a PK [poop]storm on the FamiTracker.org Discord server.

I'm inclined to agree with Karmic: don't forward $E000 writes to those chips if 5B is present.

_________________
Pin Eight | Twitter | GitHub | Patreon


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 3 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