It is currently Sat Dec 16, 2017 2:27 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Aug 07, 2017 4:21 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
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.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 5:03 pm 
Offline

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


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 5:15 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
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.


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 5:22 am 
Offline

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


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 1:52 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
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.)


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 7:08 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 7:31 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group