nesdev.com

Well, the heuristic which I was going to implement in the next version of NSFPlay is just to assume write protected for multi-chip. Otherwise homebrew FDS NSF seems to be very well behaved w.r.t. writes to FDS RAM area, and of course many commercial FDS rips rely on it as RAM.

Currently in NSFPlay it's just an option to write protect $8000-DFFF, but that means you have to turn it on and off for both cases. I'm going to replace that with 3 options (auto, RW, RO).

You could add it to the NSF spec if you wanted, but I kinda think the heuristic is good enough as-is.

I was thinking of adding the heuristic to the spec once we get data on how effective it would be. If a multi-chip NSF needs to build DPCM samples at runtime, it can map the same memory into $6000-$7FFF and $C000-$DFFF and write through the $6000 and $7000 windows. But to continue refining this heuristic, I have two questions:

• MMC5 can also map (one or two separate chips of) RAM into $8000-$DFFF. Should NSF emulate that in some manner?
• Is the FDS BIOS available to FDS NSFs in any way?

As far as I know those two cases do not yet exist. I think there's hundreds of "edge case theoretical combinations" to do with multi-chip things, so I'm a bit reluctant to instigate a format revision to accommodate ideas like this.

Actual extant problems:

• Copy vs mirrored RAM semantics. Many (bad?) rips rely on the copy, and are incompatible with PowerPak at least. (Solution: make "copy" semantic an option in your player, and/or try to make agnostic rips.)
• Multi-chip NSFs clobber code/data in RAM by accident. (Solution: heuristic I proposed.)

Neither of these seem to require a format extension, in my view?

And no, the FDS Bios is not available for NSF rips. If needed at all for a rip it's very easy to work around. We've done just fine without it, and I think it's best that a BIOS not become a prerequisite for an NSF player.

There are NSFs out there that depend on copy semantics for FDS RAM? Argh.

Mildly offtopic, but my heuristic for RAM/ROM detection is to emulate both and compare the results on every read. If the values differ, the address overlaps a port and the write-protect status is undecided, the RAM emulation is discarded and write-protect is enabled. If the code isn't buggy it should never write to locations it believes to be ROM, so a write anywhere other than a port causes write-protect to be disabled. Due to a few homebrew NSFs checking for write-protect and refusing to play without it (I'm looking at you w7n) I hacked it to treat $8000 as a port.

It's a big fat kludge, but it plays everything I have, including headaches with multichip engines that initialize everything but only specify FDS in the header.

I identified and posted corrected rips of all the ones I could find earlier in this thread, but yeah unfortunately the old versions are still floating around out there.


FWIW buggy code is easier to identify on an NSF, since they're deterministic. A lot of stuff can be tested in an automated way.


Ha! That's interesting.

I would just say that multi-chip just implies write protect for FDS at $8000-$DFFF. I don't think it needs to be more complicated than that. The only common hardware implementation I know of for this is the TNS-HFC series of cartridges, and they bypass the FDS RAM just using the normal NSF setup (RAM at $6000, ROM at $8000+).

Without multi-chip there's really never any reason to write protect the FDS RAM, since there's no conflict necessitates writes to it. (Very easy to test and make sure it doesn't write by accident due to the determinism, too.)

Using the header in a heuristic is only good if the header is accurate. Unfortunately, many of them aren't. While that's arguably not my problem to solve, I do like my tools to "just work", so I figured autodetection was worth it.

If only the original standard had banned FDS RAM and forced rippers to port games to WRAM...

Oh, sorry I missed that line. That's a bit unfortunate, but I'd also probably be content to just say that's a bad NSF and shouldn't ever play.


That would have made many actual FDS rips far too onerous, IMO. The FDS RAM is good. (Though I think the oldest version of the NSF spec didn't account for FDS at all. The concession to bank $E000 at $6000 was an addition in a second revision.)

If I could go back and stop something from the standard it would have been using a bitfield for expansions instead of just allowing one. There's been a lot of good work as a result of that accident though, so maybe it was okay overall.

Seiken Psycho Calibur should be working on Powerpak now (fixed a bug in the NSF mapper).


Sounds like a good idea, so I've done the same in Powerpak. $8000-DFFF gets write protected for multi-chip.

On the NSF spec topic: Should initializing $408A be in the spec? According to this, most tunes expect a BIOS-initialized default.

Very nice to hear the PowerPak NSF player is getting an update!

Looking at my notes in NSFPlay:
https://github.com/bbbradsmith/nsfplay/blob/9aae2ae0f7b737248198911fa283fea04d8666ff/xgm/devices/Sound/nes_fds.cpp#L108

So there seem to be three BIOS writes that are important:

• $4023 = $83 (enable sound i/o)
• $4080 = $80 (volume envelope)
• $408A = $E8 (envelope speed)

I agree this should be documented somewhere, maybe the FDS Audio page on the wiki, possibly also on the NSF page.