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?
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.
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
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?NewRisingSun wrote: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?
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.
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
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.
Code: Select all
CPY #1 BEQ L1 RTS L1: JMP $D017
Code: Select all
CPY #$80 BNE L1 RTS L1: JMP $D017
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.
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.
https://github.com/bbbradsmith/nes-audi ... init_y.nsf
NotSoFatso: $CD (default) or 0 (user setting)
I'll keep checking others, but so far $80 seems safe.
I also ported Blargg's saw wave demo to NSF2: thread
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...)
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.rainwarrior wrote: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.
Edit: if you have a VGM-format player installed, you could also download my Family Noraebang VGM pack.
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.NewRisingSun wrote:First, the YM2413 needs a much lower gain than the VRC7. Right now, the audio is horribly distorted.
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.