nesdev.org

This is always something I've been curious about, but never bothered tampering with. I know that the audio is almost entirely separate from the rest of the system and is controlled by the SPC 700 cpu, which is apparently similar to the 65816 cpu found in the other part of the system. Does the SPC 700 look straight at the cartridge slot and forget about the 65816, or do you have to tell the 65816 to send information to the SPC 700? I noticed that the music still runs in a majority of these games even when they crash, so would it be the former? I also know that the SNES has 8 channels for "real life" sound effects (as apposed to FM) that make the music and, off course, are used for sound effects, meaning that you can arrange the tracks for music and the sound effects however you like. I also know that all the sounds are stored in a 64kB space called "audio ram", but I don't really have a good understanding as to how big that is for this sort of thing. How many seconds of audio can you store at the highest quality, assuming you can even change it in the first place? would music like this be possible? (Space wise. I'm pretty sure there aren't more than 6 instruments playing in the song at a time.)

https://www.youtube.com/watch?v=kY2awRU3Sx0 (I'm a sucker for this kind of fast passed, cheesy electric guitar crap)

Oh yeah, is the SPC700 8 bit or 16 bit? A lot of places say the processor speed, but nothing else.

Espozo wrote:you have to tell the 65816 to send information to the SPC 700?

Yes. One uploads the program that runs the music to the SPC700's CPU, and that runs it more-or-less independently.

How many seconds of audio can you store at the highest quality, assuming you can even change it in the first place?

the SPC700 supports a native compression format called "Bit Rate Reduction", which packs 16 monaural samples into 9 bytes. The SPC700 could correspondingly hold about 3.6 seconds of raw audio compressed in this way (65536÷9×16÷32kHz).

As a result, most SNES games either use something more like MIDI with soundfonts, or MODs, where they instead encode "play this sound on this channel at this time"

Oh yeah, is the SPC700 8 bit or 16 bit? A lot of places say the processor speed, but nothing else.

8-bit 6502-like microcontroller with a 16-bit DAC.

Espozo wrote:Does the SPC 700 look straight at the cartridge slot and forget about the 65816, or do you have to tell the 65816 to send information to the SPC 700?

The latter. The SPC700 cannot access the cartridge slot; its only connection to the outside world is a set of four I/O ports, which are mapped to $2140-$2143 on the S-CPU side and $F4-$F7 on the S-SMP side. (And yes, this means it will cheerfully keep playing a track if the main CPU goes down, because it has no way of knowing anything is wrong.)

You cannot DMA bulk data to these ports. Anything that goes in one side must be explicitly picked up on the other side by the other CPU. If you want to automate a transfer without having the SNES CPU stuck in a loop, the best you can do is use HDMA and make sure the SPC700 is checking the ports often enough to catch it all.

...oh yeah, there is one thing. There's an analog stereo passthrough on the cartridge slot; the audio module mixes it with its own output. This is how the BS Satellaview, Super Game Boy and MSU1 work.

How many seconds of audio can you store at the highest quality

The sample format is BRR, which has a 32:9 compression ratio on 16-bit material. The output sample rate is 32 kHz. At that rate, 64 kB is enough for a little over three and a half seconds of monaural sample data. Mind you, most samples don't really need that bitrate...

This, of course, leaves no room for the sound driver, sequenced music data, stack, zero page or echo buffer. Everything has to fit in that 64 kB.

assuming you can even change it in the first place?

You can. Each game has to load the audio RAM before trying to do anything, because there are no built-in sounds or functions - only a tiny 64-byte boot ROM that starts the SPC700 in a useful 'listening to the I/O ports' state.

would music like this be possible?

I don't see why not. It might not sound identical, but I don't hear anything obviously out of the ballpark... Just be sure to use an appropriate pre-emphasis filter on the samples, because the interpolator will muffle them.

Oh yeah, is the SPC700 8 bit or 16 bit? A lot of places say the processor speed, but nothing else.

8-bit. It does have a couple of opcodes that use or generate 16-bit values (MUL and DIV come to mind), but they hijack one of the index registers for the high byte.

The DSP is 16-bit, or at least the audio output is...

