NSF specification for FDS memory

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF specification for FDS memory

Post by rainwarrior »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NSF specification for FDS memory

Post by tepples »

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?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF specification for FDS memory

Post by rainwarrior »

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

Re: NSF specification for FDS memory

Post by Rahsennor »

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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF specification for FDS memory

Post by rainwarrior »

Rahsennor wrote:There are NSFs out there that depend on copy semantics for FDS RAM? Argh.
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.
Rahsennor wrote:If the code isn't buggy it should never write to locations it believes to be ROM
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.
Rahsennor wrote: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.
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.)
Rahsennor
Posts: 479
Joined: Thu Aug 20, 2015 3:09 am

Re: NSF specification for FDS memory

Post by Rahsennor »

rainwarrior wrote:Without multi-chip there's really never any reason to write protect the FDS RAM, since there's no conflict necessitates writes to it.
Rahsennor wrote:multichip engines that initialize everything but only specify FDS in the header
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...
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF specification for FDS memory

Post by rainwarrior »

Rahsennor wrote:multichip engines that initialize everything but only specify FDS in the header
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. :P
Rahsennor wrote:If only the original standard had banned FDS RAM and forced rippers to port games to WRAM...
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.
User avatar
loopy
Posts: 405
Joined: Sun Sep 19, 2004 10:52 pm
Location: UT

Re: NSF specification for FDS memory

Post by loopy »

rainwarrior wrote:Here are fixed versions of the 4 problem NSFs:

Ai Senshi Nicol (FDS)(1987)(Konami) a.nsf (attached)
Esper Dream (FDS)(1987)(Konami) a.nsf (attached)
Kiki Kaikai - Dotou-hen (FDS)(1987)(Taito) b.nsf (attached)
Seiken Psycho Calibur - Maju no Mori Densetsu (FDS)(1987)(C-Lab.)(WaveJack) b.nsf (link to attachment below)

All of these are now free of mirrored write problems. Seiken Psycho Calibur still will not run on a PowerPak for reasons I haven't yet determined.
Seiken Psycho Calibur should be working on Powerpak now (fixed a bug in the NSF mapper).
rainwarrior wrote: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.
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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF specification for FDS memory

Post by rainwarrior »

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

Looking at my notes in NSFPlay:
https://github.com/bbbradsmith/nsfplay/ ... s.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.
Post Reply