Rahsennor wrote:rainwarrior wrote:FWIW there is no compliant NSF for Battletoads that has PCM yet
I have three of them. Not sure if they count as "compliant" or not, since they use the Nintendulator-style non-returning play, but my player supports that so I need to consider the possibility.
Non-returning PLAY is not a big problem. That's easy enough for hardware to support, though it may require a reset to be able to change tracks or otherwise interact with the player.
The Battletoads NSFs use a non-returning INIT, which is the real problem. The hack to make this work is to have an (arbitrary length) timeout on the INIT if it takes too long, and the INIT then continues to run as a sample player and PLAY becomes a 60 hz interrupt with the other APU updates in it. This is a bad way to do it, IMHO, and will probably never see compatibility with hardware players.
Rahsennor wrote:I also tried remembering the last value written to $4011 and ignoring repeated writes of the same value, and found that the Castlevania games actually use multiple different values.
Last value written isn't really relevant, only the current counter value is. The DPCM sample pushes it around, obviously, why would it matter where it started?
Rahsennor wrote:tepples wrote:I think the "heuristic" part was about distinguishing this from intentional $4011 pops used as a crude kick drum. There's a page on the wiki describing what could be done about that:
Enhancement#Pop reduction
Looks like I'm going to need another frame counter...
1. Option to play as written.
2. Option to eliminate the effect of $4011 pops in a straightforward way, knowing that this breaks certain kinds of things like PCM.
3. Option to eliminate some $4011 pops only under certain mysterious conditions, which might be good enough for everything you play?
I personally don't like the heuristic approach, because I like options to have a very clear cut behaviour. Options 1 and 2 can be understood intuitively by anybody who knows the NES. The heuristic option can only really be understood by someone who knows the exact (arbitrary) heuristic used; and if we ever find a case that breaks the heuristic, it has to change, too; then we get divergent heuristics, and at the same time people can come up with 100 different heuristics for this same thing (e.g. why "3 frames" specifically?)... it just feels like a mess made to solve a non-problem.
Rahsennor wrote:Point me at a stable spec for NSF2 and some test files and I'll implement it. That's my only problem here - time, documentation and testing. I'm one person with limited free time and lots of other things I'd like to do with it - and I haven't even seen a single NSF2 file. Why support something that, as far as I am currently aware, doesn't even exist yet?
There's no NSF2 NSFs.
B00daW says "kevtris did it", but he really didn't as far as I'm concerned, otherwise we'd have a reference implementation. I do believe kevtris implemented some version of NSF2 capabilities in hardware, but that's not of value to anybody at this point. It's not a spec, and it's not anything people can use to make their own implementation.
The NSF2 spec really belongs to the first person who:
1. Publishes a good working implementation of their version of NSF2, along with their version of a spec.
2. Publishes a collection of NSF2 rips and test NSFs (recommended: new rips for Battletoads and Ultimate Stuntman).
If this sounds like your cup of tea, go right ahead.
I might do it eventually, but I've got
other projects I care a lot more about for the time being.
By the way, Battletoads and Ultimate Stuntman could both be done with the Deflemask trick, too, so it's not like they even demand an NSF2 spec to exist in practical form.