It is a fact that many NES games had voice samples. They may not have sounded very pleasant due to low sampling rates, little storage space and a 7-bit volume limitation, but they were there. This makes me ask why in the NSFs of games that had them they are consistently left out? In NSFs of games like High Speed and Bad Dudes, no sound. Even in earlier games like Bayou Billy, Ikari Warriors II and even Karate Champ, no samples. Why can't Rob Hubbard's Skate or Die II intro be put on the NSF when every good emulator can play it without a hitch? The only NSF I could find that has the voice samples contained within it is the one for Robot Block, a.k.a. Stack-Up. (Probably the earliest use of the PCM channel.) Perhaps the NSF format isnot robust enough to handle all the NES's APU.
DPCM isn't the problem - hundreds of NSFs support that without a problem (this includes 'Robot Block'). DPCM is what most games use for 'lower quality' PCM samples, like the drums in most game music (think SMB3) or other background sounds (like the cheering crowd in Punch-Out!!).
The problem is 7-bit RAW PCM, which requires the program to manually write the waveform to a particular register 1 byte at a time. Such NSFs would have to be designed to loop forever within their init routine or something, which the NSF format itself does not strictly allow (and, as such, most players do not support it). THIS is what is used by Skate or Die II/Battletoads/etc.
I've always wondered how games such as Battletoads and Big Bird's Hide and Speak update the sprites during raw pcm playback through $4011 without making a 512 cycle drop-out in the sound, or at least how they keep the OAM (which appears to be a DRAM without an automatic refresh) from decaying.
Uh, I don't believe you need to keep updating the OAM with $4014, it should stay up from the PPU constantly accessing it. So, I guess if you turn the PPU off the OAM might decay or something.
After all, BB H&S, only updates the OAM if a sprite moves (if any of the 256 bytes of the $4014 "sprite page"), so if nothing with sprites change the game won't update sprites. Interestingly though, while Big Bird talks, his beak animates and the game constantly updates sprite ram via $4014, while using $4011 to make him talk.
Quote:
The problem is 7-bit RAW PCM, which requires the program to manually write the waveform to a particular register 1 byte at a time. Such NSFs would have to be designed to loop forever within their init routine or something, which the NSF format itself does not strictly allow (and, as such, most players do not support it). THIS is what is used by Skate or Die II/Battletoads/etc.
Well, then someone should make a better mousetrap, err NES sound format. Call it NSF 2.0 or something, but it must support raw PCM. Any good emulator should support that method of sound generation. Even my crappy NESclone can play raw samples without a problem while mangling the most basic tunes. I'm sure there are more such tunes than all the songs contained with the VRC-VII chip only used for one game (meaning its worth the trouble.) Rob Hubbard's Skate or Die II intro is almost as good as his Skate or Die intro for the C64.
I'm sure there are more such tunes than all the songs contained with the VRC-VII chip only used for one game (meaning its worth the trouble.)
Hahaha! That's always amused me too.
It's trivial to support NSF code which uses all the CPU time rather than running every 1/60 second. My guess is that the trouble is with ripping the songs in the first place, since the sample playback code would probably be mixed in with the main code.
blargg wrote:
It's trivial to support NSF code which uses all the CPU time rather than running every 1/60 second. My guess is that the trouble is with ripping the songs in the first place, since the sample playback code would probably be mixed in with the main code.
Yeah, exactly. I don't know what the best solution is. If you rip out the other code, it changes the timing. It could be done maybe with 2 timers, one for the play code and one for the sample code (which gets modified). But then the sample timing could end up being more accurate than the original. Which might sound nicer though, heheh.
Seems doable though, without much extra support if the NSF player used doesn't mind staying in the init routine permanently.
Rad Racer 2, Final Fantasy 3 and SD Gundam 4 works fine, even while using $4011. Yeah, they writes to it only twice a frame, and not always like Battletoads & cie.
It could be done maybe with 2 timers, one for the play code and one for the sample code (which gets modified). But then the sample timing could end up being more accurate than the original. Which might sound nicer though, heheh.
Though many NSFs don't follow it, I think one goal of the NSF format is that the files are playable on stock NES hardware.
Yeah, I agree. I guess the extra timer makes some sense in a situation where sound code uses some external IRQ, but maybe it's better off being emulated or otherwise present "normally" in that case anyways. (still needs the hardware to play on the system, same as with extra soundchips and such)
There is accomodation for non-stock stuff in NSF format though, like the play speed if someone wants to do 30hz, 120hz, or whatever. It's just not used often or at all. I've only ever seen a couple NSFs use 30hz (I think 720° and Chase HQ).