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.
NSF specification for FDS memory
Moderator: Moderators
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSF specification for FDS memory
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?
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSF specification for FDS memory
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:
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.
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.)
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.
Re: NSF specification for FDS memory
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.
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.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSF specification for FDS memory
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:There are NSFs out there that depend on copy semantics for FDS RAM? Argh.
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:If the code isn't buggy it should never write to locations it believes to be ROM
Ha! That's interesting.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.
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.)
Re: NSF specification for FDS memory
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.
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.Rahsennor wrote:multichip engines that initialize everything but only specify FDS in the header
If only the original standard had banned FDS RAM and forced rippers to port games to WRAM...
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSF specification for FDS memory
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.Rahsennor wrote:multichip engines that initialize everything but only specify FDS in the header
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.)Rahsennor wrote:If only the original standard had banned FDS RAM and forced rippers to port games to WRAM...
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.
Re: NSF specification for FDS memory
Seiken Psycho Calibur should be working on Powerpak now (fixed a bug in the NSF mapper).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.
Sounds like a good idea, so I've done the same in Powerpak. $8000-DFFF gets write protected for multi-chip.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.
On the NSF spec topic: Should initializing $408A be in the spec? According to this, most tunes expect a BIOS-initialized default.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSF specification for FDS memory
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:
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)