Mirrored registers and multi-chip NSFs

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Mirrored registers and multi-chip NSFs
by on (#92065)
I've heard of NSF files using three or more expansion sound chips. But it has come to my attention that certain Famicom synths won't work together because their registers overlap. For example, it is believed that the Sunsoft 5B (address: $C000; data: $E000) and Namco 163 (address: $F800; data: $4800) overlap because the Sunsoft 5B's data port is thought to be mirrored in $E000-$FFFF. There's a workaround for this pair, namely to write $0E to the Sunsoft 5B address when communicating with the N163 so that writes to the N163 address go to the data port of the unused AY I/O on the Sunsoft 5B. But I can't see such an easy workaround for VRC7's $9010 and $9030 when they overlap VRC6's $9000.

Fixing this in the NSF specification will need a few steps:
  1. Make test ROMs for each mapper to determine whether each board responds to writes to the mirrors, and run them on authentic Famicom game PCBs.
  2. Determine a "pecking order" to decode writes when multiple chips are present. For example, in a multi-chip environment, VRC6 would ignore writes to VRC7 registers, and FDS would write-protect RAM in $8000-$DFFF.
  3. Set down guidelines for multi-chip playback engines to conform to this pecking order. For example, a multi-chip NSF MUST NOT write to mirrored ports but instead MUST write only to the port's canonical address.

by on (#92081)
As I mentioned on the wiki, I think a simple solution was already found and implemented by most players. Just don't support mirror addresses for any audio registers (interestingly the original NSF spec never mentions mirrors, except to say don't use RAM address mirrors). I've been looking through a few sources and haven't yet found any NSF players that support audio register mirrors. There's also no need for any NSF file to rely on mirrors.

The FDS write protect issue is another story, though. I suspect that FDS + VRC6, for example, is causing corruption at those addresses on many players, and we've just been lucky enough not to notice.

In the next version of NSFPlay I am planning to disallow writes at enabled audio registers when FDS is active. I may write a test NSF that we can use to verify whether memory corruption is going on.

Multi-chip hardware players are kind of a moot question, since so few seem to exist and there's no authentic standard we can reference. Theoretically they could resolve the mirror conflicts by disallowing mirrors as well, but obviously practical design decisions may make this difficult; but... when you're making the hardware you can decide yourself how you want to resolve or not resolve this problem, and it's up to you to inform the user of conflicts.