CWX did start on a MID2SEQ, but this was as far as it got (publicly): Whether he ever did any more or is even still active, I wouldn't know. Btw, his TONCNV is the program for ripping Saturn samples to WAV. It works quite nicely, as I was happy to discover. I stumbled upon it during a binge of audio software downloading, in a topic where some chump had said it wouldn't work on Saga, but only because they hadn't found any *.TON files and hadn't thought to just try some of the other extensions present on the CD; I did the latter, and it worked fine. You can read all of my verbose ramblings about this topic, and others’ more technical additions including some notes of limitations (particularly that it doesn't rip ADSR envelopes) and possible updates to TONCNV (if CWX were to release the source code), here.
I know of seq2mid and toncnv, I also know of SSF files that you can use to make playable emulated tunes out of seq/ton/dsp/memory mappings. TON data is pretty simple actually, it's just a header with the quality settings and size, converting it to wave isn't hard. The seq2mid + toncnv usually produces crap sounding files however, since it's missing out DSP data and actual initialization commands. As well as any anomalies caused by the sound driver loaded into the Saturn 68k (the percussion in Bug! is affected by that, for example). Also two games, VF2 and VF Kids, use a totally different format and cannot be converted, which sucks, cause the VF Kids intro tune has an effect that craps up many emulators - it would be useful for testing SSF player sound cores.
Wait, is that the PSF/USF/GSF/2SF spinoff for Saturn music? I'd always wanted to see what'd come of that, but as far as I'd known, nobody had bothered...
Go dig in. http://snesmusic.org/hoot/kingshriek/ssf/ http://evilboris.sonic-cult.net/ssf_rips/ ftp://ftp.modland.com/pub/modules/Saturn%20Sound%20Format/ player: http://foobar2000.xrea.jp/up/index.php?page=2 ctrl+f for aossf.
I have done a MOD player on the 32X and have been looking at the Saturn. My goal is a sfx/mod system for Lapetus since the sound support in Lapetus is pretty slim. 68000 programming is no big deal. My concern over the sound ram is splitting between the mod and sound effects... to use the hardware mixing for the mod, I'd need to keep all the instruments in sound ram, but that means little space for sound effects. So I could handle it three ways: Sound effects mixed by the Slave SH2 and streamed to the sound ram while the sound processor handle the MOD stored completely in sound ram. or MOD played entirely by the Slave SH2 and streamed to the sound ram while the sound processor handles sound effects stored completely in sound ram. or MOD and sound effects done entirely by the Slave SH2 and streamed to the sound ram where the sound processor merely handles playback. The last would basically use my 32X code which does 4/6/8 channel MODs + sound effects via the Slave SH2 where instead of DMAing the result to the PWM audio, I'd DMA the result to the sound ram. Of course, that means the SH2 is doing virtually all the sound handling via software, wasting what sound hardware the Saturn has. The first or second is preferred as that makes SOME use of the Saturn sound hardware. Mixing sound effects takes less CPU power, so the first is what I was thinking - use the Slave SH2 to mix sound effects in software and stream that to the sound ram where the MOD player there mixes that with the music. That leaves the maximum amount of Slave SH2 available for other things. However, that means a 512KB - overhead limit on MODs. That's not much of a limitation, but I do regularly come across MODs that are bigger than that. The second would allow for BIG mods, but use more Slave SH2 time as well as limit the sound effects to 512KB - overhead. Doom (among other games) has more than that, even if I subsample the sound effects. Summary: The first limits the MOD size, but allows for more sound effects and limits SH2 usage. I think this is the method I'll go with. The second plays larger MODs, but limits the sound effects and uses more SH2 time. The third allows for larger MODs and more sound effects, but uses the most SH2 time and wastes hardware resources. It's the easiest to do since I already have a MOD/SFX system for the 32X.
Can't you use the cart ram for that, or is that not accessible by the 68k? I've seen games that store samples in that area, but I guess they are copied on the fly to the 68k whenever needed. The dilemma for fitting music + SE in the sound ram existed for a lot of Saturn games, it's why many of them use pathetically low quality samples.
The 68000 only accesses the sound ram and sound hardware. You could cache the sound effects in other ram, then dma them to sound ram as needed. If you needed to send multiple sounds at once that aren't in sound ram, you're back to simply mixing by the SH2 and streaming to sound ram. So it would depend on the game and sounds as to whether that would be a valid method to handle lack of sound ram or not. The lack of sound ram is why the PSX uses compression for sound effects and instruments. It gave the PSX the equivalent of 2MB of sound ram. The SEGA CD has the same problem - only 64KB of sound ram limiting the size/quality of sounds and instruments. While the SEGA Saturn libs allow you to specify ADPCM encoded sounds, from what I've seen they are decoded into PCM when loaded to sound ram - they don't remain compressed in sound ram. The 68000 could decompress ADPCM on the fly, but you would be limited in the number of channels that you could support while doing so... MAYBE four channels at best if you had the 68000 doing nothing else. For more, you'd have to severely down sample the sounds - say, 8kHz sounds instead of 22kHz or something similar. Given how little use many games made of the Slave SH2, I'd rather use it as a music / sound mixer than try to make the 68000 decompress and mix lots of horrid sounding samples. Music and sounds are relatively unsynchronized to the game, so it's a good use for a second CPU if it's otherwise doing nothing.
Yeah, they fixed that problem with the Dreamcast that could do hardware adpcm compression. By the way, could you answer me two questions that have been bugging me for a while: - would it be possible to do realtime mp3 decoding on the Saturn? I am under the impression that the Saturn can't do floating point ops good enough for that (but it can do software mpeg1 decoding on some late japanese games, even if it low resolutions). - How feasible is using the 68k for game code instead of sound? It has been mentioned many times that Shining Force 3 and Radiant Silvergun do this, but I've yet to see proof that isn't just a magazine article.
There's that, but there's still some discussion over just how powerful the ARM processor they used actually is. Most tests show it incapable of decoding any formats beyond ADPCM, which is now handled by the hardware. There are at least a couple integer decoders for MP3 - libmad and mpg123. My experiments with libmad on the 32X were interesting. While I wasn't able to play mp3s without stuttering, it leads me to think it should be possible on the Saturn where the SH2s are a little faster and they have a 32 bit bus to sdram instead of 16 bit like the 32X. Clearly, you would have to use lower bitrate streams... I don't see it handling 320 kbps streams, but 64 or 96 should work. It's also on the list of things I want to work on on the Saturn. Well, if you aren't using the 68000 for the sound and just streamed data from the SH2 it would leave the 68000 free to do something else. If the game was originally done on a 68000 with limited memory, you could still run that game code on the Saturn 68000. You would naturally change how hardware was handled, and you might use one of the SH2s to mix the audio, but I could see someone doing that instead of trying to rewrite a few hundred KB of 68000 assembly into SH2. I don't KNOW that anyone did that, but I could see how it would be possible. Think about it a moment: the SEGA CD has a 12.5 MHz 68000 that runs programs from 512 KB of program ram and has only access to the CD and PCM chip. It passes info to the Genesis side to display graphics and read the controllers. You could leave the bulk of that code alone when converting to the Saturn, just changing the communication with the Genesis into communication with the Saturn. If the game also used the SEGA CD PCM chip for sound, you could alter that to use the Saturn sound hardware directly, sparing the need to use the SH2 as a sound mixer. This is all conjecture, of course. It assumes a fairly large game already in 68000 assembly that you are just updating the graphics for. You're using the main part of the Saturn as a super VDP. If a game is C, it would probably be easier to just make the changes needed to run on the SH2.
Yeah, I understand that it's possible to run any kind of code on it, its a general purpose cpu so to speak. What I meant was, could it communicate with the rest of the system in a way so it is feasible to offload calculations to it? The games mentioned supposedly use the 68k next to the sh2s for various calculations, and you said the 68k can only access the sound ram. Would you need to periodically check the code with the SH2s so it can transfer the results to vdp and whatnot?
The SCSP allows interrupts all around. I'd store stuff in the sound ram at set locations, then generate an interrupt from whichever CPU set the value to whichever CPU needs the value. Or you could poll the locations periodically. Whichever is easier while still getting the job done. If you were converting a SCD game, polling set locations would be most similar to the SCD's communication registers.
