NSF Extensions, NSF2 and NSFe (2018)

[rainwarrior]

Okay, so this isn't a report at all about the non-returning INIT flag.

I'll look into what you're describing. If something is being cutoff, I would assume it applies to all NSFs played. Is this something new in this version of NSFPlay, or always?

You've mentioned NintendulatorNRS a few times, but I am having trouble finding any information about it. Where is it kept, and is its source code available?

[NewRisingSun]

Yes, I initially misattributed it to the init issue, but now noticed that it is a separate issue. I will have to check previous versions of NSFPlug tonight.

NintendulatorNRS is my fork of Nintendulator. I originally just added support for a few more mappers, but over time, the changes have become so numerous that it has become a fork. There is no official release yet, I only post builds when we dump a game that uses a new mapper. Source is available... from me, until I make an official release.

[rainwarrior]

Thanks for noticing that. It was a new bug I introduced with 2.4b9, and I've now committed a fix. I'll post a beta 10 build soon to correct this, since this is a bad bug IMO.

If you want to know the specific details: in the first frame, PLAY was getting called, then getting called again immediately as soon as returns. So both frames worth of PLAY were executed, but the first one wasn't being given much time to make sound.

Edit: fixed in 2.4 beta 10
https://github.com/bbbradsmith/nsfplay/releases

[NewRisingSun]

Thank-you.

I understand now how it works, but am still having trouble applying this to concrete cases. Take the recently-posted Skate or Die! 2 rerip NSF, for example. Most songs, including the title screen, have a normal returning Init/Play combination, but a few are just speech samples that apparently play the full sample in init, and do not play correctly in most players. What is is the correct set-up for these in NSF2?

[rainwarrior]

I understand now how it works, but am still having trouble applying this to concrete cases. Take the recently-posted Skate or Die! 2 rerip NSF, for example. Most songs, including the title screen, have a normal returning Init/Play combination, but a few are just speech samples that apparently play the full sample in init, and do not play correctly in most players. What is is the correct set-up for these in NSF2?

I'm not sure what that Skate or Die rip is supposed to do. What player does it actually work in?

The non-returning INIT process might be used for Skate or Die samples like this:

• INIT #1 you set up everything that needs to be set up. As soon as you return from this, the PLAY routine is going to start getting called at 60Hz.
• INIT #2 this can play samples in a locked loop and never return (make sure it was ready after INIT #1), PLAY will interrupt it to do whatever PLAY needs to do.

A long time ago quietust made a hack experiment for "non returning INIT" which was done by just timing out INIT after some arbitrary number of cycles had passed. This was used to create a Battletoads rip that did more or less that, an INIT representing a main thread sample player, and PLAY representing a periodic interruption (i.e. NMI) to handle the other music and triggering new samples.

The hacky part was making it an arbitrary timeout. That's what I was attempting to resolve with the 2 INIT calls. The length shouldn't be arbitrary, the NSF should be able to clearly signal when it's ready to begin. I think only 2 players ever implemented this (Nintendulator and GME/GEP).

So... in NSF2 you could do it this way with the non-returning INIT, though you could also turn it upside down and play samples from an IRQ instead. You'd probably want to use whichever will reproduce the original game more faithfully. The IRQ can be used for a bunch of other things, like Blargg made a DPCM IRQ saw wave. You could also combine IRQs with the non-returning INIT and a lot of the utility here is just providing access to NMI and IRQ timing like you would in an NES ROM (...no PPU or controller though).

The other thing that this helps is situations where a non-returning PLAY was used for sample playback (SuperNSF, Deflemask, MUSE Tracker). This would play in most NSF players, and even in hardware players, but in hardware players it left the player program with no way to respond to user input. You'd start a track and it would keep playing until you reset. No way to have more than one track, and it was pretty inconvenient. Using an IRQ instead, or using a non-returning INIT both give a hardware player a place to take input again, and could allow this kind of technique without that problem.

So... that's some of the reasons why Kevtris had proposed NSF2 several years ago, and reasons why people have been bringing it up since then.

Like the other Battletoads rip I linked a couple posts back, this uses the "deflemask" technique of non-returning PLAY. This worked in many more players than quietust's hack did, and you could even play the first track on a PowerPak. However, if you wanted to switch tracks on a PowerPak... that's still out of reach for this. Doing that will require NSF2 for PowerPak.


Edit: found a working link for Blargg's saw test

[NewRisingSun]

I only got it to play correctly in FCEUX.

[rainwarrior]

Oh, okay. That Skate or Die 2 rip is using the PPU to generate an NMI (i.e. writes to $2000).

That's... exactly the kind of thing NSF2 was designed to make possible. (Except you're still not allowed to write to the PPU. NMI is provided for you.)

