I think the FDS memory specification needs a bit more definition.
1. When using bankswitching, does writing to RAM ($6000-DFFF) replace values in the original NSF ROM image? i.e. if you write to an area, bankswitch it out, and bankswitch it back in, should the written values persist?
I think the answer to this one should be "yes" for a few reasons.
For rips of actual FDS games, a yes or no seems to be irrelevant, as bankswitching during playback isn't really expected. I'm not certain, but after a short review of available source code this seems to be the dominant behaviour among NSF players, and this does not appear to be causing FDS incompatibility.
For hardware players, I think this generally simplifies the implementation, since the "no" behaviour alternative is copying over the old (untouched) block every time it is bankswitched in. Instead you For software players it is also simpler for the same reasons, though they aren't as much of a problem (no need to store the original ROM copy, FDS bankswitching does not have to be a memcpy operation). I believe this simplicity is why it's the usual implementation in NSF players. What does the PowerPak do?
This behaviour does come with a warning: any writes to the image may or may not be persistent across songs, depending on whether the player will reload between songs. Some software players reload for every track, but I wouldn't expect a hardware player to. This likely won't affect any existing FDS NSFs, but it's something that should be clarified.
2. When using multi-expansion, there are potential write conflicts.
This has been discussed over at the wiki, and there is already a recommendation there, but I'll outline it here in case anyone has comment. ( http://wiki.nesdev.com/w/index.php/NSF#Multi-chip_tunes )
This one is a little bit trickier. VRC6/VRC7/5B writes overlap with FDS RAM areas, so there is a high potential that memory gets corrupted when using FDS with these expansions. Since some NSF players do not seem to prevent this conflict, it's necessary to warn against using FDS with these other expansions, but I think it's worth making a recommendation for implementers.
Since it is normal practice in NSF implementations to ignore the mirror aliases for expansion registers and expect only the address in the NSF spec, blocking RAM writes at all active expansion addresses seems to be the lowest impact solution. The other easy solution I think is to disable all writing to FDS RAM during multi-expansion, but I don't like this as much since it takes away a useful property of the FDS. (Particularly, someone can procedurally generate DPCM samples in the $C000-DFFF region with FDS.)
This one is not particularly important to address for hardware implementations, since multi-expansion hardware has plenty of its own practical design constraints, but I think it would be good to recommend a "standard" behaviour for software implementers. This is another one where I'm curious, what does the PowerPak do?
Finally, NSF makers who want greater compatibility among players can be carefuly to put dummy data areas at the conflicting expansion addresses.
Anyhow, share your thoughts.
1. When using bankswitching, does writing to RAM ($6000-DFFF) replace values in the original NSF ROM image? i.e. if you write to an area, bankswitch it out, and bankswitch it back in, should the written values persist?
I think the answer to this one should be "yes" for a few reasons.
For rips of actual FDS games, a yes or no seems to be irrelevant, as bankswitching during playback isn't really expected. I'm not certain, but after a short review of available source code this seems to be the dominant behaviour among NSF players, and this does not appear to be causing FDS incompatibility.
For hardware players, I think this generally simplifies the implementation, since the "no" behaviour alternative is copying over the old (untouched) block every time it is bankswitched in. Instead you For software players it is also simpler for the same reasons, though they aren't as much of a problem (no need to store the original ROM copy, FDS bankswitching does not have to be a memcpy operation). I believe this simplicity is why it's the usual implementation in NSF players. What does the PowerPak do?
This behaviour does come with a warning: any writes to the image may or may not be persistent across songs, depending on whether the player will reload between songs. Some software players reload for every track, but I wouldn't expect a hardware player to. This likely won't affect any existing FDS NSFs, but it's something that should be clarified.
2. When using multi-expansion, there are potential write conflicts.
This has been discussed over at the wiki, and there is already a recommendation there, but I'll outline it here in case anyone has comment. ( http://wiki.nesdev.com/w/index.php/NSF#Multi-chip_tunes )
This one is a little bit trickier. VRC6/VRC7/5B writes overlap with FDS RAM areas, so there is a high potential that memory gets corrupted when using FDS with these expansions. Since some NSF players do not seem to prevent this conflict, it's necessary to warn against using FDS with these other expansions, but I think it's worth making a recommendation for implementers.
Since it is normal practice in NSF implementations to ignore the mirror aliases for expansion registers and expect only the address in the NSF spec, blocking RAM writes at all active expansion addresses seems to be the lowest impact solution. The other easy solution I think is to disable all writing to FDS RAM during multi-expansion, but I don't like this as much since it takes away a useful property of the FDS. (Particularly, someone can procedurally generate DPCM samples in the $C000-DFFF region with FDS.)
This one is not particularly important to address for hardware implementations, since multi-expansion hardware has plenty of its own practical design constraints, but I think it would be good to recommend a "standard" behaviour for software implementers. This is another one where I'm curious, what does the PowerPak do?
Finally, NSF makers who want greater compatibility among players can be carefuly to put dummy data areas at the conflicting expansion addresses.
Anyhow, share your thoughts.