93143 wrote:Quote:would music like this be possible?I don't see why not. It might not sound identical, but I don't hear anything obviously out of the ballpark... Just be sure to use an appropriate pre-emphasis filter on the samples, because the interpolator will muffle them.

Yeah, I actually looked inside of the game and there was a file that just contained audio. I played it in Audacity, and I noticed that the song wasn't actually all arranged, but all the instruments were there. (Not the FM ones, off course) The thing is, the audio in the file played very fast, so I had to slow it down to sound normal. Would this be to make up for limited space?

Probably. One thing you'll notice if you get into SNES music is that sample data doesn't tend to be high-resolution unless it really needs to be, and sometimes not even then. Saving audio RAM and saving cartridge space are probably two-thirds of the reason SNES audio was sometimes muffled (the third reason being lack of proper prefiltering of samples to counteract the effect of the interpolation filter).

Now, you can stream audio to the SPC700 by continually exercising the I/O ports during playback. Tales of Phantasia famously used this technique to stream a (muffled) vocal track during the intro song, and Star Ocean's soundtrack is undumpable (in SPC format at least) because they changed out instrument data on the fly. Hitting all four ports with HDMA, it seems to me that it might be possible to push nearly 40 kB per second depending on how busy the S-SMP is. That's enough for 32 kHz stereo BRR. And, of course, blargg has demonstrated that if you don't mind dedicating a lot of CPU time to it, you can stream uncompressed 32 kHz 16-bit stereo PCM - which there's room for about a minute of if there's no actual game hogging up the cartridge...

If your using 4 HDMA ports for audio, doesn't that mean you have 4 less ports for other things like scrolling line by line?

93143 wrote:if you don't mind dedicating a lot of CPU time to it, you can stream uncompressed 32 kHz 16-bit stereo PCM - which there's room for about a minute of if there's no actual game hogging up the cartridge...

Sorry if I sound stupid, but what is taking up CPU time if it is uncompressed? I also wonder about the MSU-1 and what it does to provide "32 kHz 16-bit stereo PCM". Is it a coprocessor that gives the CPU time to do other things?

Espozo wrote:If your using 4 HDMA ports for audio, doesn't that mean you have 4 less ports for other things like scrolling line by line?

Yes, but I think you could do it with only two HDMA channels.

Sorry if I sound stupid, but what is taking up CPU time if it is uncompressed?

Something's gotta write to those ports. Even HDMA stalls the CPU while it's firing. And it strikes me that there's a fairly strict bandwidth limit on HDMA; once you've written all four I/O ports, you have to wait for the S-SMP to notice and get the data before you write again, which I suspect means you can only hit each port once per HBlank. If you want to go faster, you have to put the S-CPU in a polling loop so it can send the SPC700 new data as soon as it signals that it's ready.

Also, IIRC the audio in blargg's demo was in fact compressed, using a lossless scheme incompatible with the S-DSP. The S-CPU decompressed it before sending it to the audio module, which played it by putting it in the echo buffer.

I also wonder about the MSU-1 and what it does to provide "32 kHz 16-bit stereo PCM". Is it a coprocessor that gives the CPU time to do other things?

MSU1 audio is full-scale Red Book at 44.1 kHz. It uses the analog passthrough pins on the cartridge slot to completely bypass the digital part of the audio module (and of the rest of the SNES, for that matter). blargg's demo doesn't use the MSU1.

Just thinking, if you're not constantly uploading music, couldn't you use all 4 HDMA channels when you are doing something like changing levels, and then have all 8 free? I don't see why not.

93143 wrote:Something's gotta write to those ports. Even HDMA stalls the CPU while it's firing.

I know that you said it takes up a lot of processor time, but does it really take up more time than if you used 4 HDMA channels for anything else? Would blarg's demo along with an actual game be out of the question? From what you told me, the MSU-1 seems a bit like "cheating" and I never really wanted to use it in the first place.

93143 wrote:Also, IIRC the audio in blargg's demo was in fact compressed, using a lossless scheme incompatible with the S-DSP. The S-CPU decompressed it before sending it to the audio module, which played it by putting it in the echo buffer.

If you're just swapping out instruments with HDMA and your not planning on playing an entire song using it, you can still have the samples be compressed and this would save on CPU time?