Edit: As an experiment I decided to turn it into a valid NSF2 rip in that thread.

[NewRisingSun]

Now that I see it in action, I am thinking that one could increase the compatibility of such NSF2s by changing the spec to call for Y having the values $80 and $81 instead of $00 and $01. That would tell the init routine that the player does support that feature and act accordingly, while any other value would indicate that the player does not support the feature, and the init routine can then act like NSF(1). So in that file, instead of

Code: Select all

   CPY #1
   BEQ L1
   RTS
L1:
   JMP $D017

one would have:

Code: Select all

   CPY #$80
   BNE L1
   RTS
L1:
   JMP $D017

and be compatible with both NSF(1) and NSF2 players.

Apart from that, good job fixing that file. I had yesterday posted my own attempt at fixing it, but deleted it once I learned that I did not implement the non-returning init feature correctly.

Edit: I have tried NSFPlug beta 10, and the beginnings now play perfectly. Thank-you for correcting this.

[rainwarrior]

I like that idea. Gives the option to try to provide a fallback if you want one.

Y on entry to INIT wasn't guaranteed to be anything in NSF1, so there's no guarantee that players aren't using $80 or even a consistent value, but I do think most players probably do use 0, and at any rate $80 is much less likely to be used than 0. PowerPak's NSF player source looks like it will enter INIT with Y=3.

Gotta update the beta and that Skate or Die 2 test, but I will do that soon.

Edit: Beta updated to version 11.

[rainwarrior]

Just to follow up, wrote a simple NSF to play an 8 bit beep to let me know what players use for Y on init:
https://github.com/bbbradsmith/nes-audi ... init_y.nsf

NSFPlay: 0
PowerPak: 3
Mesen: $0F
VirtuaNSF1060: 0
Foo_gep: 0
VLC: 0
Nestopia: 0
Nintendulator: $0F
VirtuaNES097e: 0
FCEUX: 0
NotSoFatso: $CD (default) or 0 (user setting)
NEZPlug++: 0
G-NSF: 0

I'll keep checking others, but so far $80 seems safe.

[rainwarrior]

Found a working link for Blargg's DPCM saw test. This is a candidate for NSF2 features. I might try porting it at some point, if nobody else does:
http://blargg.8bitalley.com/misc/nes-saw/

[rainwarrior]

NSFPlay 2.4 beta 12 adds some better error messages about NSFe files that fail to load, and also cleans up some of the IRQ/DPCM implementation (better CPU synchronization, fixes some bugs that were exposed now that IRQs work, etc.):
https://github.com/bbbradsmith/nsfplay/releases

I also ported Blargg's saw wave demo to NSF2: thread

[rainwarrior]

I ended up pushing the VRC7/5B rewrites to 2.5, and just cleaned up a bunch of smaller tasks to finish out 2.4. Beta 15 might be the last beta before I call it stable and move on to 2.5:
https://github.com/bbbradsmith/nsfplay/releases

I added "quick" support for YM2413, i.e. just sort of turning it on with the existing YM2413 emulator in there, but I'm not certain if it works correctly. It will run that Family Noraebang NSF, and I think there's percussion in there, but I have nothing to compare against to know how it should sound. (The whole VRC7/YM2413 will get rewritten for 2.5 anyway...)

[NewRisingSun]

Cool.

tI will run that Family Noraebang NSF, and I think there's percussion in there, but I have nothing to compare against to know how it should sound.

First, the YM2413 needs a much lower gain than the VRC7. Right now, the audio is horribly distorted. And yes, the percussion channels are missing. As a reference, you could download a current build of NintendulatorNRS here, which plays the file correctly, or you could listen to MLX' recording from actual hardware (ignore the footage from another cartridge in the first few seconds). The hardware recording is rather muffled; this may be the result of filtering by the cartridge itself (to hide the YM2413's quantization noise) or by the console.

Edit: if you have a VGM-format player installed, you could also download my Family Noraebang VGM pack.

[rainwarrior]

First, the YM2413 needs a much lower gain than the VRC7. Right now, the audio is horribly distorted.

If you've got the cart to measure you modify the reference test for its register locations and put an appropriate value into a 'mixe' chunk.
http://wiki.nesdev.com/w/index.php/NSFe#mixe
Edit: There's nothing to measure, is there. See next post for a different recommendation.

That video and VGM will help with reference, thanks.

As for percussion not working properly... I'm not sure what I want to do about that. It seems to be making some sounds, but not all of them. I'm rewriting the entire VRC7 emulation for the next version, so I don't really want to labour to understand and fix the old inherited implementation for 2.4. If there's a small code change you can see that would fix it, I could put it in, but otherwise it might just have to wait for the rewrite.