Between levels, you're often DMAing to VRAM. If a normal DMA finishes too close to the start of HDMA, this could cause the DMA controller in a launch console (S-CPU revision 1) to crash.

MSU1 only looks like cheating until you realize there is a hardware implementation of the design in Verilog. Meaning that it's as real as the Super FX is.

What do I think? You didn't ask lol. but here goes :

I think you should stop focusing on all this HDMA / DMA / streaming balogna and focus on tracking

I know that you said it takes up a lot of processor time, but does it really take up more time than if you used 4 HDMA channels for anything else? Would blarg's demo along with an actual game be out of the question? From what you told me, the MSU-1 seems a bit like "cheating" and I never really wanted to use it in the first place.

The 65816 has to wait for the SPC700 to keep up with it.

bazz wrote:I think you should stop focusing on all this HDMA / DMA / streaming balogna and focus on tracking

I'll be waiting on you for that...

psycopathicteen wrote:The 65816 has to wait for the SPC700 to keep up with it.

What a slowpoke.

Espozo wrote:couldn't you use all 4 HDMA channels

I meant that I think you could fully occupy all four SPC700 I/O ports with just two HDMA channels. One mode 4 indirect addressed for data, and one mode 0 direct addressed for transfer control (a byte the S-SMP can check so it knows the data is new). You waste a write this way, but the overhead is a lot lower and you free up two channels.

I know that you said it takes up a lot of processor time, but does it really take up more time than if you used 4 HDMA channels for anything else?

No. I'm talking about the case where you don't have enough bandwidth with just HDMA, and you have to put the CPU in a poll/update loop.

Refreshing audio RAM is very tedious compared to refreshing VRAM, because you can't DMA to it.

Would blarg's demo along with an actual game be out of the question?

It's one minute of music, and it takes 4 MB. And the CPU is almost at 100% load just decompressing the audio and feeding it to the SPC700. So yes.

If you're just swapping out instruments with HDMA and your not planning on playing an entire song using it, you can still have the samples be compressed and this would save on CPU time?

The samples have to be compressed. The S-DSP only understands BRR. And further compression of BRR won't get you anywhere; it's pretty tightly packed already.

A sample swapping engine is a very sophisticated trick. Keep in mind that undumpable games are very rare, and that most of them are that way not because of streaming but because the developers didn't understand the SPC700 and wrote audio engines that required continuous S-CPU input to work.

bazz wrote:I think you should stop focusing on all this HDMA / DMA / streaming balogna and focus on tracking

This. I probably shouldn't have mentioned streaming; it's a very advanced technique, and only a few games used it very late in the system's life. (I had Bad Apple on the brain, I guess.) The meat and potatoes is using what you've already put in the audio RAM to make fine music and immersive sound effects.

It's limited, but it's not that limited. When I said the music you linked was probably possible, I wasn't taking streaming into account. Plok, Rock 'n' Roll Racing, Vortex, Dracula X, the DKC games, Super Star Wars, Energy Breaker, Final Fantasy VI, Seiken Densetsu 3, Super Mario RPG, Actraiser, Super Turrican 2 - none of them use streaming. Even Tales of Phantasia only uses streaming for voice work; the instrumentals are all preloaded.

93143 wrote:Would blarg's demo along with an actual game be out of the question?It's one minute of music, and it takes 4 MB. And the CPU is almost at 100% load just decompressing the audio and feeding it to the SPC700. So yes.

I thought that you said that the SPC 700 decompressed the audio. Is the "S-CPU" not the sound processor? Would the music be possible in a game if there was no compression and you instead used an insanely large cart? I'm probably not going to try something like this, I'm just curious.

93143 wrote:It's limited, but it's not that limited. When I said the music you linked was probably possible, I wasn't taking streaming into account.

Just for the heck of it, here's how all the instruments and sound effects sound in the game before slowing them down. (You can't upload a WAV file? Huh.)
You know, if sound on the SNES is so flexible, then why do a lot of songs from games like Street Fighter 2 sound a lot different than the arcade version? I'm pretty sure sound on the CPS 1 is FM, but couldn't you have instruments that sound exactly like FM that you can use?

That reminds me of something I heard about the DKC games. Dave Wise said in an interview, that he used a synthesizer that produced instruments by linking shorter waveforms together, and programmed the SPC700 to emulate it.