PDA

View Full Version : Saturn's Sound System (and advanced console sound hardware in general)



kool kitty89
08-16-2010, 09:35 PM
When used purely for sample playback and sample based synthesis, how capable was the Saturn? (especially compared to the Playstation -or even N64)

I know the Saturn didn't support compressed samples by default like the PSX (the N64 did in software), but what soft of compression would the 68k or DSP of the Saturn facilitate by comparison.


It seems like, in general, a lot of consoles (from SNES onward) had a lot of dedicated resources put into audio hardware that was almost always used only for simple sample based synthesis and sample playback rather than a variety of other synthesis techniques possible with the resources of such systems (FM, AM, wavetable, subtractive, etc -including what the MT32 does) as well as other flexibility possible but not used, or not supported in standard tools.
It seems like the most advanced features used with such were decompression of samples, digital filtering and interpolation, and some other effects like echo, or reverb. (in the SNES's case, full stereo panning wasn't even supported, just hard panning)

In the SNES's case in particular, the standard SPC format was basically lime a simple mod player (to the extent that most people wouldn't miss much if simple DMA sound had been used instead -like the Amiga, Archimedes, Atari Falcon, etc), not only did it not really facilitate the DSP's use for other forms of synthesis, but fixed the feature set: forcing interpolation (muffling the sound) and fixing it to the 8 channel output with a fixed feature set when it should have been possible to use up to 32 voices with the sound system. (not to mention other possible compression algorithms useful for samples of other bit depths -like compressing 8-bit PCM rather than the 16-bit samples used for ADPCM: 8-bit samples compredded to 3:1 or 4:1 would have been much smaller than corresponding ADPCM samples for example)


I could see why hardware designers would be pushing such with the SNES through Saturn/PSX period with the assumption that the flexibility would actually be used (though in the SNES's case, the actual support for such soft of counters that concept), but after it became clear with the 5th generation that streaming audio and sample based synthesis (if not just straight sample playback) were the norm, it's rather odd that some later consoles continued to push rather hefty dedicated sound systems. (especially the Dreamcast, taking the Saturn's sound system with a lot more RAM and ARM7 replacing the 68k)
If anything it seems like designers should have realized that simple DMA driven sound would have been all that was really necessary, maybe with a dedicated sound CPU for added effects and such. (if not utilizing the main CPU for that)

The only thing to really worry about would have been support for surround sound panning for effects and decompression of such effects (or enough RAM to fit them uncompressed) and perhaps support decompression for streaming audio as well. (ADPCM or simply lower quality PCM would have already been practical for such in the previous generation, but MP3 audio would be quite significant to fit many, many more tracks on disc than huge CD-DA files, or also stuff like oog, or less intensive lossy algorithms than MP3 -N64 even supported MP3, though I'm not sure if any games used that: Episode 1 racer used all streaming audio I believe, though that's not necessarily MP3 -could be ADPCM, I think a few other N64 games did that too).

The N64 dropped the dedicated audio subsystem entirely, just using the RSP or CPU coupled with DMA sound I believe: which is also how most post Dreamcast systems did it. (not sure about PS2, but I think GC, Xbox, Wii, PS3, and 360 are like that -let alone PCs)

TrekkiesUnite118
08-16-2010, 10:04 PM
If I remember correctly Saturn's Sound system was better than that of the PS1, but N64 was better in theory, though only if all it's power was used for just sound. Though I could be wrong here.

I do know though that most stuff on Saturn and PS1 usually sounded better on Saturn, games like Lunar, Grandia, and Megaman 8 come to mind. Saturn can do 32 PCM channels, PS1 can do 24. So Saturn stuff sometimes has more going on I guess. Also I think Saturn's sound chip can also go into FM Synthesis mode which I think is used for some of Capcom's CPS1 ports.

Joe Redifer
08-16-2010, 11:35 PM
The game Scorcher uses the internal Saturn sound chips for ALL of its sound, including the music. I don't think it used any samples, at least not for the music. Give it a listen, sounds pretty good.

Da_Shocker
08-17-2010, 12:12 AM
If I remember correctly Saturn's Sound system was better than that of the PS1, but N64 was better in theory, though only if all it's power was used for just sound. Though I could be wrong here.

I do know though that most stuff on Saturn and PS1 usually sounded better on Saturn, games like Lunar, Grandia, and Megaman 8 come to mind. Saturn can do 32 PCM channels, PS1 can do 24. So Saturn stuff sometimes has more going on I guess. Also I think Saturn's sound chip can also go into FM Synthesis mode which I think is used for some of Capcom's CPS1 ports.

The Saturn's sound system was better than the N64. Sega used it in there high end Model 3 board to be exact.

kool kitty89
08-17-2010, 01:04 AM
The game Scorcher uses the internal Saturn sound chips for ALL of its sound, including the music. I don't think it used any samples, at least not for the music. Give it a listen, sounds pretty good.
Sample based stuff would also be using onboard sound hardware too, but I guess you mean using all realtime synthesis and not simple sample stuff. (presumably FM as that seems to have been specifically supported by Sega -though with a DSP there should be more than that possible -same for SNES, 3DO, Jaguar, PSX, etc -and N64 or 32x or modern consoles depending on how much resource is dedicated to audio)

I don't think the Saturn had a discrete sound "chip" as such (nothing like discrete PSGs or FM chips), but the DSP could be used for FM synthesis for sure. (and given the list of "8 FM voices" in common specs, it would seem likely that Sega specifically facilitated that in their dev kits -or even had a DSP program in ROM facilitating FM)
I know Atari provided support for FM Synthesis (as well as some other forms of synthesis) on the Jaguar's "DSP." (actually very advantageous compared to sample based stuff due to the slow connection to the main bus for the DSP and no dedicated RAM other than the 8 kB on-chip -it has a 4 kB wave ROM with simple waveforms intended for use with subtractive synthesis, wavetable synthesis and such)

From what I understand, the Saturn's sound system is comprised of 512 kB of DRAM, a 11.5 MHz 68EC000, and a custom Yamaha DSP labeled the "Saturn Custom Sound Processor."

Edit: listening to Scorcher's tracks, I really can't tell: it easily could be sample based, but it could also be FM... or subtractive syntehsis, or wavetable synthesis (or something like the MT-32 does). Using sampes from synthesized instruments is nothing out of the ordinary. (most SNES games did that -some with almost all instruments being FM or some other synthesized instrument -the Amiga had a tendency to sample analog synth sounds for several games too; in fact, the N64 had a lot of games that seem to use sampled synthesized instruments -Mario 64 in particular comes to mind and a lot of it sounds liek DX7 synthesis)

6-op FM is advanced stuff and the sorts of sounds possible with that are extremely varied too. (look what the DX7 can do)
That reminds me: I think most (maybe even all) of the music in Earthworm Jim Special Edition sounds like it could be 6-op FM. (including percussion)

This really sounds like it's sampled to me though:
http://www.youtube.com/watch?v=h3lyBL-FOkc
h3lyBL-FOkc

It's not like there's not a lot of stuff on the N64 that sounds similar to that too.



The Saturn's sound system was better than the N64. Sega used it in there high end Model 3 board to be exact.
Why does being used in the model 3 make it more advanced the than the N64 for audio??? (that's false reasoning)

Would the YM2612 or Ricoh PCM chip being used in the System 32 make either of those more advanced than the SNES's sound module?



If I remember correctly Saturn's Sound system was better than that of the PS1, but N64 was better in theory, though only if all it's power was used for just sound. Though I could be wrong here.
The N64 didn't have dedicated sound hardware, but it had a lot of resource to work with (either using the CPU or RSP for audio work), but yes, as both the CPU and RSP had other duties in games, there were trade-offs.
I'm not sure how using the R4300 or RSP compares to the Saturn's SCSP DSP and 68k in general though. (it's not apples to apples for sure)
The 32x had a lot of CPU resource to throw at audio too, unfortunately the DMA audio wasn't supported on the 32x so a lot more resource had to be used for sample based stuff that was actually necessary. (Sega didn't provide documentation for that feature -it is fully functional though and Chilly willy recently got it working with a demo)

Depending on the game there could be trade-offs with sound and game performance. (on a pure sound comparison that's a bit different though and throwing 100% RSP or CPU resource at audio would not be used in games)

TrekkiesUnite118
08-17-2010, 01:40 AM
The N64 didn't have dedicated sound hardware, but it had a lot of resource to work with (either using the CPU or RSP for audio work), but yes, as both the CPU and RSP had other duties in games, there were trade-offs.
I'm not sure how using the R4300 or RSP compares to the Saturn's SCSP DSP and 68k in general though. (it's not apples to apples for sure)
The 32x had a lot of CPU resource to throw at audio too, unfortunately the DMA audio wasn't supported on the 32x so a lot more resource had to be used for sample based stuff that was actually necessary. (Sega didn't provide documentation for that feature -it is fully functional though and Chilly willy recently got it working with a demo)

Depending on the game there could be trade-offs with sound and game performance. (on a pure sound comparison that's a bit different though and throwing 100% RSP or CPU resource at audio would not be used in games)

I'm well aware of that, hence why I said in Theory. In an actual game though Saturn probably has the best sound chip of the 32-bit Generation. Not only can it do more channels, a lot of times it sounds a lot more realistic.

Here are some comparisons:
Saturn: http://www.youtube.com/watch?v=YstYEC2dsm4
PS1: http://www.youtube.com/watch?v=3LXU5z1QcWg

Saturn: http://www.youtube.com/watch?v=N621H80LpPo -(volume is low on the video)
PS1: http://www.youtube.com/watch?v=yhaWp5E79xQ

PS1 just sounds a bit empty by comparison.

Da_Shocker
08-17-2010, 01:46 AM
The Model 3 board shitted on the N64 so i'm sure it would shit on the N64 board. And the N64's sound system was dependent on other features iirc. The Saturn simply could'nt play compressed samples.

kool kitty89
08-17-2010, 02:33 AM
I'm well aware of that, hence why I said in Theory. In an actual game though Saturn probably has the best sound chip of the 32-bit Generation. Not only can it do more channels, a lot of times it sounds a lot more realistic.

Here are some comparisons:
Saturn: http://www.youtube.com/watch?v=YstYEC2dsm4
PS1: http://www.youtube.com/watch?v=3LXU5z1QcWg

Saturn: http://www.youtube.com/watch?v=N621H80LpPo -(volume is low on the video)
PS1: http://www.youtube.com/watch?v=yhaWp5E79xQ

PS1 just sounds a bit empty by comparison.
Those aren't good comparisons, but from what I can tell, they're pretty much identical sounding. (the quality is really poor and the dialog is too loud to really judge in the PSX video of Lunar especially)
From what I can hear, it seems like some additional or different instruments may have been used on the PSX version, but it's really hard to judge with the terrible recording quality. The Saturn recording for MM8 is also pretty nasty, the PSX one is a little distorted too, but again they seem rather similar overall. (again, hard to really judge: both seem to use a lot of sampled FM instruments though, not uncommon for Capcom at all -they did that a lot on the SNES)

I will say that the trumpet sounds better in the PSX version of lunar (around 5:30 and 2:40 repesctively), the Saturn version seems to use a rather generic synth trumpet sound (sounds more like FM than a real trumpet), actually very similar to one of Roland's soundcanvas samples. (microsoft windows general midi) Not bad by any means and rather like the trumpet/brass samples used at poits in Majora's mask too, but I prefer the one used in the PSX. (it seems like it might be a longer sample too, or longer sustain being used) At that part of the music in general, the Saturn version sounds like it's using a lot more FM like instruments (I wonder if any are synthesized and not samples) while the PSX seems to use several different instrument samples entirely. (I think I prefer the PSX version generally, though the quality of the recording makes it a bit hard to tell)
Edit: the more I listen to it, the more it sounds like the Saturn might be using FM synthesis (either that or a lot of FM based samples) while the PSX version seems to use mostly sampled *real* instruments instead. (more orchestral sounding and less synthy)
It seems more likely to be the case there than with Joe's example with Scorcher IMO.

As it is, that stuff sounds a lot like some N64 music too, though it obviously varies. (it's a bit reminiscent of some OOT or Major's Mask stuff in particular) But again, sample based music isn't really something to show off the hardware, and developers using their own software compression algorithms and such isn't something you can judge by simply listening. ;)

I'm not sure the PSX and Saturn necessarily have hard limits either: it may be 32 and 24 hardware channels, but that could be a big simplification too. (not mentioning if that's discrete hardware channels, the limit for mixing with the DSP, etc)
The SNES, again, is fully capable of 32 concurrent voices. (it's only limited to 8 due to the default setup, that's all up to the constraints of the SPC format and lack of flexibility offered to use the sound module)
I think Chilly willy mentioned that the 32x could have reasonably had 32 channels mixed in PWM using the slave SH2 alone if the DMA is used. (which no game used and no developer of the time had access to -lack of documentation on Sega's part as I said)

And the maximum number of channels is not really a useful measure in its own right. (the N64 using full bandwidth for audio easily wins there)
Plus, the real power isn't from the number of channels, but the other forms of synthesis possible. (given the lack of general emphasis put on that, there's not much to compare -but any system using a DSP in the audio subsystem should have facilitated such: the rather primitive DSP used in the Flare 1 design -and corresponding Konix Multisystem- had FM synthesis prominently demonstrated on it)







The Model 3 board shitted on the N64 so i'm sure it would shit on the N64 board. And the N64's sound system was dependent on other features iirc. The Saturn simply could'nt play compressed samples.
What makes you think the Saturn couldn't play compressed samples? (or stream compressed audio for that matter)
The Genesis can play compressed samples. (and stream compressed audio) ;)

Comparing an arcade board liek the model 3 means nothing as you've got more memory... and if you're doing sample based stuff (like many if not most model 1, 2, ST-V and 3 games seem to do), that's all pointless as the resouce required isn't very great at all: it's just pitch shifted sample playback, so the "quality" difference is usually based sonly on the size of the samples used. (a memory issue, not a performance one)

And again, the N64 has no sound system per se, but it has a ton of resource that can be put towards sound. (again, the 32x facilitates that too, though I'm not sure about the Saturn -ie if the main CPUs can access the sound system directly -with 32x, the Z80, 68k, and SH2s can access PWM)

The Jaguar had a pretty powerful set-up to with Jerry driving audio, though most games seem to just use sample based stuff, which totally wastes it and is more limited at that due to the bandwitch of the shared system bus. (other than maybe being used for sample decompression) The "DSP" in the Jag was the same RISC core used for the "GPU" and as such was a general purpose processor not limited to audio duties, but again, the connection to the main bus severely hindered any operations requiring hea


Just because something had examples that seem better, doesn't make it more powerful by any means.
Not that it really matters anyway, as, again, samples were the norm and that's not resource intensive at all unlike using a DSP or CPU for FM, subtractive, wavetable, or other forms of synthesis. (if all they wanted was a good sample based synthesizer, all they needed was DMA driven audio and maybe a dedicated CPU/MCU if they wanted to avoid any CPU overhead at all -which would be pretty minimal depending on the set-up and effects desired, more dedicated resource if software mixing and such was desired -an evolution of the same bare bones DMA driven DACs the Amiga used -which is eventually what ended up happening once it was realized that such dedicated resource going to sound was rather unnecessary)

I'm really interested in what the programmers on the board have to say about this in general though. (some of it came up before, but usually short and off topic)

Chilly Willy
08-17-2010, 03:07 AM
The Saturn DSP can mix uncompressed streams in hardware. You can use the CPU to decompress samples, but the system is at the base of it designed around uncompressed samples. That's good in a way - as people learned with the SNES, compressed samples suffer from compression. The PSX uses compressed samples, very similar to the SNES, and hence you get that "compressed sample" sound to it. Uncompressed samples use more space, but sound better. If you are careful with your audio memory usage, your sound will be much clearer than in systems that only play compressed audio. So the Saturn SHOULD sound better on some games than the PSX.

The N64 has the worst audio of all the systems - it's really very similar to the 32X audio. All you have is a single channel of stereo audio that can be 8 to 16 bit, with sample rates up to 46 kHz. That's better than the 32X, but I meant in terms of what you have - you just have a stereo stream and the CPU does all the work. The RSP is not a complex DSP - it's basically just a MIPS CPU with the multiply, divide, and fpu ripped out to make room for a fixed-point vector unit meant for 3D. The "microcode" Nintendo supplied could do a few things to help the audio - resample the audio to a different rate, change the volume, decompress a simple compressed sample, add the sample to a buffer for mixing... those sorts of things. In the end, the main CPU did most of the work in playing audio... which actually helped game devs as that was pretty much how most programmers were used to dealing with audio on PCs. So while the N64 had the worst audio, it was actually the most dev friendly of the various consoles.

Joe Redifer
08-17-2010, 03:58 AM
Kool Kitty, the Saturn has 8 dedicated FM sound channels. There is no reason to believe otherwise. They are not pretend FM channels.

TrekkiesUnite118
08-17-2010, 08:40 AM
If you listen closely to the Saturn version of Aquaman and compare it to the PS1 version, you can hear more instruments in the background. With Lunar the strings sound much better on the Saturn version than the PS1 version and there are again more instruments being used too. I admit the recordings aren't great, but finding good ones on youtube is pretty hard.

TmEE
08-17-2010, 09:37 AM
There's no dedicated FM sound channels on Saturn...

The SCSP has 32 channels / operator, you can use any of the channels as an FM operator and you can use as many as you wish and link them together in any way you want. You can have 16 channels of 2op FM synthesis or 1 channel of 32op FM synthesis. You're also not limited to specific waveforms, but rather you can use anything you wish... you could even use some drum sample instead of regular sine and get interesting results :P

There's also the DSP which kills the PSX... but it was not made use of... Dreamcast has better DSP and twice as many channels, but lacks synthesizer part.

I'm not sure about PS2 but Saturn has technically the most powerful sound setup of all game consoles... there's hardware sampler, synthesizer and effect unit, following machines had sampler at best and a feeble effect unit or just plain DACs(X360, most probably PS3, Xbox1) or PWM (NDS) that are CPU driven or have some sort of hardware support... but they're still limited to simple sample playback.

retrospiel
08-17-2010, 01:28 PM
Panzer Dragoon Zwei and Story of Thor 2 / Legend of Oasis use real time chiptunes.

Scorcher most likely used ADPCM compression - as does Shin Shinobi Den aka Shinobi X.

Unlike you claim, I say that Saturn did support hardware ADPCM - much like Dreamcast does.

kokujin
08-17-2010, 05:15 PM
Did any games use FM on the Saturn.

kool kitty89
08-17-2010, 05:30 PM
There's no dedicated FM sound channels on Saturn...

The SCSP has 32 channels / operator, you can use any of the channels as an FM operator and you can use as many as you wish and link them together in any way you want. You can have 16 channels of 2op FM synthesis or 1 channel of 32op FM synthesis. You're also not limited to specific waveforms, but rather you can use anything you wish... you could even use some drum sample instead of regular sine and get interesting results :P
Oh cool, so you could have some 6-op FM channels for sure (or vary it depending on the FM instruments needed) as well as PCM channels, and that's all in hardware, not using a DSP or CPU to do it instead. (though using additional resource you could mix additional PCM channels or do other forms of synthesis using the DSP)
So that's not what I'd assumed for sure: I'd thought the FM was handled by the DSP like the FM driver on the Jaguar (not sure if any games used it), though, again, with DSP resource you've got a lot of other options as well. (just using it for compression, mixing, or effects on sample based stuff, or other forms of synthesis: wavetable, subtractive, etc -the method used in the MT-32 and such is really interesting -I think that's actually somewhat similar to wavetable synthesis but with subtractive synthesis used as well)



There's also the DSP which kills the PSX... but it was not made use of... Dreamcast has better DSP and twice as many channels, but lacks synthesizer part.
Was the DSP just used rarely or not at all? (it seems that in the context of sample based stuff, at very least it would be used for decompressing samples)
You mentioned using software ADPCM decoding with the 68k in the Saturn, but it would seem that the DSP would be far more capable at doing that. It shouldn't be limited to conventional 4-bit ADPCM either (for compressing 16-bit PCM), but other algorithms tuned for other word sizes. (especially 8-bit PCM)

I know the PSX has pretty much the same DSP used in the SNES (though not the entire SPC sound system or dedicated sound controller/CPU iirc), but it would be the DSP in the SNES and PSX that's handling the ADPCM decompression, right? (and digital interpolation in the SNES's case)


I'm not sure about PS2 but Saturn has technically the most powerful sound setup of all game consoles... there's hardware sampler, synthesizer and effect unit, following machines had sampler at best and a feeble effect unit or just plain DACs(X360, most probably PS3, Xbox1) or PWM (NDS) that are CPU driven or have some sort of hardware support... but they're still limited to simple sample playback.
The DS uses PWM too? (I know the GBA did, but I didn't know the DS did that too)
Obviously there's a big difference in terms of resource/overhead with DMA supported DACs and bare DACs. (that and software mixing on a limited number of discrete hardware channels vs a large number of hardware channels)








Panzer Dragoon Zwei and Story of Thor 2 / Legend of Oasis use real time chiptunes.
You mean all FM synthesis?


Unlike you claim, I say that Saturn did support hardware ADPCM - much like Dreamcast does.
I'm not sure any of these supported ADPCM "in hardware" as such (ie no ASIC or hardwired logic dedicated to ADPCM decoding -like in some of Yamaha's FM chips or the ADPCM chips in some arcade boards or the PC Engine). I think all of them (including the SNES) use DSP resource for ADPCM decoding. (the Dreamcast also has a nice ARM7 in its sound system on top of a hefty DSP -enough to easily handle MP3 streams as well going by previous discussions on this)

If the DSPs have ADPCM decoding programs burned into on-chip ROM, I suppose that could be considered "hardware" decoding though. (it wouldn't be hardwired logic in the same sense of ADPCM on the YM2608 or YM2610 among others)

evildragon
08-17-2010, 07:06 PM
If it's a program in rom of the chip, that's still software, is it not?

kool kitty89
08-17-2010, 07:18 PM
If it's a program in rom of the chip, that's still software, is it not?
That's why I said "could" consider it as such. It's software, but it's still hard-coded in embedded ROM. (like it would be in a DSP microcode program running in on-chip RAM, except fixed to that single program)

I'm not sure, but don't hard-coded microcode driving operations in CPUs do that too? (instructions triggering internal microcode programs to carry out an operation that's not hardwired in logic -like multiplication on an 8088/8086: one major speed difference for NEC's V20/30 was hardwired logic for multiplication -not sure if the 80186 added that too: I think the V33 -and 80286- executes all instructions in hardwired logic)

I think it's more complex than that though, and my understanding is rather limited.



Also, a couple quotes from a previous topic that went in this direction before:


Saturn has the most powerful sound setup form any console that exists, very very powerful synthesizer and quite powerful DSP with many effects. Only problem was that nobody used those features... few games used synthesizer capabilities, most only did sampling and with 512KB of RAM for that you will get limited... reverb was used quite a lot though.
There is a dedicated 68K there, and one way to get past RAM limits is by doing software sample decompression... you got a LOOOT of power there to work with.

Dreamcast has same setup as Saturn except twice as many channels, no synthesizer, ADPCM support and few more effects, and controller is 45MHz ARM this time.
One could do software based synthesis on the ARM, there's loooots of power there, you only need like 1% of that power to do plain samples... rest being wasted. MD emulators on DC could very well have sound emulation pushed on the ARM instead, hell if Genecyst was able to emulate MD with sound on a 66MHz 486DX2 at half speed, doing sound alone on a 45MHz CPU would be quite easy, though probably not at full accuracy...


The 45 MHz ARM in the DC is capable of decoding MP3 or ogg-vorbis... which is generally what folks are going to use on the DC. I used libWildMIDI with my DC port of Doom, but that's because it's based on an old base and still support the MUS/MIDI music.

retrospiel
08-17-2010, 08:20 PM
It sounds like a FM / PCM mix, yeah.

tKPkPW6C9g0

c8eAcUYYF8o

Legend of Oasis / Story of Thor 2: http://www.youtube.com/watch?v=BGqIo4G39K0

kool kitty89
08-17-2010, 09:26 PM
Christuserloeser, where did you hear or read about the Saturn doing ADPCM in hardware? (I don't doubt that it can do it -I'd be surprised if the DSP wasn't useful for that, but I haven't seen it listed and others have argued otherwise)

I'm sure the programmers could elaborate on that too though. ;)

And the videos are hard to tell, they could easily be using sampled FM, though they could also be using synthesis. (it would depend on the amount of sampled they wanted to use and the amount of hardware channels desired -Tiido mentioned you sacrifice a channel with every FM operator used -unless it's DSP driven FM, but given what Tiido said it's unlikely the DSP was used for such)
If you wanted genesis quality FM (6 4-op channels) using the hardware synthesis, that would drop to 8 hardware PCM channels. (so a bit like the MCD+MD but with higher quality samples possible and more RAM -and no PSG)
In many cases, it would probably be useful to use a mix of different FM operator configurations. (a mix of 6-op, 4-op, and 2-op stuff or maybe 5 or 3 op too depending on the case to optimized for instruments used: a single operator would be useful for sine wave too)

It wouldn't be able to match an OPL3 in some cases though. ;) (though in many, many cases having 18 2-op FM channels -or the mix of limited 4-op channels- wouldn't really be preferable to fewer 4-up channels of the sort the OPM/OPN series use, let alone the flexibility of the Saturn's set-up)
The Saturn wouldn't be able to match the DX7's 16 6-op voices either for that matter. (or the OPL4 ;) -would have been interesting if the Saturn had used that, way cheaper and way less powerful than what they used though)


Sampling FM is not uncommon at all: very common for the SNES and N64 (and some PSX games), let alone CD-DA using FM compositions, some general midi instruments are sampled FM too for that matter.

retrospiel
08-17-2010, 09:42 PM
I agree that it's hard to tell. I hear a lot of pretty obvious samples (or at least what I think are samples) that do remind me of something you'd expect on SNES or N64 but all in all it's an entirely different bag: It all sounds a lot thicker, richer. Like a mix of FM and PCM.

Legend of Oasis / Story of Thor 2 on the other hand sounds a lot like Beyond Oasis / Story of Thor.

TrekkiesUnite118
08-18-2010, 12:07 AM
You mean all FM synthesis?




If I'm not mistaken, I'm pretty sure a chiptune can be anything from PSG to FM Synthesis to PCM. It doesn't necessarily have to be FM Synth. Just as long as it's not redbook audio or an MP3 or ADX or something like that which just loops a prerecorded track.

For example I'm pretty sure almost all of Capcoms 2D fighters use real time chip tunes. Same with most RPGs on the system and games like Panzer Dragoon 2, Saga, NiGHTS, Megaman 8 and X4, Sakura Wars, the CPS1 collection ports, etc. Just because it's not FM Synthesis doesn't mean it's not a chip tune.

kool kitty89
08-18-2010, 03:51 AM
I agree that it's hard to tell. I hear a lot of pretty obvious samples (or at least what I think are samples) that do remind me of something you'd expect on SNES or N64 but all in all it's an entirely different bag: It all sounds a lot thicker, richer. Like a mix of FM and PCM.

Legend of Oasis / Story of Thor 2 on the other hand sounds a lot like Beyond Oasis / Story of Thor.
One thing on the SNES and N64 is that you often have lower quality (or curtailed) samples due to limited cart space (and also due to wave RAM on the SNES -plus forced interpolation). On the saturn, it's mainly the RAM, so if that's sufficient, you can have really nice sounding samples that would be indistinguishable for realtime synthesis.

In particular, a lot of FM instruments might be relatively simple waveforms too, so small samples. (some complex instruments -especially 6-op- would be closer if not identical to the non-synth counterparts)
Plus you have other forms of synthesis as well, other than FM. (again, many of which the

Due to the more flexible polyphony of sample based music, it would probably be preferred in any case where RAM (or compression/quality sacrificing) wasn't an issue. Especially for any instruments that used relatively simple waveforms. (though with a pure sine wave you'd only use 1 channel either way)



TmEE,
What operators can the Saturn use for FM: is it only sine, or variable? (or is it user programmable -ie allowing you to modulate sampled waveforms with other samples: that would be really neat!)
And are there limits on the FM algorithms available?






If I'm not mistaken, I'm pretty sure a chiptune can be anything from PSG to FM Synthesis to PCM. It doesn't necessarily have to be FM Synth. Just as long as it's not redbook audio or an MP3 or ADX or something like that which just loops a prerecorded track.
I understand the broadness of the term, but some argue the application, which is why I asked: particularly as he mentioned PCM earlier in the post but then specified chiptune later on.

Some don't consider it a "chiptune" unless there's an actual "sound chip" though then the definition of that is pretty arguable too. *you could argue the SNES's sound system doesn't amount to a "chip" among other things)
I personally would include anything using arrangements played in realtime with some form of instruments played in hardware to be chiptune, but I avoid the term if possible due to such issues of ambiguity.

Oh, and you have straight streaming audio (or short looped segments too) in a lot of cases on the Amiga or ST (especially some ST intros -like Starglider), there's a lot of hybrids too, of stream+samples/PSG sound, etc. (and again "beat loops," volcals, and such).
So then you have "synthesis" or "chiptune" even more arguable. (when does looping a sample and looping a segment of music become distinct?) :D

Some wouldn't consider using samples as actual "synthesis" either (TmEE doesn't ;)), but that's semantics to a degree as well.

Also note that when I say wavetable synthesis, I was referring to actual wavetable synthesis and not sample based music so to speak. (wavetable synthesis uses a group of small samples that are built up to form the desired waveform with control of timbre as well as pitch and volume -it's more than that and I don't properly understand it, but it's a lot more complex than sampled audio)

TmEE
08-18-2010, 04:41 AM
TmEE,
What operators can the Saturn use for FM: is it only sine, or variable? (or is it user programmable -ie allowing you to modulate sampled waveforms with other samples: that would be really neat!)
And are there limits on the FM algorithms available?

Its not a general FM synthesizer (asd DSP is not doing it either, DSP is an additional separate block).

Each channel is either PCM channel or FM operator. If a channel is FM operator it will use some sample stored somewhere in the memory for its waveform, you can use any kind of waveform you want, and any lenght, as long as it fits in the RAM. Alogrithms are unlimited, you can tie the operators with each other in any way you want.

It is a veeeery powerful setup



As far as ADPCM goes, there is no hardware support for that, the chip plays only plain PCM. I really don't know the details or have forgotten them, but from what I have understood the DSP is not reconfigurable... it comes with its standard set and you got to live with it.
I need to read the docs when I have more time...

kool kitty89
08-18-2010, 05:04 AM
Its not a general FM synthesizer (asd DSP is not doing it either, DSP is an additional separate block).

Each channel is either PCM channel or FM operator. If a channel is FM operator it will use some sample stored somewhere in the memory for its waveform, you can use any kind of waveform you want, and any lenght, as long as it fits in the RAM. Alogrithms are unlimited, you can tie the operators with each other in any way you want.

It is a veeeery powerful setup
Oh, wow, so a LOT more than any of yamaha's normal FM stuff. (and a lot of cases where fewer operators would be necessary due to that)

That seems like it would be extremely flexible: I wonder how many cases it was used as a more typical FM synthesizer using only simple waveforms or sine and more typical algorithms as yamha synth used. (though the DX7 has a pretty large selection of algorithms)


As far as ADPCM goes, there is no hardware support for that, the chip plays only plain PCM. I really don't know the details or have forgotten them, but from what I have understood the DSP is not reconfigurable... it comes with its standard set and you got to live with it.
I need to read the docs when I have more time...
Hmm, so it's not programmable (no on-chip SRAM) and can't run microcode from the audio DRAM?
That would limit it a lot then (only effects/operations supported in embedded ROM): I wonder if the SNES or PSX DSP (or 3DO) is also all hard-coded like that without programmable microcode. (that would throw some of the DSP flexibility I assumed out the window)

If that was the case, the 68k would be the main option for decompression. (you might be able to use the CPUs if you could spare the resource, but that might be awkward if the CPUs can't directly access the wave RAM)

Can the SH2s access the audio block of RAM directly? For that matter, can the audio subsystem pull samples from main RAM? (or does the 68k at least have access to the main bus?)


I was thinking more in the context of how Flare had intended the DSP in the multisystem to be used (programmed in on-chip SRAM), or like some mass market DSPs running code from RAM (sometimes on-chip). (or the SSP-1601 DSP for that matter)
The Jaguar's "DSP" was intended with such flexibility as well, but wasn't strictly a DSP, but a more general purpose RISC microprocessor (more CPU like, and the same core used in the "GPU") though it did make for a capable DSP. (and with the limited 8 kB of local RAM, 4 kB wave ROM, and slow/cumbersome main bus connection, it seems best for computationally intensive and bus access light processing -so sample based stuff was rather detrimental in that case: had they forseen that plain sample based audio would have been dominant, they probably would have taken a cheaper route, probably DMA/DAC set-up --the tiny on-chip wave ROM had been intended to facilitate synthesis with the "DSP" without touching the main bus -something most developers didn't do, opting for sample based stuff instead -including a number of MOD players)


For the Saturn's PCM: are there significant limits for the format used (ie word size and sample rate) or is it pretty flexible for any depth up to 16 bit samples and sample rate up to 44.1 kHz? (or at least supports 4/8/12/16-bit PCM and upsampling of direct division/factors of 44.1 kHz if not stepped/variable sample rate -I'd gotten the impression that the SNES and MCD PCM chip had pretty variable sample rate up to 32 kHz)

TmEE
08-18-2010, 06:02 AM
DSP uses some DRAM for its own purposes, depending on what are you doing with it... I don't know the details. But code is run from internal ROM form what I know.

SH2's can access the sound stuff, and 68K can access the SH2 stuff... if you want you can run the Saturn off the 68K... if I have understood things right.

only 8 and 16 bit PCM is supported, and everything is scaled with interpolation to 44KHz, like in SNES (though SNES rate is 32KHz), but additional filter effects are not forced on you, you can use filtering when needed by means of DSP.
MCD just scales everything to 32KHz with no interpolation or filtering, producing veeery crisp sound.


EDIT:

OK

Seems the DSP gets its code from 68K, or can get it from 68K. I'm still not clear wether the "Standard library" is built into the chip or is loaded externally. It can be loaded externally form what I am understanding

kool kitty89
08-18-2010, 04:59 PM
SH2's can access the sound stuff, and 68K can access the SH2 stuff... if you want you can run the Saturn off the 68K... if I have understood things right.
So you could use main memory for additional audio data without having to page into the 512 kB audio block?



only 8 and 16 bit PCM is supported, and everything is scaled with interpolation to 44KHz, like in SNES (though SNES rate is 32KHz), but additional filter effects are not forced on you, you can use filtering when needed by means of DSP.
MCD just scales everything to 32KHz with no interpolation or filtering, producing veeery crisp sound.
That's too bad: it would have been really nice to have interpolation user selectable (especially on a channel basis), same for the SNES for that matter. (both interpolation and digital filtering -there's obvious cases where stuff sounds wrong without interpolation, but many cases where it's obviously better with no interpolation -others where it's not so much an issue either way- at least based on what I hear in ZSNES and SNES9x with and without interpolation -of course, ZSNES adds a number of alternate interpolation types to use as well)

Having more variable bit depth of samples would have been nice too (especially without compression), allowing trade-offs to be made depending on the sound/instrument used. (just as with sample rate)


Seems the DSP gets its code from 68K, or can get it from 68K. I'm still not clear wether the "Standard library" is built into the chip or is loaded externally. It can be loaded externally form what I am understanding
So it may be programmable, but there's a default set-up used. (it sounds like Sega may not have provided alternate default options either -leaving it up to programmers to do any custom configuration: assuming microcoding tools were provided)



If developers did opt for using software compression decoding on the 68k alone, how many simultaneous channels could have been managed like that? (using ADPCM or maybe another algorithm catering to 8-bit PCM -like what you and Chilly Willy used with the Z80 decompressor on spritesmind)

Could it also have been useful to use other sample word sizes with linear PCM and convert them on the fly in software to 8 or 16 bit PCM? (and correct volume accordingly)

Team Andromeda
08-18-2010, 06:08 PM
The Saturn's sound system was better than the N64. Sega used it in there high end Model 3 board to be exact.

Model 3 is using 2 Saturn Sound Boards to power it . Saturn sound was awesome when used right, Though from what one reads the lack of on board support for compression held it back, that and even game leading on the PS I guess.

For some of the best Sound to come of the Saturn chip one needs to play Radiant Silver Gun, Saga and Souky

NqUWiBGZz9c

GWVE6avpZSQ


Also the sound effects in Virtual Fighter are almost with out equal on any system, even now . Deep Fear had tops sound too (helped by ADX)

VyC0eNgQre8

kool kitty89
08-18-2010, 09:53 PM
Christuserloeser, again, where did you see reference to the Saturn using ADPCM before?
The 68k should certianly be able to handle it to some extent (not sure how many simultaneous channels you could decode though), and if the DSP was programmable, they should definitely have been able to implement a DSP program to support very fast ADPCM decoding. (let alone other compression schemes -again, one catering to 8-bit PCM would be great)

And, of course, there's using SH2 resource as well, and/or storing additional samples in main RAM is the audio block was too small. (like textures or tile data could be stored in main RAM if the dedicated 512 kB block was too small)

I wonder if the SH1 could be used for anything: from all I've heard from programmers, it was dedicated to CD-ROM duties, but I wonder if it was just not properly supported. (that would be a good chunk of added general purpose resource, and if it's true it was originally intended to be the main CPU as well as control the CD-ROM, it would certainly stand to reason that that functionality would have remained)
The 68000 is general purpose as it is (like the Z80 in the Genesis) and can be used for pretty much anything: it would have been great if the SH1 was like that too. (and when the CD-ROM drive is idle or just streaming red book audio, I think the SH1 is just idle too -like the 68k in the MCD: managing the CD-ROM drive as well as being a general purpose CPU, and being relatively free from overhead for Red Book streaming -though not loading game data and such iirc, and controlling the seek times for looping red book tracks)
The PCE CD was even simpler with main CPU overhead having to be used for CD-ROM iirc. (again, not so much an issue if the CD activity in-game is red book)

If any of the programmers could elaborate on some of this (or correct anything I'm mistaken on), it would be appreciated.



Also, does anyone know if any Saturn or PSX soundtracks used compressed streaming audio for the main soundtrack? (be it ADPCM or lower quality PCM like 8-bit PCM, lower sample rate, and/or mono audio streams) I mean other than for FMV, of course. (44.1 kHz stereo ADPCM would allow 4x as much audio on disc)

TmEE
08-19-2010, 04:57 AM
The DSP is not good for ADPCM decode, I could not notice any conditional stuff when I skimmed through the manual and you need that for ADPCM decompression.

ADPCM has been done on Saturn quite a lot, but its all software decompressed by the 68K. Sonic Jam streams all of its music and its all ADPCM except for some tunes in Sonic World. PSX games stream ADPCM too, i,e Duke Nukem: Time To Kill

From what I know, the SH1 is compltetely dedicated to CD-ROM, its got its own internal ROM (or ROM is embedded into some ASIC) and it does not allow any user code to be run in it... you have no control over it, you can only tell what you want but the SH1 is the boss.

kool kitty89
08-19-2010, 06:09 AM
ADPCM has been done on Saturn quite a lot, but its all software decompressed by the 68K. Sonic Jam streams all of its music and its all ADPCM except for some tunes in Sonic World. PSX games stream ADPCM too, i,e Duke Nukem: Time To Kill
So Sonic Jam's in-game stuff is all streamed and not synthesized?



And in the other consoles with ADPCM decoding sound systems (SNES, PSX, 3DO, Dreamcast, etc) the DSP is handling the decompression, right?

TmEE
08-19-2010, 06:23 AM
yeap, everything besides SFX is streamed ADPCM.

And perhaps not always DSP but dedicated decompressor, who knows...

kokujin
08-19-2010, 06:40 PM
So no games used FM sound?

TrekkiesUnite118
08-19-2010, 09:11 PM
So no games used FM sound?

As I said earlier I'm pretty sure the CPS1 ports done by Capcom do:

http://www.youtube.com/watch?v=U2A_IvnZfHQ

kokujin
08-19-2010, 09:18 PM
As I said earlier I'm pretty sure the CPS1 ports done by Capcom do:

http://www.youtube.com/watch?v=U2A_IvnZfHQ

I must have missed that post, sorry.It sounds different from the arcade version, so it might be FM.I was kind of hoping it would be a newer game.

TrekkiesUnite118
08-19-2010, 09:25 PM
I must have missed that post, sorry.It sounds different from the arcade version, so it might be FM.I was kind of hoping it would be a newer game.

It sounds rather spot on to me, what sounds different?

retrospiel
08-19-2010, 10:04 PM
Panzer Dragoon Zwei, Story of Thor 2 aka Legend of Oasis, Nights, maybe others.



It sounds like a FM / PCM mix, yeah.

tKPkPW6C9g0

c8eAcUYYF8o

Legend of Oasis / Story of Thor 2: http://www.youtube.com/watch?v=BGqIo4G39K0


Definitely ADPCM: Shin Shinobi Den / Shinobi Legions / X, Sonic Jam, Sega Ages: Disney Collection, Thunder Force Gold Pack #2, etc.

kool kitty89
08-20-2010, 01:09 AM
yeap, everything besides SFX is streamed ADPCM.

And perhaps not always DSP but dedicated decompressor, who knows...
OK.
It seems that the original Soundblaster line used an Intel MCU for ADPCM decoding too. (I wonder how many games used that rather than just PCM)

Decoding a single (or stereo) ADPCM stream would be less intensive than decoding a large number of samples at once, wouldn't it? (ie what you'd have to do if you wanted to effectively approximate a multi-channel ADPCM sample based synthesizer) If you tried to do that and hit a wall with 68k resource, you could always limit compression to a practical number of channels and use additional channels for plain PCM.
Again, for 8-bit samples, it would probably be preferable to use a compression scheme catering to that specifically.




Panzer Dragoon Zwei, Story of Thor 2 aka Legend of Oasis, Nights, maybe others.
Is there any way to tell if something is using FM or straight samples without looking at actual code/data used?

From what Tiido described, the Saturn's FM is by far more complex and flexible than any common FM synthesizer or FM chip: it COULD be used for plain sine based FM, but that would be rather wasteful, or it could be used with sine as well as a number of simple waveforms (like the OPL3 did), but it can go beyond that too: any waveform can be used with any other waveform for FM, the waveforms used are samples: so it's FM sample synthesis so to speak. (I think the Jaguar also had support for that in the SDK)

You have 32 channels (with 8 or 16 bit PCM waveforms) to use as operators in any combination and any algorithm, plus additive synthesis thereof as well. (depending on the DSP functionality, it might be useful for doing additive synthesis without wasting hardware channels -or full wavetable synthesis, but I'm not sure of the nature of the DSP)

If you wanted to fully emulate a YM2612, you'd have to use 24 channels/operators for such, all with sine waves, and limited to the algorithms used by Yamaha in that chip, so a bit of a waste and obviously not what one would do, unless you had some particular reason for emulating it. (emulating the YM2151 with hardware FM would use all 32 channels)
You wouldn't even be able to emulate an OPL3 ;). (that has 36 operators -18 2-op channels, or up to 6 4-op channels -though limited algos compared to the OPM/OPN chips)

With 32 channels, it could also be useful to do a lot of stuff just with additive synthesis alone too, but again, that's a bit wasteful compared to the real potential. (you could probably simulate what the MT-32 does to a fair extent -though I think that also applies subtractive synthesis too, maybe the DSP could be useful there -but would also be more flexible due to the programmable samples -MT32 was in ROM)


Definitely ADPCM: Shin Shinobi Den / Shinobi Legions / X, Sonic Jam, Sega Ages: Disney Collection, Thunder Force Gold Pack #2, etc.
Would that mean streaming ADPCM like Jam, or ADPCM samples? (opposed to PCM samples)



Edit: it's of course pretty easy to tell when a game is NOT using streaming audio due to the lack of disc spinning, though there may be cases where there's still disc activity in spite of synthesized/sampled audio being used.

Team Andromeda
08-20-2010, 11:46 AM
Edit: it's of course pretty easy to tell when a game is NOT using streaming audio due to the lack of disc spinning, though there may be cases where there's still disc activity in spite of synthesized/sampled audio being used.

And the access light is a give away too . Dracula X is streaming music and what a music score it is , I Am The Wind is a awesome track. Astal streams music too

Jasper061992
08-20-2010, 08:20 PM
Never was very knowledgeable about the Saturn or it's hardware very much in general (only have a very few games for it). But after slightly skimming through the most important comments, all I must say WOW. I learned something new. I didn't know the 68k inside the Saturn can be used as the main CPU with the Dual SH2s in idle. Also the Saturn's audio subsystem sounds very robust going by the comments here. But speaking of the FM synth capability of the Saturn, how similar is it to the Mega Drive's YM2612 chip? Does it have very different FM waveforms or can it perfectly replicate all FM waveforms including the entire Yamaha synth family?


Moreover, no one has mentioned of the PSP's audio capabilities. I assume it's roughly inline with the Dreamcast/PS2 audio chips? I know it has a dedicated MIPS CPU for MPEG decompression and sample playback with it's own 2MB block of embedded RAM.

kool kitty89
08-20-2010, 10:57 PM
And the access light is a give away too . Dracula X is streaming music and what a music score it is , I Am The Wind is a awesome track. Astal streams music too
Yeah, but access/spinning could mean streaming data not related to sound at all. ;)

Constant and consistent stop and go loading would be indicative of PCM other than CD-DA, or ADPCM. (or other compressed audio) Though that would still not be definitive alone. (other data could stream in a similar manner; in fact, I think that's the reason some games opting for onboard sound for music and not streaming: to facilitated on-the-fly game data updates)

The only reasons not to use CD-DA (or other streaming audio) would really be down to: wanting large/long compositions and not wanting to use multiple discs (and even streaming compressed or reduced quality audio was unsuitable) and using more discs was not desirable, too much space went to FMV and using more discs was undesirable, dynamic compositions were desired and seek times for segmented streamed tracks were unsuitable, or on-the-fly loading was used for things other than music. (you could also have cases of games using streaming soundtracks and some areas using onboard sound for all the music -Sonic CD did that even, or using onboard sound durring FMV to reduce bandwidth used for streaming audio -if not eliminate it entirely for video only)

One other thing for FMV heavy games could be using some of the audio tracks from cutscenes in-game as well. (and only decoding the audio part -be it compressed or just lower quality PCM)




Oh, and does anyone know of the PlayStation having a dedicated audio CPU/controller? I've never seen any reference to such. (vs the SNES's 2 MHz 8-bit 6502 derived SPC700 CPU -the MD had the Z80, Saturn 68k, and DC ARM7, but in those cases they were also general purpose CPUs, not dedicated to the audio subsystem like the SPC)

For totally PCM based audio (sample and streams), DMA channels and DAC is all you really need: CPU resource used for any additional effects or compression. (or some of that supported in hardware) Other forms of synthesis are far more intensive, compression can be too (and some other effects), so dedicated hardware or coprocessors for that can be significant (or just opting for a faster main CPU and staying simple). It's other forms of synthesis that really get intensive: and have largely fallen from favor anyway. (may of those were more attractive when memory was expensive -one limitign factor for sample based synthesis, though it's more complex than that) Streaming audio is most common anyway, of course. (and much more flexible for developers -no catering to specific sound hardware: though programmable samples are simpler to deal with likewise than man other forms of synthesis -and again, not very resource intensive to manage in software)
Of course, with DMA, you don't have the overhead of software managed PCM playback like on the PCE/TG-16, Genesis, ST, SMS, A8, C64, Speccy, CPC, MSX, etc, etc. (Amiga has DMA sound, so does sound blaster) The NES's DPCM channel also has DMA iirc.

kool kitty89
08-20-2010, 11:36 PM
Never was very knowledgeable about the Saturn or it's hardware very much in general (only have a very few games for it). But after slightly skimming through the most important comments, all I must say WOW. I learned something new. I didn't know the 68k inside the Saturn can be used as the main CPU with the Dual SH2s in idle. Also the Saturn's audio subsystem sounds very robust going by the comments here. But speaking of the FM synth capability of the Saturn, how similar is it to the Mega Drive's YM2612 chip? Does it have very different FM waveforms or can it perfectly replicate all FM waveforms including the entire Yamaha synth family?
It's not Yamaha FM synth: as TmEE said, it's the 32 PCM channels treated as FM operators configurable as any number of FM channels (even a single 32-op channel) using any waveforms that can fit into RAM.

So you could emulate Yamha chips directly, but that would be wasting the potential: it would take all 32 channels using only sine wave to emulate a YM2151 and 24 channels to emulate a YM2612, 18 channels to emulate an OPL1 or OPL2, and couldn't emulate an OPL3 (as that has 36 operators).
It also wouldn't be able to emulate a DX7's 16x 6-op channels (it could do 5 6-op channels as such).
You also can't go past 44.1 kHz I believe, so the sample rate isn't as high as Yamha FM. (not that it too much matters)

Having fully programmable waveforms up to very large sized waveforms allows a LOT of stuff though, but using it effectively is different from sine wave based FM, or even the more varied selection of waveforms found in the OPL3. (you may often want to use a simple waveform as an operator though, but a more complex samples would almost always be desirable for effective use) For any simple FM synth waveforms, it would often be best to simply sample them (the simpler the waveform, the smaller the sample, and you could have REALLY tiny samples -and in most cases you could use 8-bit PCM -I think all yamaha FM is 8-bit output)

I think pretty much any waveform you could get from 2-op FM (a la OPL or OPL2) would probably fit as very small samples. (4-op stuff and maybe some OPL3 2-op stuff could be larger, and 6-op stuff could be very complex)

For a lot of more complex instruments, to minimize sample size, you'd probably have a samples of the attack, mid-note, and decay, not the entire note. ( a lot of SNES and Amiga stuff is mid-note only I think, and may simulate attack and decay with pitch/volume)


Moreover, no one has mentioned of the PSP's audio capabilities. I assume it's roughly inline with the Dreamcast/PS2 audio chips? I know it has a dedicated MIPS CPU for MPEG decompression and sample playback with it's own 2MB block of embedded RAM.
Dreamcast's is very powerful with dedicated audio subsystem, powerful DSP, and 45 MHz ARM7, and 2 MB of 66 MHz 16-bit SDRAM, 64 hardware ADPCM/PCM channels, but not the FM feature of the Saturn. (but adds hardware ADPCM decoding -or at least ADPCM support with the DSP)
So the sound system alone has more CPU resource than the Saturn or PSX. ;)

PS2 has 2MB of dedicated audio RAM and 48 PCM/ADPCM at 44.1 or 48 kHz channels software mixed with the "SPU2" (not sure what that is), I presume it's not the MIPS R3000 as that's described separately as the I/O CPU with separate 2MB of I/O memory -using it for sound as well as I/O, probably would have been a good cost saving engineering decision though -compatibility being the main reason for its presence like the Z80 in the Genesis)

I think the GC and Xbox just have plain DMA sound channels and use main CPU resource for the rest. (as the N64 did and later consoles I think -and onboard sound on PCs) It really makes the most sense to do that due to the main trends for audio at the time. (one good use for a coprocessor would be facilitating MP3 decoding without the CPU taking a hit -DC didn't need the DSP for that though, just the ARM -Arm could be used for non sound related stuff too -more complex game engines or perhaps some software graphics effects, or maybe offloading the game logic/ai and allowing the main CPU to be used for other stuff)

GBA and DS are all DMA driven audio with CPU resource for extra stuff. (no sure if the DS's was even upgraded beyond GBA PWM, or if the added RAM, ROM, and CPU resource are the only differences)
I'd hazard a guess that the PSP is similar as well. (but with far more CPU resource; both should be capable of MP3 decoding depending on how CPU intensive a game is)

l_oliveira
08-21-2010, 02:08 AM
Playstation and Playstation 2 audio are CPU driven.

On the Playstation, an generic driver provided by SCEI or custom drivers developed by the companies which make the games (Square loves to make it's own drivers)

There's two types of synthesizer they use on the PS2:

Software synthesizer on the Emotion Engine where samples are sampled using the EE CPU and one of the vector units (usually on 2D games where they have the vector units free as they're not doing 3D). Sampled data is streamed to the SPU2 chip (which is a pair of PS1 sound chips slapped together like an YM2612 has 2 YM2204 inside where one can feedback onto the other)

Or they can use a driver on the IOP (IO processor, which on the PS2 mode does control the IO devices but is the CPU when on PS1 mode)...

The PS2 is designed around an sort of "DMA engine" which allows for either one of the two CPUs (EE or IOP) be the main processor.

Just like when Tiido said that one can drive the whole Saturn with the 68k, one can do the same with the PS2 IOP (MIPS R3000).

Team Andromeda
08-21-2010, 04:04 AM
Yeah, but access/spinning could mean streaming data not related to sound at all. ;)



Yes, but when you go to the Sound Test mode, select the music and still see the red light light access in full constant use (like in Dracula X) That's a bit of given away that its streaming , don't you think ?

kool kitty89
08-21-2010, 05:22 AM
Yes, but when you go to the Sound Test mode, select the music and still see the red light light access in full constant use (like in Dracula X) That's a bit of given away that its streaming , don't you think ?
For all games with sound test. :)

Plus putting it in an audio CD player or PC. (though that wouldn't tell you anything about compressed streaming audio unless WAV or other PC compatible files were actually used)




Playstation and Playstation 2 audio are CPU driven.
But the PS1 does have a dedicated DSP and ADPCM decompression for 24 channels. (the CPU doesn't have to software mix 24 channels, does it? -they're 24 hardware channels, or mixed by the DSP, right?)



Sampled data is streamed to the SPU2 chip (which is a pair of PS1 sound chips slapped together like an YM2612 has 2 YM2204 inside where one can feedback onto the other)
YM2204, what's that? (I haven't heard of that before) I thought the YM2612 was basically taking the FM block of the OPN (YM2203) and doubling it while omitting the SSG channels and I/O ports, plus integrating a DAC. Or rather, taking a YM2608 (which already had 3 more FM channels added among other things to the YM2203) that was cut way back and added a DAC. (I think one of only 2 such Yamaha chips not using an external DAC -the other beign the YM2413, though that used a different method that resulted in aliased output and usually had an external filter added to reduce that)


The PS2 is designed around an sort of "DMA engine" which allows for either one of the two CPUs (EE or IOP) be the main processor.

Just like when Tiido said that one can drive the whole Saturn with the 68k, one can do the same with the PS2 IOP (MIPS R3000).
Interesting, again, I wonder if the same is true of the DC's ARM7. (it's certainly true for the Z80 in the Genesis, though in that case, the Z80 also has the bank switching overhead when working in 68k mapped address space -and a slow serial bank mechanism for 32 kB rather than parallel)

m68k
08-21-2010, 08:52 AM
Going by the comments here, if the saturn can run in 68k mode, perhaps somewhere down the line in the design phase it was to have Genesis backwards compatibility, but they pulled the required IC due to cost constraints as the saturn already was too complex?

Jasper061992
08-21-2010, 11:28 AM
It's not Yamaha FM synth: as TmEE said, it's the 32 PCM channels treated as FM operators configurable as any number of FM channels (even a single 32-op channel) using any waveforms that can fit into RAM.

Yeah, I knew it isn't directly related to the older Yamaha FM Synths, although the saturn's audio subsystem was manufactured by them.


So you could emulate Yamaha chips directly, but that would be wasting the potential: it would take all 32 channels using only sine wave to emulate a YM2151 and 24 channels to emulate a YM2612, 18 channels to emulate an OPL1 or OPL2, and couldn't emulate an OPL3 (as that has 36 operators).
It also wouldn't be able to emulate a DX7's 16x 6-op channels (it could do 5 6-op channels as such).
You also can't go past 44.1 kHz I believe, so the sample rate isn't as high as Yamha FM. (not that it too much matters)

That does does sound like a big waste. You probably could get better results trying to emulate an existing FM chip via sampling. I know the PS1's SPU chip is very capable at such. I have a copy of Metal slug X for the PS1, a Neo Geo port and can clearly hear the FM sounds in the music. Very similar to what you would hear from the Mega Drive. The Neo Geo has the YM2610 right?




Dreamcast's is very powerful with dedicated audio subsystem, powerful DSP, and 45 MHz ARM7, and 2 MB of 66 MHz 16-bit SDRAM, 64 hardware ADPCM/PCM channels, but not the FM feature of the Saturn. (but adds hardware ADPCM decoding -or at least ADPCM support with the DSP)
So the sound system alone has more CPU resource than the Saturn or PSX. ;)

I personally think it doesn't matter that the Dreamcast loses native FM synthesis playback. The Dreamcast sound chip in all other areas have a big advantage to what the Saturn had in total, unless I'm missing something? For example, ADPCM playback (don't fully understand the difference between ADPCM and plain PCM yet, but I'm sure it's an advantage having ADPCM too?), far more channels, much more powerful CPU controller that is general purpose enough for said sound chip and for other tasks. I even think the 45MHZ Yamaha ARM chip is even powerful enough to emulate one of the yamaha FM synths during controlling the sound chip, right? If so, that somewhat makes up for the lack of real FM playback.


PS2 has 2MB of dedicated audio RAM and 48 PCM/ADPCM at 44.1 or 48 kHz channels software mixed with the "SPU2" (not sure what that is), I presume it's not the MIPS R3000 as that's described separately as the I/O CPU with separate 2MB of I/O memory -using it for sound as well as I/O, probably would have been a good cost saving engineering decision though -compatibility being the main reason for its presence like the Z80 in the Genesis)

I always thought of the PS2's sound subsystem as a lazyish extension to the PS1's sound chip. The same existing SPU1 chip with 24 channels tacking on another = 48 channels. Not sure if the SPU2 has any new underlying features from the SPU1, but looking on paper, the only improvements the PS2's sound subsystem have over the PS1 is.....another SPU chip.....and more sample memory that can improve sound quality. Not sure if the old R3000A can help as an audio controller though. Then again, maybe the original SPU chip was capable enough on competing with the Dreamcast/Xbox/Gamecube's audio capabilities only held back by limited sound channels and limited audio memory.


I think the GC and Xbox just have plain DMA sound channels and use main CPU resource for the rest. (as the N64 did and later consoles I think -and onboard sound on PCs) It really makes the most sense to do that due to the main trends for audio at the time. (one good use for a coprocessor would be facilitating MP3 decoding without the CPU taking a hit -DC didn't need the DSP for that though, just the ARM -Arm could be used for non sound related stuff too -more complex game engines or perhaps some software graphics effects, or maybe offloading the game logic/ai and allowing the main CPU to be used for other stuff)

It only reminds me of the PS3. I felt they should of at least kept the EE chip with it's own 32MB RAM as a coprocessor for audio processing, as soundcontroller for a dedicated sound chip, and/or as an I/O CPU like the PS2 for PS3 games. Also for PS2 backwards compatibility. I don't know, sounds like it would have been alot more expensive for Sony in the long run and probably wouldn't have hit hardware profitability all now.


GBA and DS are all DMA driven audio with CPU resource for extra stuff. (no sure if the DS's was even upgraded beyond GBA PWM, or if the added RAM, ROM, and CPU resource are the only differences)
I'd hazard a guess that the PSP is similar as well. (but with far more CPU resource; both should be capable of MP3 decoding depending on how CPU intensive a game is)

I always thought of the DS as an extended GBA for the most part, with just a few more processors. The DS's audio sounds very similar to the GBA's audio. The GBA always had that static kinda sound to it with a rare snap crackle and pop when trying to play back samples, something the DS does sometimes aswell to a slightly lesser extent. The DS only has 16 audio channels right? Aside from that, the PSP is fully capable of MP3 playback, I have MP3 music loaded to it.


Going by the comments here, if the saturn can run in 68k mode, perhaps somewhere down the line in the design phase it was to have Genesis backwards compatibility, but they pulled the required IC due to cost constraints as the saturn already was too complex?

That would have opened doors to possibilities for devs to port over existing Mega Drive games to the Saturn without even touching the Dual SH-2's. All they'd have to change in the code, was the graphics, the audio and the memory management. Am I missing something more? :p I even think 32x ports is a possibility on the Saturn by using those Dual SH-2s inside, but again need some changes to get it working on Saturn still. Who's up for a Knuckles Chaotix port to the Saturn?!?! :lol:

kool kitty89
08-21-2010, 08:42 PM
Going by the comments here, if the saturn can run in 68k mode, perhaps somewhere down the line in the design phase it was to have Genesis backwards compatibility, but they pulled the required IC due to cost constraints as the saturn already was too complex?

Nah, not really, it's just a common CPU, there's no evidence of the Saturn ever having any part of the Genesis architecture (let alone Sega CD) in it. (hell, the 68k in the Saturn isn't even fully compatible with the one in the Genesis or MCD -68EC000 has some changes to it)

The Saturn wouldn't be running in "68k mode" either, it would still have full use of all processors: the point is that the 68k is just not limited to audio alone, but can work on the main system bus along with the SH2s. (and the SH2s can contribute to driving audio as well) It could be really useful if you had a game where the logic/AI game part of the game engine could be handled by the 68k alone and the SH2s fully dedicated to graphics related duties. (or at least offload some stuff onto the 68k)

Conversely, the PC-FX is missing the PCE/TG-16's CPU (or compatible), but there's tons of evidence of planned compatibility due to the entire PCE/SuperGrafx audio and video hardware being included. (like the Genesis, which included all the SMS audio and video hardware too -except the SMS video can't be used on top of the Genesis video, it's just there for compatibility and a waste otherwise -probably forced trade-offs to the MD VDP too -like colors or subpalettes)




Yeah, I knew it isn't directly related to the older Yamaha FM Synths, although the saturn's audio subsystem was manufactured by them.
I think it was actually designed by Yamaha too, not just manufactured (Yamaha was a major chip vendor for Sega, including producing the VDP for the MD and some other custom Sega designed components)
But yeah, not really like any discrete yamaha FM hardware before that.


That does does sound like a big waste. You probably could get better results trying to emulate an existing FM chip via sampling. I know the PS1's SPU chip is very capable at such. I have a copy of Metal slug X for the PS1, a Neo Geo port and can clearly hear the FM sounds in the music. Very similar to what you would hear from the Mega Drive. The Neo Geo has the YM2610 right?
Yeah, but the hardware FM capabilities should be VERY useful in their own right, it's just a waste to use them for something far, far simpler than what they can be used for. (using more complex and varies waveforms for operators -and also using FM for more than just creating music but other effects on samples too -the DSP should be useful for a lot of effects too)

Neo Geo has the YM2610, yeah, 4 4-op FM channels (2 less than the Genesis), 3 SSG channels (same as the YM2149/AY chip from the ST, MSX, Speccy, Intellivision, Vectrex, CPC, etc) and 5 ADPCM channels.
Apparently a lot of late Neo Geo games use the ADPCM channels almost exclusively. (I'm not sure if that's using instruments with all pre-shifted pitch for music -a lot of ROM to fit all that- or if that could be handled in software as well -and if ADPCM had to be used, or if the channels could be used for plain PCM too -that should have facilitated MOD players and such)



I personally think it doesn't matter that the Dreamcast loses native FM synthesis playback. The Dreamcast sound chip in all other areas have a big advantage to what the Saturn had in total, unless I'm missing something? For example, ADPCM playback (don't fully understand the difference between ADPCM and plain PCM yet, but I'm sure it's an advantage having ADPCM too?), far more channels, much more powerful CPU controller that is general purpose enough for said sound chip and for other tasks. I even think the 45MHZ Yamaha ARM chip is even powerful enough to emulate one of the yamaha FM synths during controlling the sound chip, right? If so, that somewhat makes up for the lack of real FM playback.
Yeah, the FM was pretty much a waste on the Saturn, and for most common uses the DC is better in every respect (and better than the PS2 in many areas), though both the Saturn and DC sound systems are overkill in some respects. (I wonder how much the DSP was actually used, or the ARM7 for that matter -the ARM could be really useful though, from streaming MP3 audio, or used to a major part of a game engine to offload from the main CPU -assuming it's able to use the main bus like the 68k in the Saturn)

As for ADPCM, it's just compression: 4-bit ADPCM data is 1/4 the size of 16-bit PCM (4:1 compression) for the same sample rate (like 44.1 kHz for CD-DA), though it is lossy compression, so it's not full quality, and also doesn't decompress to 16 bit PCM, but 12-bit iirc. (so it's really 3:1 compression)
There's tons of other compression algorithms too, both lossless and lossy, some catering more only for larger audio streams vs small samples (I think MP3 is like that) Some of those would include relatives of 4-bit ADPCM, including some catering to 8-bit PCM samples. (Chilly Willy and TmEE implemented 2 such schems for decompressing and playing 8-bit PCM on the Genesis using only the Z80, one 3:1 compression and one 4:1 with somewhat lower quality -also 8:1, but with a lot of quality lost, all at 22 kHz playback too)

So in the Saturn's case, it doesn't have hardware support for ADPCM and it seems like the DSP might not be useful either, but the 68k could be used for software decoding of ADPCM or a lot of other compression schemes depending on the complexity (so not MP3 audio streams ;)), plus you could dig into SH2 resource too. I know some games use the 68k to decode stereo ADPCM streams, but I'm not sure how many use if to decode ADPCM samples (or other compressed samples) for sample playback and music. (there would be a limit of how many simultaneous streams it could decode, but the question would be what that number is -and it would vary depending on the compression schemes used too)



I always thought of the PS2's sound subsystem as a lazyish extension to the PS1's sound chip. The same existing SPU1 chip with 24 channels tacking on another = 48 channels. Not sure if the SPU2 has any new underlying features from the SPU1, but looking on paper, the only improvements the PS2's sound subsystem have over the PS1 is.....another SPU chip.....and more sample memory that can improve sound quality. Not sure if the old R3000A can help as an audio controller though. Then again, maybe the original SPU chip was capable enough on competing with the Dreamcast/Xbox/Gamecube's audio capabilities only held back by limited sound channels and limited audio memory.
Nah, not lazy, efficient: they finally seem to have taken notice that complex sound systems were really unnecessary, in fact, they probably wouldn't have even needed more than the original 24 hardware channels for most PS2 games. (something that allowed MP3 streaming without hitting the main CPU might have been significant though -I think the MIPS R3000 could be useful for that though and as mentioned above it can bse used to drive sound too: I wouldn't think its I/O duties would really take up a ton of CPU resource)
The last console that probably could have really needed a bit more of a boost for audio is the N64 due to the general design... though even there the use of general CPU or RSP resource with simple DMA sound hardware worked out fine. (thus, boosting CPU/RSP resource in general would have been more useful, or making other changes to reduce bottlenecks -mainly made to save cost and some probably to save time: the CPU doesn't have proper DMA to main RAM and thus a large amount of wait states/latency compared to what it should have from what I understand -fixing that seems liek it would have been mainly a time/R&D issue, not a cost one: using separate CPU and RSP buses would have been a cost decision)




It only reminds me of the PS3. I felt they should of at least kept the EE chip with it's own 32MB RAM as a coprocessor for audio processing, as soundcontroller for a dedicated sound chip, and/or as an I/O CPU like the PS2 for PS3 games. Also for PS2 backwards compatibility. I don't know, sounds like it would have been alot more expensive for Sony in the long run and probably wouldn't have hit hardware profitability all now.
That would have been a massive waste... even in the PS2 it was a bit overkill for a lot of things, though probably a good option in more intensive examples (MP3 decoding perhaps).
The EE was another matter entirely and, from what I understand, the rather complex PS2 design didn't really facilitate cost effective integration of hardware compatibility in the PS3 overall. (plus it used pretty much off the shelf video hardware, eliminating the option for embedding backwards compatibility into the architecture)

The PS1's design was pretty simple and clean and I think it rather facilitated embedding for compatibility (or integrating compatibility modes in newer hardware rather than dedicated chunks of chips or entire chips) at relatively limited cost detriment, the PS2's hardware isn't really like that from what I understand, and the PS3's design didn't really help things. (the PS2's design had a lot of other ramifications -namely difficult to program for, and especially tough to really push the performance compared to DC, GC, or Xbox -or PS1)
They probably could have put the EE to good use as a coprocessor of some sort and perhaps made a relatively efficient PS2 compatible design (mix of hardware and software emulation where practical), but that's not what happened, and with the PS3 design they did come out with and how expensive it was, cutting the EE made some sense. (plus thter had been compatibility issues regardless)

In hindsight, going from the PS1 hardware, Sony almost certainly could have come out with successors that facilitated backwards and forwards compatibility better. (not to mention fit better on the market -it's hard to imagine how the PS2 might have done on the market if a bit more ideal in terms of hardware given how massively popular it was already)



I always thought of the DS as an extended GBA for the most part, with just a few more processors. The DS's audio sounds very similar to the GBA's audio. The GBA always had that static kinda sound to it with a rare snap crackle and pop when trying to play back samples, something the DS does sometimes aswell to a slightly lesser extent. The DS only has 16 audio channels right? Aside from that, the PSP is fully capable of MP3 playback, I have MP3 music loaded to it.
GBA's sound was often heavily supplemented by GB sound and used fewer and lower quality samples with less CPU resouce (for any compression or software mixing), so even using the same PWM DACs (almost identical to the 32x -though probably with proper DMA documentation from the start), sound could be much better simply due to CPU resource and more RAM and ROM.

The GBA has only 1 hardware channel, or one stereo channel rather, like the 32x, the rest is up to software mixing (but it is DMA loaded audio, not just a bare DAC, so CPU resource is MUCH, MUCH less than the Genesis or real life 32x games -Sega didn't support the DMA feature for some reason, so you have games pouring a ton of CPU time into audio instead -the difference between ~4-8 channels and more like 32 software mixed channels with DMA -the utility of such would be limited by the amount of memory available and memory bandwidth)
So either the DS adds more hardware audio channels or the "16 channels" is just the standard number of channels mixed by a default sound driver or such. (and not a hard limit -such specs are often oversimplified and misleading -like the Saturn's "32 PCM or 8 FM channels" when FM is fully programmable and coudl easily be 16 2-op channels, so that would be the real max number of FM channels, though that's still missing the context)

The DS adds a lot more video hardware I think, not just the faster ARM7 and added ARM9 CPU/SOC (and more RAM), I'd gotten the impression that some of that was embedded in the ARM9 SOC too. (particularly some hardware support more useful for 3D rendering -unless it does all that in software)

The DS should easily be capable of MP3 playback as well given the CPU resource (the ARM7 alone should be enough), but using that in-game could be limiting depending on the CPU resource needed for said game.

mick_aka
08-22-2010, 07:08 AM
Going by the comments here, if the saturn can run in 68k mode, perhaps somewhere down the line in the design phase it was to have Genesis backwards compatibility, but they pulled the required IC due to cost constraints as the saturn already was too complex?

MegaCD/SegaCD compatibility was definitely on the cards in its original unrevised specification, but I've yet to see anything that suggests that MegaDrive/Genesis cartridge compatibility was ever considered...

tomaitheous
08-22-2010, 09:13 AM
As for ADPCM, it's just compression: 4-bit ADPCM data is 1/4 the size of 16-bit PCM (4:1 compression) for the same sample rate (like 44.1 kHz for CD-DA), though it is lossy compression, so it's not full quality, and also doesn't decompress to 16 bit PCM, but 12-bit iirc. (so it's really 3:1 compression)

It's not limited to 12bit. It's just that some hardware playback devices were setup with 12bit DACs (on some encoding software, you had to be careful not to accumulate more than 12bit depth, or you'd getting clipping on the sample. I.e. the sample will inverse in the opposite polarity. Later chips fixed that by saturating the accumulation to the matched DACs depth). You can decompress to 16bit and even more, if the DAC supports it.

IIRC, Chilly Willy and TmEE's compression works/examples weren't like normal/official/true/whatever ADPCM scheme (it wasn't a two layer indexed system into a delta table).

jdWYOHPV6Uw (noise for low volume parts are from that particular system. It has low sound output. SGX and TG16 have less noise output).

Jasper061992
08-22-2010, 08:11 PM
This thread also got me thinking. Seen as the GBA's audio is supplemented with the original GB sound chip (Zilog CPU clone), how does the DS retain the original PSG sound channels if the DS has the Zilog clone removed?

evildragon
08-22-2010, 08:18 PM
Because the PSG could be a separate chip? ;)

I don't see it anywhere, but I have heard some PSG in SNES aswell..

tomaitheous
08-22-2010, 09:23 PM
This thread also got me thinking. Seen as the GBA's audio is supplemented with the original GB sound chip (Zilog CPU clone), how does the DS retain the original PSG sound channels if the DS has the Zilog clone removed?

It was just on the same package as the cpu (which also included the video part of the original GB). Not a big deal to include it in its own package or with another IC setup. NEC did the same thing with PCE sound chip, which was originally included on the CPU package of the PCE. But later took the audio chip and packaged it with an ADPCM chip for the PCFX. Hell, even the later Genesis models had the FM sound chip package into a single ASIC too.

m68k
08-23-2010, 12:05 AM
Well, the DSP capabilities for synth were used in Segata Sanshiro Shinken yuugi. In his mini-games, a synthesized non CD audio music plays. In the run through the burning building fire minigame, there is an awesome remix of his theme that sounds like a sound blaster midi synth

Da_Shocker
08-23-2010, 12:49 AM
I've always thought that Sega wasn't going to make the Saturn backwards compatible with the Genesis but the pre-release Saturn's(my avatar) cart port looks jsut like a Genesis cart port. In fact IDK what the hell happened to the Saturn which use to look like a super sexy system.

retrospiel
08-23-2010, 11:56 AM
^ Yeah, this is a super sexy Saturn variant indeed.




Tom Kalinske: We all knew that there would come a day when the Genesis would no longer have a life, and we'd have to move on to the next technology. There was of course, a big debate as how best to go about that.

From the various interviews here at Sega-16 we do know that Sega of America was very much against introducing a successor in 1993 or even 1994. (They however did introduce the Genesis 2 and Sega CD 2 in late 1993.)

At that time Sega of Japan and Sega of America agreed that they should keep focusing on their Mega Drive / Genesis product line but also improve the console's capabilities to keep it competitive.

Sega of Japan's design was some kind of Mega Drive 2 or "Giga Drive" if you will. A fully compatible but enhanced Mega Drive with a couple of additional features like more colors, a 3D co-processor and probably some additional PCM channels.

Instead of your Mega Drive / Genesis, you'd hook up your "Giga Drive" to your SCD. The CDX as we know it probably wouldn't have existed (it was released after Project Mars was cancelled), instead it would have been a GD+SCD-in-1.

Sega of America's proposal was 32X/Neptune. Very similar in its options if you think about it, yet different in its add-on approach.



Focusing on their Mega Drive/Genesis product line meant that Saturn wouldn't be compatible and that it was introduced as a high end machine with a high launch price and small library of games.

A very bad idea that obviously was made at a time when no one took PlayStation serious.

And only months before the 16-bit market collapsed.


Personally I think it would have been the much better idea to just make Saturn compatible with the Mega Drive / Genesis - like all previous Sega consoles were compatible to their predecessors.

Da_Shocker
08-23-2010, 12:49 PM
I don't think backwards compatibility would've made much of a difference. It's not why the Genesis was such a success nor was it the reason why the Saturn and DC failed miserably. But on to something else I wish there was a sound program out for the Saturn. I would'nt mind delving into it sometime.

TrekkiesUnite118
08-23-2010, 01:31 PM
With the popularity of the Genesis in the US, it probably would have at least helped sell Saturns. If in 1995 you wanted a Genesis, you could just buy a Saturn instead and still be able to play Genesis stuff and play new Saturn stuff as it came out. That was part of what made the PS2 sell well.

Da_Shocker
08-23-2010, 01:46 PM
I think the DVD drive was bigger factor than BC. If the DC had DVD out of the box or BC with Saturn which one would make financial sense?

Silanda
08-23-2010, 07:02 PM
I think the DVD drive was bigger factor than BC. If the DC had DVD out of the box or BC with Saturn which one would make financial sense?

Neither option is good from a financial standpoint. Remember that the DC was released in Japan in 98 so a DC with a DVD drive would either have needed to be significantly more expensive than it actually was, or Sega would have eaten a big loss early in its life (which they couldn't have afforded to do). Would it have sold more Dreamcasts and blunted the launch of the PS2? Certainly. Would it have bankrupted Sega? Possibly.

Globally backwards compatibility with the Saturn would have been a total waste of money though as the Saturn had been a total bomb. Saturn BC with the MD/Genesis may have been another story, especially if the Genesis' life had been prolonged.

mick_aka
08-23-2010, 07:48 PM
Lets also consider the fact that the Panasonic DVD player I brought to replace my Laserdisc in '98 was almost 600, and at the time was the cheapest model available.

I remember a lot of the better DVD players at that point being around the 1000 mark (I think Denon or B&O released one around '98 or '99 for 1200!)

So as has already been touched on, do you really think after the epic cluster-fuck that was made of the Saturn and it's over-pricing compared to the PlayStation, that anyone in their right mind would have dropped 500 or 600 on a Dreamcast with a DVD player?

kool kitty89
08-24-2010, 04:07 AM
MegaCD/SegaCD compatibility was definitely on the cards in its original unrevised specification, but I've yet to see anything that suggests that MegaDrive/Genesis cartridge compatibility was ever considered...
Any design that would dhave included MCD compatibility would have included MD cart compatibility. ;) (it wouldn't make sense not to as you need all the genesis console hardware for MCD games) It would be like making the CD-X, Wondermega, or PCE Duo without a cart/card slot. :p

I think an earlier design concept (pre-saturn, perhaps "gigadrive" and certainly if the Mars hardware was older -not sure on that), but the Saturn design (the final and the supposed pre-1994 version) wasn't configured around compatibility from any (even moderately credible) available information.
There's really a lot of mystery and missing information though, most locked away in Japan.

Again, the PC-FX shows considerable signs of backwards compatibility (all it really needed was the CPU and necessary ports -along with compatible bios -I think the memory map may already be compatible).





It's not limited to 12bit. It's just that some hardware playback devices were setup with 12bit DACs (on some encoding software, you had to be careful not to accumulate more than 12bit depth, or you'd getting clipping on the sample. I.e. the sample will inverse in the opposite polarity. Later chips fixed that by saturating the accumulation to the matched DACs depth). You can decompress to 16bit and even more, if the DAC supports it.
OK, thanks for the clarification: does the compression ratio vary too? (would decompressing to 16-bit be 4:1 or 2:1 for 8-bit?) Some cases cut it below 12-bit too, don't they? (I remember you mentioning the PCE CD's ADPCM chip outputs 10-bit PCM)



IIRC, Chilly Willy and TmEE's compression works/examples weren't like normal/official/true/whatever ADPCM scheme (it wasn't a two layer indexed system into a delta table).
I wasn't saying it was similar to true ADPCM (Chilly's in particular is a 2-bit variant of CVSD from what I recall, with the 8:1 compression being a direct derivative of 1-bit CVSD), but what I meant was that it catered to higher compression ratios for 8-bit samples than ADPCM would do. (unless I'm mistaken)




Because the PSG could be a separate chip? ;)

I don't see it anywhere, but I have heard some PSG in SNES aswell..
PSG on the SNES is sampled. :p (just like any on the Amiga -technically the PCE uses "samples" too though fixed to only 32 words and 5-bit resolution: PSG sounds on the N64 would apply there too, and some on Saturn and PSX -some CD-DA tracks or other streaming stuff too and some later consoles using it)





Well, the DSP capabilities for synth were used in Segata Sanshiro Shinken yuugi. In his mini-games, a synthesized non CD audio music plays. In the run through the burning building fire minigame, there is an awesome remix of his theme that sounds like a sound blaster midi synth
That wouldn't have to use the DSP, the SCSP is quite capable of PCM and very flexible programmable FM (as above) by itself, plus there's the 68k too. (and possibility of main CPU resource too)

So unless you know of some DSP specific effects used, I'm not sure why you'd think that.






I've always thought that Sega wasn't going to make the Saturn backwards compatible with the Genesis but the pre-release Saturn's(my avatar) cart port looks jsut like a Genesis cart port. In fact IDK what the hell happened to the Saturn which use to look like a super sexy system.
The Shape of the cart slot really doesn't say anything: plus that's the western cart slot it resembles, not the JP MD one. ;)

A stronger indicator would have been a common pinout AND matching 64-pin connector.
Regardless, there's no hardware in the saturn that facilitated MD or MCD compatibility and not even any to really suggest it was ever planned for that hardware. (again, perhaps an earlier or parallel design)

The cart slot was used as a general expansion port (namely RAM and ROM), though it may have tied to the so-called Jupiter project as well. (plus the ST-V, though I'm not sure the ST-V's cart slot is really similar to the Saturn's)

TmEE
08-24-2010, 05:17 AM
one tidbit regarding sample rate - in FM, sample rate is extremely important.. for example all the distortion guitars and spark will sound wrong if played on a different chip and/or with different clock

kool kitty89
08-24-2010, 05:19 AM
From the various interviews here at Sega-16 we do know that Sega of America was very much against introducing a successor in 1993 or even 1994. (They however did introduce the Genesis 2 and Sega CD 2 in late 1993.)
Heh, they were pushing for a successor though, regardless of when they wanted it released. :) (vigorously jumping at the opportunity SGI offered in early 1993, and later on there was the attempted collaboration with Sony -not to get into further details)

It's a shame SoA didn't push so hard against that for Mars/32x given what happened... let alone wait another few months to release the Saturn properly in late 1995.



At that time Sega of Japan and Sega of America agreed that they should keep focusing on their Mega Drive / Genesis product line but also improve the console's capabilities to keep it competitive.
And they's doen that with the Sega CD, though the support was sort of mish-mash and SoA never kicked in any really good across-the-board marketing. (ie emphasis on arcade game ports, animation, sound, scaling and rotation -and more- with the ASIC and sub CPU, lower priced games, etc: all on top of multimedia)

That and on-cart expansion seemed to miss out too. (they had quite a lot facilitated on the cart slot, particularly facilitating audio expansion -see my recent thread on that) More of the SVP could have been nice, but there was a lot of other (especially much less expensive) stuff too: color wouldn't change without video overlay, but audio and general graphical rendering capabilities could have for sure. (from simpler PCM -or synth- expansions to the Ricoh chips sega used in the arcade and MCD to various coprocessors -maybe even the ASIC in the MCD or added CPUs -though anything requiring RAM and/or a lot of board space would be more cost intensive and there is a limit power wise as well)
And they could.should have started well before the SVP with some that stuff. (like '92 or '93 -probably with better PCM, the simplest and cheapest option should have been a plain DAC with DMA loading, again see my latest thread)

And of course, there's software alone: both experienced programmers and larger ROM sizes competing against late fare on other consoles.
As it was there wasn't really any non-mode 7, non-enhanced, late SNES game that couldn't have been done reasonably well on the Genesis. (some stuff wouldn't look as good or sound as good -depending a lot on the developer and personal preference, but there were still inherent advantages as well) Again, there's no reason they couldn't have fought fire with fire for the enhancment chips, added RAM, etc. (audio, graphical or general purpose coprocessors, and decompression ASICs -or use one of the more general purpose co-processors for that too: some stuff might have even been able to be embedded onto the ROM IC and save cost for high production count games)



Sega of Japan's design was some kind of Mega Drive 2 or "Giga Drive" if you will. A fully compatible but enhanced Mega Drive with a couple of additional features like more colors, a 3D co-processor and probably some additional PCM channels.
Which design? You mean something older in the pipeline around 1992? (and Mars obviously)
But none of that applies to the final Saturn (or even the supposedly more limited 1993 Saturn -supposedly no SH2s, VDP1, or geometry DSP, but we don't have hard information either way -even less for Mars or Gigadrive)

Where did you get the idea that Mars would ever have been related to the Saturn? It's not like the PC-FX where they obviously had a design intending compatibility at some point, but a totally unrelated system. (there's even less evidence than the SNES intending to support NES games -which isn't even close: the main "evidence" in the final design being the CPU architecture -not really definitive at all as there's other reasons for that- and the controller port I/O -which could easily have been done to save on R&D costs -granted there's some stronger evidence tied to earlier design proposals and mock-ups I believe)

The Saturn's complex design isn't something Sega threw together in 1994, if anything it had some additions and some tweaks (possibly some rushed stuff contributing to bugs -would explain the VDP1 transparency problem if it was added later or significantly enhanced over its original form), but nothing that seems at all related to the 32x, cancellation of Mars, or intended backwards compatibility. (though could easily be related to the PSX or Project Reality announced in late 1993)



Instead of your Mega Drive / Genesis, you'd hook up your "Giga Drive" to your SCD. The CDX as we know it probably wouldn't have existed (it was released after Project Mars was cancelled), instead it would have been a GD+SCD-in-1.
Umm, the CD-X definitely would have been in the works in 1993 given the release date... it's not something they threw together at the last minute. (again, it's a bit odd that Sega didn't put work into a western friendly low-cost integrated duo console contemporary to the high-end Japan-centric JVC Wondermega for '93 and '94 that could be significantly cheaper than the Genesis+CD costs combined and thus attractive to new users -ie something ~$300 US by mid/late 1993 and perhaps $200 by late 1994)

Though given the relatively niche market for the CD in the US (and more so in Europe), let alone the appeal for a new console (opposed to an add-on) being greater for new buyers than current users, it doesn't really make sense. (plus I think the MCD is still limited by the original BIOS and interface, though it might have been possibly to circumvent some of that on a new console -probably better than trying to use the ASIC to render to the 32x framebuffer at least)
Maybe if Mars had been as cheap or cheaper than the 32x alone (ie no more than $160 at launch) it might have been better, though it's doubtful you could have something on the level of the 32x for just $160.

And it's still moot with the Saturn being totally unrelated and incompatible with the MD, MCD, Mars, OR 32x. (closest relation was probably the CPUs in the 32x, which makes sense given the Saturn's design -or redesign- in 1994 supposedly influenced the 32x)
Had SoJ suggested the Jupiter to SoA in early 1994, that would have been another matter entirely. :p



Sega of America's proposal was 32X/Neptune. Very similar in its options if you think about it, yet different in its add-on approach.
We really have no idea what Mars was to be like, so we can't know how similar it was at all. (we have no solid information of the VDP configuration or enhancement, CPUs, RAM, sound hardware, etc, etc)
I wouldn't even trust that 128 color figure from pettus. (if you do go by that, it's still so vague you can speculate like crazy: just double the soubpalettes with nothing else added to the VDP and a faster CPU or DSP to help with simple 3D, or something like the SuperGrafx with dual VDPs, maybe more RAM -especially double buffered video RAM, added sound hardware, etc; but we know next to nothing)



Focusing on their Mega Drive/Genesis product line meant that Saturn wouldn't be compatible and that it was introduced as a high end machine with a high launch price and small library of games.
If anything: focusing on the MD/Genesis would have been all the more reason for backwards compatibility, so I don't see your argument there at all. (the shift in consoles in 1993 would be a better argument for that being dropped, though given the lack of evidence of there ever being compatibility on the Saturn, it makes rather little sense)



A very bad idea that obviously was made at a time when no one took PlayStation serious.
They took it seriously in Japane. :p and not just that, but by late 1993 there was both the PSX AND Project Reality from Nintendo to worry about, not to mention the 3DO and Jaguar potentially being problems. (they turned out to be non-issues though, and to soem extent that could have been prediced at the time -3DO with the market model/price, though untested, and late Japanese release, and less so with Atari as you'd have to have inside information about funding and management -other than the fact that their brand name in the US had declined a good bit by 1993, had no name in Japan, and they neglected the potentially strong European market -albeit not without reason: trying to impress big US investors)


And only months before the 16-bit market collapsed.
Huh? The 4th gen consoles were strong through 1996 (even a decent amount in 1997), both peaked around 1993/1994 I believe (though the SNES declined more gradually from 1995 onward) and the mess they made on the market in '94/95 let alone weakening software lineup did nothing to slow the decline of the Genesis. There was no collapse though, just like the NES in 1989/1990 there was a peak and then a gradual decline and shift into the budget market sector.
In Japan it obviously fell much more quickly for the MD (not sure about the PCE/CD -though games seem to be pretty strong up to 1996), but the SFC seems to have held on as market leader until 1995 at least and still had close to 1/3 the market in '96. (more market Share than the Saturn by some accounts and not too far behind the PSX -1997 was a huge shift though)



Personally I think it would have been the much better idea to just make Saturn compatible with the Mega Drive / Genesis - like all previous Sega consoles were compatible to their predecessors.
Yeah, having backwards compatibility like Mars/32x/Neptune did would have been nice, but probably not all that critical regardless (obviously from a retro/collector's standpoint it would have been awesome and for any manor user too: I'm sure a ton of people wished the SNES played NES games or N64 SNES games, but the lack of compatibility wasn't a major factor there: neither was the presence of compatibility on the MD -especially due to the required adaptor, and I highly doubt the PS2 would have been crippled without PSX compatibility). The Atari 7800 and Game boy lines are probably the best cases of consoles benefitting from compatibility.

You can certainly argue it, and if it's cost effective or (especially) cost/time advantageous to include (like the Wii or GBC) there's not really a down side, but in the long run (in most cases), it really isn't the deciding factor. (for home computers that's another matter entirely though)


And now we've gone off topic to the old Saturn backwards compatibility thread: http://www.sega-16.com/forum/showthread.php?t=11345 :lol:






I don't think backwards compatibility would've made much of a difference. It's not why the Genesis was such a success nor was it the reason why the Saturn and DC failed miserably. But on to something else I wish there was a sound program out for the Saturn. I would'nt mind delving into it sometime.
Yeah, I agree: if anything it probably would have been most important early on with users transitioning and late games being released. (though designing the hardware to facilitate fluid cross-platform development would have been a factor for that to some extent, but for any interested in playing older games or their established collections it's another matter -any well optimized backwards compatible/evolutionary system would likely have facilitated ports rather fluidly anyway: granted, cases of such hardware are rather rare, especially cases where it's not a more modest upgrade -like the Wii)

It merited it more than any previous Sega platform in terms of library, but as history has shown, no console on the market was made or broken by that alone. (the 5200 really wasn't an issue with that -other issues, especially those related to Atari and nt the 5200 are more significant at the time- and it was more the fact of the competing consoles -especially Coleco- having adapters that was the big issue: not sure why they couldn't sue for patent infringement on TIA)

As it was, the Genesis probably would have been better off had they designed it without backwards compatibility in mind at all. (at worst it would have been cheaper and maybe released a little sooner, but more likely it would have had a more capable VDP -probably less color limits if nothing else: more palettes and larger master palette- and maybe more advanced sound or more RAM -or double buffered video RAM: if omitting compatibility had facilitated R&D put into making it a full DRAM system, that would have been REALLY significant: cheap DRAM would have facilitated double buffered video RAM and more main RAM and still had lower cost in many respects -especially in the long run)






Neither option is good from a financial standpoint. Remember that the DC was released in Japan in 98 so a DC with a DVD drive would either have needed to be significantly more expensive than it actually was, or Sega would have eaten a big loss early in its life (which they couldn't have afforded to do). Would it have sold more Dreamcasts and blunted the launch of the PS2? Certainly. Would it have bankrupted Sega? Possibly.
I don't think it would have been a good idea even if the Saturn had lasted longer and the DC not been released until 2000. Remember Sony had a huge advantage in vertical integration, but on top of integration of hardware manufacturing, they also had a big advantage of owning the patents to a lot of the DVD format/drive hardware and DVD video. (so you have overhead not only for DVD-ROM drive licensing or buying off the shelf, but 2 fold if you want to add DVD video support)

What is surprising is that Sega didn't include VCD support out of the box (should have been possible to do that all in software by that point too): not so much an issue in the US (or even Europe AFIK), but a significant factor for Japan and mainland Asia with VCD very popular.
Maybe Sega could have even marketed their own improved GD-ROM video format along with VCD support. (higher max bitrate and better compression: MPEG-2 if licensing cost wasn't an issue)
Hell, maybe they could even have negotiated that with the SVCD format being established at the time. (ie license the GD-ROM format for that use, though given the Chinese politics involved, I'm not sure how that might have panned out -alternatively SVCD support on the DC might have been nice too)



Globally backwards compatibility with the Saturn would have been a total waste of money though as the Saturn had been a total bomb. Saturn BC with the MD/Genesis may have been another story, especially if the Genesis' life had been prolonged.
Plus the Saturn's hardware hardly facilitated low-cost compatibility like the PSX did. ;) (unless they'd stuck more closely to the Saturn architecture -which has corresponding issues) That's the main reason the PS2 wasn't easy to integrate into the PS3. (the complexity of the PS2 and general shift in architecture of the PS3)

With the 32x on the market, forward compatibility of 32x games to Saturn (and general hardware similarities) would have been a lot more important (32x and Saturn being released concurrently), hence my thoughts on the so-called Jupiter.

kool kitty89
08-24-2010, 05:52 AM
one tidbit regarding sample rate - in FM, sample rate is extremely important.. for example all the distortion guitars and spark will sound wrong if played on a different chip and/or with different clock
Hmm, so that would be an issue in Fusion's emulation? (or does it emulate at the full clock rate and then downsample for the actual mixer/output? -as would happen to some extent on an analog level in a lot of real consoles)
Would that get screwed up for samples of FM instruments as well?

Also, was I correct in assuming that the compression schemes used by you and Chilly Willie for the MD Z80 are better suited for compressing 8-bit PCM samples/streams than 4-bit ADPCM is for that purpose? (apart from being less computationally intensive) Or that other schemes would also be better suited for 8-bit PCM specifically than normal ADPCM.

TmEE
08-24-2010, 07:50 AM
Fusion does something funky which is definitely not correct technically... it kinda seems to scale down the bandwidth, so that things that would fit into 53KHz fit nicely into 44.1KHz.

And they are more meant for 8bit but you can use if for 16bits too but then deltas need ot be scaled a bit in case of T-ADPCM for things like square waves etc.
Chilly's inplementation actually uses 16bit data, lower part is discarded in Z80 playback :P

TrekkiesUnite118
08-24-2010, 01:41 PM
I think the DVD drive was bigger factor than BC. If the DC had DVD out of the box or BC with Saturn which one would make financial sense?

DVD helped too, but BC with the PS1 was also a big selling point at the time as well. A lot of stores around here offered trade-ins because of it where you could trade in a PS1 and get 50% off a PS2. DVD was probably the biggest factor for PS2's success, but BC was probably the 2nd biggest factor. If Saturn had Genesis and Sega CD Compatibility, it probably would have sold better and the $400 price tag would have seemed a bit more justified as people would have seen it more as three systems in one.



As it was, the Genesis probably would have been better off had they designed it without backwards compatibility in mind at all. (at worst it would have been cheaper and maybe released a little sooner, but more likely it would have had a more capable VDP -probably less color limits if nothing else: more palettes and larger master palette- and maybe more advanced sound or more RAM -or double buffered video RAM: if omitting compatibility had facilitated R&D put into making it a full DRAM system, that would have been REALLY significant: cheap DRAM would have facilitated double buffered video RAM and more main RAM and still had lower cost in many respects -especially in the long run)



Um, I'm pretty sure the VDP has little to do with color limits. Isn't there an arcade board that uses the exact same hardware but can have more colors? I highly doubt removing Master System compatibility would have made the Genesis anymore powerful.

Chilly Willy
08-24-2010, 04:03 PM
ADPCM is only 2:1 compared to storing the raw 8 bit sample as it is 4:1 compared to the original 16 bit sample. My 1 bit CVSD format was 8:1 compared to storing the raw 8 bit sample, or 16:1 compared to the original 16 bit sample. It was not suitable for anything but sound effects that needed heavy compression. The 2 bit CVSD was much better sounding, and even could be used for music in a pinch. It was 4:1 compared to storing a raw 8 bit sample, or 8:1 compared to the original 16 bit sample.

Tiido's scheme was 3:1 compared to storing a raw 8 bit sample, or 6:1 compared to original 16 bit sample. It was kind of a cross between CVSD and ADPCM and sounded better than the 2 bit CVSD. I'd use Tiido's compression scheme for music, and my 2 bit scheme for sound effects... unless you needed more compression, then I'd use my 2 bit CVSD for music and the 1 bit CVSD for sound effects.

I'd only use the 1 bit CVSD for music if you needed lots of music that couldn't be done any other way but sampled. An example would be the bootleg Harry Potter game for the MD - they used REALLY shitty compression for the music, taken from the movie. Even my 1 bit CVSD would sound better than whatever compression they used.

kool kitty89
08-24-2010, 07:28 PM
Um, I'm pretty sure the VDP has little to do with color limits. Isn't there an arcade board that uses the exact same hardware but can have more colors? I highly doubt removing Master System compatibility would have made the Genesis anymore powerful.
All arcade board to use the MD VDP used it later on, just like the SMS's VDP. ;)

And yes, removing SMS compatibility easily could have allowed more capabilities:
For the VDP, you've got to include the entire SMS VDP onboard as it's totally unrelated to the MD VDP and thus takes up a big chunk of silicon and adds to development time and cost to implement the circuitry that could otherwise have facilitated 8 (maybe even 16) subpalettes instead of 4 and use of 12-bit RGB instead of 9-bit.
Then there's the Z80/RAM costs, pull those out and you've just saved a good amount of cost and board space (and thus more cost), not to mention the need to design circuitry to interface the Z80 to the 68k bus, etc.

Then you have room for other, much cheaper enhancement too: a single 8-bit DAC with DMA support on a custom chip would have greatly facilitated good PCM playback (they could have done more like 2 DACs or a 10 bit DAC, etc, but a single 8-bit DAC is the minimal option), maybe dual YM2612s, or using a YM2164 instead (stereo YM2151) among other things.
The Z80 is not cost effective at all for what it's used for in the Genesis.

You also have some other changes which may or may not have been at all effected by omitting compatibility: the VDP pixel bus output being connected to the expansion port and/or expanded cartridge port, YS added to the expansion port, full address range on the expansion port, VDP palette information on the expansion port, etc. (or drop the expansion port and go with expansion all on the cart slot -especially using outboard pins like the 7800 or SNES to keep normal cart costs down)
Maybe even a pixel accumulation mode for the VDP to allow half resolution 256 color tile or sprite layer modes.

Not to mention more time to allow implementation of DRAM instead of PSRAM for main memory, and double buffered DRAM instead of VRAM for video. (not only cutting cost -especially in the long run- but eliminating the VDP bandwidth issues and allowing 128 or 256 kB of main RAM to be used and still save on cost compared to PSRAM)

At worst, if you strip it all out, you've got a cheaper and easier to integrate system (maybe could have launched at $150 in 1989), but it's more likely that more features would have been added and more optimization would have taken place. (both due to R&D time and resources spent on compatibility and the general cost of adding it) In which case they could have also focused more on on-cart enhancement. (albeit that's limited -audio would be the easiest)

I'll try and dig up some older discussions on this.

Edit:
See these discussions/posts:
http://sega-16.com/forum/showthread.php?p=216127
http://sega-16.com/forum/showthread.php?p=216848

http://sega-16.com/forum/showthread.php?t=10271

http://sega-16.com/forum/showthread.php?p=194814




ADPCM is only 2:1 compared to storing the raw 8 bit sample as it is 4:1 compared to the original 16 bit sample. My 1 bit CVSD format was 8:1 compared to storing the raw 8 bit sample, or 16:1 compared to the original 16 bit sample. It was not suitable for anything but sound effects that needed heavy compression. The 2 bit CVSD was much better sounding, and even could be used for music in a pinch. It was 4:1 compared to storing a raw 8 bit sample, or 8:1 compared to the original 16 bit sample.

Tiido's scheme was 3:1 compared to storing a raw 8 bit sample, or 6:1 compared to original 16 bit sample. It was kind of a cross between CVSD and ADPCM and sounded better than the 2 bit CVSD. I'd use Tiido's compression scheme for music, and my 2 bit scheme for sound effects... unless you needed more compression, then I'd use my 2 bit CVSD for music and the 1 bit CVSD for sound effects.
Are the schemes you used also less computationally intensive than ADPCM?

I know you mentioned that since it was all with the Z80, nothing more than 16-bit math was used, so something aimed at the 68k (ie on the Saturn) might be optimized differently -let alone using an SH2. (though that could be more on the decoding software used rather than the compression format itself)

Chilly Willy
08-24-2010, 08:33 PM
Are the schemes you used also less computationally intensive than ADPCM?

Yes. The ADPCM used for the SNES, PSX, etc are fairly computationally heavy... some even require floating point math! The CVSD routines I made, and the process by which I implemented Tiido's scheme are simple enough that the Z80 has no trouble decompressing mono 8-bit sound at 22 to 24 kHz.


I know you mentioned that since it was all with the Z80, nothing more than 16-bit math was used, so something aimed at the 68k (ie on the Saturn) might be optimized differently -let alone using an SH2. (though that could be more on the decoding software used rather than the compression format itself)

Yes, I'd probably use slightly different code on the 68000 or SH2, but the 16 bit math was mainly done to keep the code on the Z80. I was interested in how good I could do real-time decompression with just the Z80. The idea at the time was to perhaps add music to Wolf32X that way - play the music via the Z80 on the DAC independently of the rest of the game. I still might do that.

kool kitty89
08-24-2010, 08:49 PM
Yes. The ADPCM used for the SNES, PSX, etc are fairly computationally heavy... some even require floating point math! The CVSD routines I made, and the process by which I implemented Tiido's scheme are simple enough that the Z80 has no trouble decompressing mono 8-bit sound at 22 to 24 kHz.
That would also be significant for plain genesis games for compressed samples too. (might be useful for Tiido's engine too whenever a single PCM channel would be acceptable)
Doing that back in the Genesis/MD's heyday would obviously have been advantageous too, especially with the number of games using single channel playback anyway.
I wonder why something like that wasn't ever done (or extremely rarely -I haven't heard of any such realtime decompression other than DPCM in SMPS and maybe some RLE compressed stuff -Tomaitheous mentioned that was used for some PCM on the PC Engine at least), it seems like it was more common to drop to 4-bit PCM in such cases. (maybe other depths -that probably would be the more practical option for games mixing 2 or 4 channels)

In the context of the Saturn, that would mean that (as I was guessing) such compression schemes would be preferable to use for 8-bit samples compared to ADPCM. (or 16-bit samples too with the higher compression ratio, though I'd imagine the quality wouldn't be as good as ADPCM, but would make more sense to fit more samples and particularly for using the 68k for software decompression for sample based synthesis -managing several PCM streams)
In the case of your 2-bit CVSD derivative, on the saturn, that would mean double the amount of sample data to be stored than ADPCM. (though not with the same quality)
And in the Saturn's case you could be using 44.1 kHz samples. (wouldn't that also make 1-bit CVSD more acceptable in some cases?)

I'd imagine there would be other possible lossy compression schemes that could have been attractive as well at the time. (rather than ADPCM)


Yes, I'd probably use slightly different code on the 68000 or SH2, but the 16 bit math was mainly done to keep the code on the Z80. I was interested in how good I could do real-time decompression with just the Z80. The idea at the time was to perhaps add music to Wolf32X that way - play the music via the Z80 on the DAC independently of the rest of the game. I still might do that.
Doing it all as streaming audio and not FM? (wouldn't that take up a ton of cart space?) Couldn't you also have the Z80 use PWM and not use the 6th FM channel? (it would seem like compressing all the sound effects would also be advantageous, unless you already did that) Plus you've got the DMA working now, so a lot less overhead for that.

tomaitheous
08-24-2010, 09:07 PM
Yes. The ADPCM used for the SNES, PSX, etc are fairly computationally heavy... some even require floating point math! The CVSD routines I made, and the process by which I implemented Tiido's scheme are simple enough that the Z80 has no trouble decompressing mono 8-bit sound at 22 to 24 kHz.

Well, if you ignore the filter flag per block, it's actually simpler than Dialogic's ADPCM (which is what most people/docs refer to when using the term ADPCM). There's no delta index. Just direct 4bit signed deltas with a 4bit shift value for every 16 samples (nibbles). Nothing more than direct addition. Dialogic's ADPCM is all addition too, but you have two layers of addition plus indexing. :)

I'd go so far as to say calling BRR used in SNES (and I assume the same format on the PS1) as ADPCM is pretty misleading. Sony even calls it BRR in their dosc, IIRC, and not ADPCM. But I could be wrong.

I can't remember with version/scheme and setting you guys used, but IIRC I think the 3:1 one (relative to 8bit source) sounded pretty good.

TrekkiesUnite118
08-24-2010, 09:31 PM
All arcade board to use the MD VDP used it later on, just like the SMS's VDP. ;)

And yes, removing SMS compatibility easily could have allowed more capabilities:
For the VDP, you've got to include the entire SMS VDP onboard as it's totally unrelated to the MD VDP and thus takes up a big chunk of silicon and adds to development time and cost to implement the circuitry that could otherwise have facilitated 8 (maybe even 16) subpalettes instead of 4 and use of 12-bit RGB instead of 9-bit.
Then there's the Z80/RAM costs, pull those out and you've just saved a good amount of cost and board space (and thus more cost), not to mention the need to design circuitry to interface the Z80 to the 68k bus, etc.

Then you have room for other, much cheaper enhancement too: a single 8-bit DAC with DMA support on a custom chip would have greatly facilitated good PCM playback (they could have done more like 2 DACs or a 10 bit DAC, etc, but a single 8-bit DAC is the minimal option), maybe dual YM2612s, or using a YM2164 instead (stereo YM2151) among other things.
The Z80 is not cost effective at all for what it's used for in the Genesis.

You also have some other changes which may or may not have been at all effected by omitting compatibility: the VDP pixel bus output being connected to the expansion port and/or expanded cartridge port, YS added to the expansion port, full address range on the expansion port, VDP palette information on the expansion port, etc. (or drop the expansion port and go with expansion all on the cart slot -especially using outboard pins like the 7800 or SNES to keep normal cart costs down)
Maybe even a pixel accumulation mode for the VDP to allow half resolution 256 color tile or sprite layer modes.

Not to mention more time to allow implementation of DRAM instead of PSRAM for main memory, and double buffered DRAM instead of VRAM for video. (not only cutting cost -especially in the long run- but eliminating the VDP bandwidth issues and allowing 128 or 256 kB of main RAM to be used and still save on cost compared to PSRAM)

At worst, if you strip it all out, you've got a cheaper and easier to integrate system (maybe could have launched at $150 in 1989), but it's more likely that more features would have been added and more optimization would have taken place. (both due to R&D time and resources spent on compatibility and the general cost of adding it) In which case they could have also focused more on on-cart enhancement. (albeit that's limited -audio would be the easiest)

I'll try and dig up some older discussions on this.

Edit:
See these discussions/posts:
http://sega-16.com/forum/showthread.php?p=216127
http://sega-16.com/forum/showthread.php?p=216848

http://sega-16.com/forum/showthread.php?t=10271

http://sega-16.com/forum/showthread.php?p=194814




Are the schemes you used also less computationally intensive than ADPCM?

I know you mentioned that since it was all with the Z80, nothing more than 16-bit math was used, so something aimed at the 68k (ie on the Saturn) might be optimized differently -let alone using an SH2. (though that could be more on the decoding software used rather than the compression format itself)

You do realize that the Z80 is used as the sound CPU for all of Sega's 16-bit Arcade hardware right? Since the Genesis is based off that exact same hardware, it only makes sense to include the Z80 as the sound CPU, as it also gives the benefit of Master System compatibility while also making porting System-16 sound engines over to the Genesis fairly easy. In fact, we don't see the Z80 leave Sega's Arcade hardware as a sound CPU until Model 1 hardware, with the exception of the C2 board. Looking at other 16 bit Arcade hardware we continue to see the Z80 being used as a sound CPU such as the CPS1 board, the CPS2 Board, The Konami boards used to run games like TMNT, Gradius 3 use it as a sound CPU, hell even the Neo Geo uses the Z80 as a Sound CPU. It's far more likely that Sega used it in the Genesis as a Sound CPU because almost every High End Arcade board at the time used it for the exact same thing. After all this was the intended purpose of the Genesis, to bring 16-bit Arcade titles to the home market. Master System Compatibility was an added benefit of the chip.

tomaitheous
08-24-2010, 09:54 PM
You do realize that the Z80 is used as the sound CPU for all of Sega's 16-bit Arcade hardware right? Since the Genesis is based off that exact same hardware, it only makes sense to include the Z80 as the sound CPU, as it also gives the benefit of Master System compatibility while also making porting System-16 sound engines over to the Genesis fairly easy. In fact, we don't see the Z80 leave Sega's Arcade hardware as a sound CPU until Model 1 hardware, with the exception of the C2 board. Looking at other 16 bit Arcade hardware we continue to see the Z80 being used as a sound CPU such as the CPS1 board, the CPS2 Board, The Konami boards used to run games like TMNT, Gradius 3 use it as a sound CPU, hell even the Neo Geo uses the Z80 as a Sound CPU. It's far more likely that Sega used it in the Genesis as a Sound CPU because almost every High End Arcade board at the time used it for the exact same thing. After all this was the intended purpose of the Genesis, to bring 16-bit Arcade titles to the home market. Master System Compatibility was an added benefit of the chip.

Doesn't change the fact that having a z80 for sound control is waaaaay overkill. Arcades tend to be overkill and that's fine because they are completely different beasts than home system.

But looking at the cost of the z80 just for audio reasons on the MD - is a rather poor cost decision. Sound engines take up about 1-2% cpu resource per frame (1/60th). It's definitely overkill. It was there first and foremost for backwards compatibility. Not because they needed it for 'porting' sound engines from arcade games. That's ridiculous (and if that were true, Sega really had some boneheads working on system designs). As it is, the z80 is a poor work around for any sort of real sample playback. It's definitely better than nothing, but that doesn't mean it isn't wasteful cost wise, for what it serves on MD/Genesis only games.



Um, I'm pretty sure the VDP has little to do with color limits. Isn't there an arcade board that uses the exact same hardware but can have more colors? I highly doubt removing Master System compatibility would have made the Genesis anymore powerful.
The VDP has everything to do with color. All the color ram is inside the VDP. Removing SMS modes could have cut costs to have another 576bits (72 bytes) of color ram and have each layer selectable as to which bank of 64 colors to choose.

kool kitty89
08-24-2010, 10:03 PM
You do realize that the Z80 is used as the sound CPU for all of Sega's 16-bit Arcade hardware right? Since the Genesis is based off that exact same hardware, it only makes sense to include the Z80 as the sound CPU, as it also gives the benefit of Master System compatibility while also making porting System-16 sound engines over to the Genesis fairly easy. In fact, we don't see the Z80 leave Sega's Arcade hardware as a sound CPU until Model 1 hardware, with the exception of the C2 board. Looking at other 16 bit Arcade hardware we continue to see the Z80 being used as a sound CPU such as the CPS1 board, the CPS2 Board, The Konami boards used to run games like TMNT, Gradius 3 use it as a sound CPU, hell even the Neo Geo uses the Z80 as a Sound CPU. It's far more likely that Sega used it in the Genesis as a Sound CPU because almost every High End Arcade board at the time used it for the exact same thing. After all this was the intended purpose of the Genesis, to bring 16-bit Arcade titles to the home market. Master System Compatibility was an added benefit of the chip.
Nope, the Genesis VDP was a new design and not really closely related to any previous arcade designs or the SMS.

The way the Z80 is used in the MD is a waste for what it is, unnecessary and more expensive than better options for sound. Controlling the YM2612 is not intensive at all and software PCM playback is, but there's much cheaper (and better) alternatives than a dedicated CPU. (even without a DMA driven DAC, doing software or interrupt timed PCM on the 68k is also not a huge deal either though it does slow things down -DMA solves that and would be many times cheaper -and generally more capable- than using the Z80+DAC)

Arcade boards could afford the be extravagant in many cases where home consoles would never be so wasteful.

Again, see the previous discussions. (unless you want me to start pulling specific quotes)
And more on audio if you're interested:
http://sega-16.com/forum/showthread.php?p=276902
http://sega-16.com/forum/showpost.php?p=277537&postcount=122


Plus, given the nature of the PBC, they could have made the PBC an active adapter rather than mostly passive (embedded VDP+CPU+RAM and/or using some of the MD hardware if practical -namely RAM) and mix video through the cart port. (they'd need to add a few connections -namely analog RGB inputs)

TrekkiesUnite118
08-24-2010, 10:07 PM
Doesn't change the fact that having a z80 for sound control is waaaaay overkill. Arcades tend to be overkill and that's fine because they are completely different beasts than home system.

But looking at the cost of the z80 just for audio reasons on the MD - is a rather poor cost decision. Sound engines take up about 1-2% cpu resource per frame (1/60th). It's definitely overkill. It was there first and foremost for backwards compatibility. Not because they needed it for 'porting' sound engines from arcade games. That's ridiculous (and if that were true, Sega really had some boneheads working on system designs). As it is, the z80 is a poor work around for any sort of real sample playback. It's definitely better than nothing, but that doesn't mean it isn't wasteful cost wise, for what it serves on MD/Genesis only games.


The VDP has everything to do with color. All the color ram is inside the VDP. Removing SMS modes could have cut costs to have another 576bits (72 bytes) of color ram and have each layer selectable as to which bank of 64 colors to choose.

Well as I've said before I don't really know much about the hardware and how it works. I was under the impression that Color RAM and the VDP were separate for some reason.

As for the Z80, what probably went through the thought process of the designers was "This is what we use in our Arcade Hardware for our sound CPU, it's also what we use in our Master System hardware, if we include it in Genesis we can kill two birds with one stone by keeping it close to our arcade hardware and giving Master System compatibility."

kool kitty89
08-24-2010, 10:16 PM
Doesn't change the fact that having a z80 for sound control is waaaaay overkill. Arcades tend to be overkill and that's fine because they are completely different beasts than home system.

But looking at the cost of the z80 just for audio reasons on the MD - is a rather poor cost decision. Sound engines take up about 1-2% cpu resource per frame (1/60th). It's definitely overkill. It was there first and foremost for backwards compatibility. Not because they needed it for 'porting' sound engines from arcade games. That's ridiculous (and if that were true, Sega really had some boneheads working on system designs). As it is, the z80 is a poor work around for any sort of real sample playback. It's definitely better than nothing, but that doesn't mean it isn't wasteful cost wise, for what it serves on MD/Genesis only games.
Plus, if they HAD intended it to be regularly used for PCM and audio duties, it's even stranger that they left the YM2612 timers disconnected. (both for music timing and PCM) As it is the 68k can use hblank interupts and the Z80 can't, right? (and software PCM is something that arcade boards didn't have to deal with -other than some really old stuff -like some early 80s williams games -though a lot of old arcade board at the time used all audio driven with a CPU/MCU and DSP -like Donkey Kong)

Not to mention, for interrupt driven stuff, wouldn't using a 6502 be better? (let alone a 6800/6809/6309 or derivative MCD)


The VDP has everything to do with color. All the color ram is inside the VDP. Removing SMS modes could have cut costs to have another 576bits (72 bytes) of color ram and have each layer selectable as to which bank of 64 colors to choose.
And they 3 additional high-speed resistors for the DAC. (and additional lines of CRAM for 12-bit indexes instead of 9: though didn't you mention that they might have already used 16-bit wide CRAM?)

Chilly Willy
08-24-2010, 10:16 PM
And in the Saturn's case you could be using 44.1 kHz samples. (wouldn't that also make 1-bit CVSD more acceptable in some cases?)

Yes, the higher the frequency, the better the 1 bit CVSD sounds. That's why my example does 22kHz instead of 11 - the difference was really astounding.



I'd imagine there would be other possible lossy compression schemes that could have been attractive as well at the time. (rather than ADPCM)

Actually, there isn't. I've looked over audio compression a LOT, and there not nearly as much as you'd think.



Doing it all as streaming audio and not FM? (wouldn't that take up a ton of cart space?) Couldn't you also have the Z80 use PWM and not use the 6th FM channel? (it would seem like compressing all the sound effects would also be advantageous, unless you already did that) Plus you've got the DMA working now, so a lot less overhead for that.

You can't directly convert the music in old PC games to the YM2612. If someone wants to try making 2612 version of the W3D music, they're welcome to try. Composing FM music is not my area in any case


Well, if you ignore the filter flag per block, it's actually simpler than Dialogic's ADPCM (which is what most people/docs refer to when using the term ADPCM). There's no delta index. Just direct 4bit signed deltas with a 4bit shift value for every 16 samples (nibbles). Nothing more than direct addition. Dialogic's ADPCM is all addition too, but you have two layers of addition plus indexing. :)

I'd go so far as to say calling BRR used in SNES (and I assume the same format on the PS1) as ADPCM is pretty misleading. Sony even calls it BRR in their dosc, IIRC, and not ADPCM. But I could be wrong.

There's two forms of ADPCM - the "simple" method with the shift and delta tables derived from the old IMA ADPCM, and the more complex method Sony likes, which is actually the more traditional form of ADPCM from the original studies on audio compression. I'm sure they've given it their own name, but that's just marketing. It's just more formal ADPCM.


I can't remember with version/scheme and setting you guys used, but IIRC I think the 3:1 one (relative to 8bit source) sounded pretty good.

Yes, the 3:1 was very nice. Quite suitable for music in my estimation. 4:1 was a little noisy in places, so I wouldn't use it for more than sound effects unless you REALLY needed the extra space.

TrekkiesUnite118
08-24-2010, 10:33 PM
Nope, the Genesis VDP was a new design and not really closely related to any previous arcade designs or the SMS.

The way the Z80 is used in the MD is a waste for what it is, unnecessary and more expensive than better options for sound. Controlling the YM2612 is not intensive at all and software PCM playback is, but there's much cheaper (and better) alternatives than a dedicated CPU. (even without a DMA driven DAC, doing software or interrupt timed PCM on the 68k is also not a huge deal either though it does slow things down -DMA solves that and would be many times cheaper -and generally more capable- than using the Z80+DAC)

Arcade boards could afford the be extravagant in many cases where home consoles would never be so wasteful.

Again, see the previous discussions. (unless you want me to start pulling specific quotes)
And more on audio if you're interested:
http://sega-16.com/forum/showthread.php?p=276902
http://sega-16.com/forum/showpost.php?p=277537&postcount=122


Plus, given the nature of the PBC, they could have made the PBC an active adapter rather than mostly passive (embedded VDP+CPU+RAM and/or using some of the MD hardware if practical -namely RAM) and mix video through the cart port. (they'd need to add a few connections -namely analog RGB inputs)

I don't think I said the VDP was based on Arcade hardware, I simply said the system itself was originally designed and intended for porting System-16 games home. So that would probably explain part of the logic behind some things such as the Z80 for the sound CPU.

kool kitty89
08-24-2010, 10:33 PM
Well as I've said before I don't really know much about the hardware and how it works. I was under the impression that Color RAM and the VDP were separate for some reason.
Beyond just the CRAM (I believe it's also referred to as color registers), you've also got 3 more high-speed resistors to add to the DAC for 12-bit RGB, not to mention other potential VDP additions. (pixel accumulation would have been great)
And of course, ANY cost and R&D spent on one thing can (and likely will) be traded-off for other possible features or refinements, even if entirely separate parts of the hardware.


As for the Z80, what probably went through the thought process of the designers was "This is what we use in our Arcade Hardware for our sound CPU, it's also what we use in our Master System hardware, if we include it in Genesis we can kill two birds with one stone by keeping it close to our arcade hardware and giving Master System compatibility."
That doesn't really make much sense from an engineering perspective though: designing a home console has significantly different goals than designing an arcade board...

Doing so would be bad/flawed engineering, and I doubt that's the case.







Actually, there isn't. I've looked over audio compression a LOT, and there not nearly as much as you'd think.
SO you just had a few audio-specific lossy compression formats and a bunch of general purpose lossless schemes?
In any case, CVSD was already around long before the MD (let alone Saturn), wasn't it?


You can't directly convert the music in old PC games to the YM2612. If someone wants to try making 2612 version of the W3D music, they're welcome to try. Composing FM music is not my area in any case
And Tiido's engine isn't open source... (if it's been leaked, GEMS has midi support, though you probably don't want to go with GEMS)

Other than that, wouldn't sample synthesis be a more efficient option than streaming audio? (either sampled FM or using something based on the MAC, SNES, or Jaguar versions) With the DMA PWM, would the Z80 be enough to manage an 8-channel MOD player? (or would the bank-switching be too limiting)
You were already using the slave SH2 for audio right? (though it sounds like you want to see if you can avoid that)


There's two forms of ADPCM - the "simple" method with the shift and delta tables derived from the old IMA ADPCM, and the more complex method Sony likes, which is actually the more traditional form of ADPCM from the original studies on audio compression. I'm sure they've given it their own name, but that's just marketing. It's just more formal ADPCM.



Yes, the 3:1 was very nice. Quite suitable for music in my estimation. 4:1 was a little noisy in places, so I wouldn't use it for more than sound effects unless you REALLY needed the extra space.[/QUOTE]

TrekkiesUnite118
08-24-2010, 10:42 PM
Beyond just the CRAM (I believe it's also referred to as color registers), you've also got 3 more high-speed resistors to add to the DAC for 12-bit RGB, not to mention other potential VDP additions. (pixel accumulation would have been great)
And of course, ANY cost and R&D spent on one thing can (and likely will) be traded-off for other possible features or refinements, even if entirely separate parts of the hardware.


That doesn't really make much sense from an engineering perspective though: designing a home console has significantly different goals than designing an arcade board...

Doing so would be bad/flawed engineering, and I doubt that's the case.




Just because looking back it's flawed, doesn't mean that might not have been the thought process. While Sega made some good hardware and games, they also made, and continue to make, a lot of questionable decisions. Just look at the Saturn's Design if you need more proof that Sega's logic for doing things wasn't always the best logic to use at the time when we look back on it.

It wouldn't surprise me at all if Sega's logic for the Z80 was "Our arcade boards and other Arcade Boards use the Z80 as a Sound CPU, let's throw it in the Genesis to do the same job, Arcade Developers will love that! And it will allow for Master System compatibility, our fans will love that!"

retrospiel
08-24-2010, 10:47 PM
It's a shame SoA didn't push so hard against that for Mars/32x given what happened...

32X was SOA's idea. There's zero evidence that would suggest that SOA was against another Genesis expansion / upgrade / add-on. Quite the opposite really.

Tom Kalinske: I think, in hindsight to me, the great lesson is don't ever expect an add-on device to be as important as a true, new platform. And I think that's what we had in mind. We thought were going to sell millions of those, and that was unrealistic.



let alone wait another few months to release the Saturn properly in late 1995.

Kalinske was responsible for the early launch. There's no evidence that would suggest otherwise. Instead we got hundreds of journalists who were present at his speech at E3 where Kalinske personally announced Saturn's early launch, most likely surprised by Sony's PlayStation presentation.



Which design?

I was referring to Project Mars.



Where did you get the idea that Mars would ever have been related to the Saturn?

??? - I did not. They threw away earlier designs of what became Saturn because SOA was pretty much against releasing a MD/G successor 'too early'.

Both Saturn and Mars might have been related to these early concepts, but they were not related to each other.



but nothing that seems at all related to the 32x, cancellation of Mars, or intended backwards compatibility.

I agree. Saturn and Mars/32X were concepts that probably were conceived when earlier designs of a Mega Drive successor were scrapped due to Genesis' success and SOA's opposition.



Personally I think that Saturn's FMV capabilities (MPEG-1 decoder) might hint at Sega of America influence on how to improve FMV games based on their experiences with Sega CD.



If anything: focusing on the MD/Genesis would have been all the more reason for backwards compatibility, so I don't see your argument there at all.

It was an observation. Not an argument.

I have no idea what they were thinking when they came up with these decisions.

And I already mentioned that Saturn being compatible to Mega Drive /CD would have been the better solution if you want to keep milking your Genesis cow, and quite an obvious one.



They took it seriously in Japane. :p and not just that, but by late 1993 there was both the PSX AND Project Reality from Nintendo to worry about

That would explain why they weren't happy with 32X alone.



Huh? The 4th gen consoles were strong through 1996

In 1995 the market shrunk to less than half its size of 1994, and again in 1996. PCs started to get really popular as gaming machines.



I highly doubt the PS2 would have been crippled without PSX compatibility

Well, I disagree.



As it was, the Genesis probably would have been better off had they designed it without backwards compatibility in mind at all.

I definitely would have bought a Master System if Mega Drive wasn't compatible to it.

tomaitheous
08-24-2010, 10:52 PM
Well as I've said before I don't really know much about the hardware and how it works. I was under the impression that Color RAM and the VDP were separate for some reason.

It can be setup that way. The original Genesis VDP supports a pure digital pixel bus that can be feed directly into a palette/color managing chip. IIRC, a few of Sega arcade systems are setup like this (for multiple video chips that are overlaid on the digital pixel bus level). But afaik, only the PCE keeps the color handling separate in another chip - of that type design (comparative to that generation).



As for the Z80, what probably went through the thought process of the designers was "This is what we use in our Arcade Hardware for our sound CPU, it's also what we use in our Master System hardware, if we include it in Genesis we can kill two birds with one stone by keeping it close to our arcade hardware and giving Master System compatibility."

Oh, I agree that they were probably thinking they could solve two issues with one part. I mean, since they were already including it for SMS compatibility - they cut costs on a DAC playback system by having the z80 as a supplement. And that makes sense. But if you remove backwards compatibility from the picture (invalidating it of the worth of the system as a whole), then having the z80 over a more correct audio setup.. is well.. less effective/poor substitute. But hey, hindsight is 20/20 ;)


Yes, the 3:1 was very nice. Quite suitable for music in my estimation. 4:1 was a little noisy in places, so I wouldn't use it for more than sound effects unless you REALLY needed the extra space.

Yeah. I forgot about that thread. I need to look in to the decoding method (wanted to use that scheme for some stuff).



There's two forms of ADPCM - the "simple" method with the shift and delta tables derived from the old IMA ADPCM, and the more complex method Sony likes, which is actually the more traditional form of ADPCM from the original studies on audio compression. I'm sure they've given it their own name, but that's just marketing. It's just more formal ADPCM.

Heh - I think the Sony scheme is simpler, actually: http://pcedev.net/docs/brr/brr.txt No need for any LUTs (though you could use them if shifting is slow on the target processor). What was the max sample depth and playback on the 32x? BRR decodes really easily and the SPC is only 1mhz. You could probably do a quick(read: not cycle accurate) SPC player for it :)

Chilly Willy
08-24-2010, 10:52 PM
SO you just had a few audio-specific lossy compression formats and a bunch of general purpose lossless schemes?
In any case, CVSD was already around long before the MD (let alone Saturn), wasn't it?

Yes, pretty much ALL these compression schemes were around long before consoles or home computers. It's just been a matter of applying old ideas to ever-improving hardware. Nearly all audio compression now is done in the frequency domain since that makes it easier to do psycho-acoustic encoding, but they didn't in past not because no one thought of it, but because it was laughable to consider doing so in real-time on existing hardware. The IDEA of compressing audio in the frequency domain is pretty old.



And Tiido's engine isn't open source... (if it's been leaked, GEMS has midi support, though you probably don't want to go with GEMS)

There's another engine out from someone else (I forget who, but it can be found at SpriteMinds). But like I said, that's not something I would work on.



Other than that, wouldn't sample synthesis be a more efficient option than streaming audio? (either sampled FM or using something based on the MAC, SNES, or Jaguar versions) With the DMA PWM, would the Z80 be enough to manage an 8-channel MOD player? (or would the bank-switching be too limiting)

The bank switching is too limiting. You're hard pressed to add two waves with the Z80, much less do something like resampling for notes. A Z80 mod player with the MD setup is just not in the books. It might have been possible if they had made four banks instead of one.



You were already using the slave SH2 for audio right? (though it sounds like you want to see if you can avoid that)

I'm working on a sound engine for the 32X that uses the slave sh2 and dma audio to do sound effects and MIDI music based on samples. Depending on how it goes, that's most likely how the W3D music will be done.

I've got the engine playing the sound effects, but I need to put more work in the music part.

retrospiel
08-24-2010, 11:02 PM
I'm working on a sound engine for the 32X that uses the slave sh2 and dma audio to do sound effects and MIDI music based on samples. Depending on how it goes, that's most likely how the W3D music will be done.

Would it be possible to feed the MIDI information to a FM sound driver ?

kool kitty89
08-24-2010, 11:49 PM
Just because looking back it's flawed, doesn't mean that might not have been the thought process. While Sega made some good hardware and games, they also made, and continue to make, a lot of questionable decisions. Just look at the Saturn's Design if you need more proof that Sega's logic for doing things wasn't always the best logic to use at the time when we look back on it.
Saturn is another case entirely and we don't know exactly how it happened:
One story was that initially it was totally 2D oriented without the VDP1, geometry DSP, or SH2s, with emphasis on software rendered 3D and general 2D capabilities. (VDP2 can do plain 2D layers with its 6 planes or have them used as mode7 like layers too -obviously much higher res)
But when Sega saw what Sony was pushing in late 1993 (and perhaps Nintendo's announcement -3DO and Jaguar would have been older news) they realized their platform would have been nowhere near powerful enough to compete and tus rushed a redesign with the added SH2s and SH1 only remaining for CD-ROM management (way overkill for that duty, but it would save time in the redesign) added VDP1 (or replaced a far more primitive ASIC initially used -it's possible that they had nothing at all before and used the CPU alone), and added the DSP to the SCU intended for 3D matrix calculations. (that would also explain the VDP1 bugs and poor documentation of the DSP in the SCU)

Otherwise the Saturn is indeed an expensive mess that could have been much more efficiently designed from the ground up and probably designed rather differently from the ground up as well -supporting Triangles for 3D should have been natural by that point, though not exclusive, it was clearly what most developers would be using given what was used with software rendering from years before up to that point -even without hindsight. (none of which has any tie to backwards compatibility though)
I mean, the IronMan/PCFX design makes a fair bit of sense for 1993, but likewise they rushed it out in 1994. (except they didn't cram in additional hardware facilitating 3D)


It wouldn't surprise me at all if Sega's logic for the Z80 was "Our arcade boards and other Arcade Boards use the Z80 as a Sound CPU, let's throw it in the Genesis to do the same job, Arcade Developers will love that! And it will allow for Master System compatibility, our fans will love that!"
That makes no sense at all as Tomaitheous already elaborated on.

TrekkiesUnite118
08-25-2010, 12:03 AM
Saturn is another case entirely and we don't know exactly how it happened:
One story was that initially it was totally 2D oriented without the VDP1, geometry DSP, or SH2s, with emphasis on software rendered 3D and general 2D capabilities. (VDP2 can do plain 2D layers with its 6 planes or have them used as mode7 like layers too -obviously much higher res)
But when Sega saw what Sony was pushing in late 1993 (and perhaps Nintendo's announcement -3DO and Jaguar would have been older news) they realized their platform would have been nowhere near powerful enough to compete and tus rushed a redesign with the added SH2s and SH1 only remaining for CD-ROM management (way overkill for that duty, but it would save time in the redesign) added VDP1 (or replaced a far more primitive ASIC initially used -it's possible that they had nothing at all before and used the CPU alone), and added the DSP to the SCU intended for 3D matrix calculations. (that would also explain the VDP1 bugs and poor documentation of the DSP in the SCU)

Otherwise the Saturn is indeed an expensive mess that could have been much more efficiently designed from the ground up and probably designed rather differently from the ground up as well -supporting Triangles for 3D should have been natural by that point, though not exclusive, it was clearly what most developers would be using given what was used with software rendering from years before up to that point -even without hindsight. (none of which has any tie to backwards compatibility though)
I mean, the IronMan/PCFX design makes a fair bit of sense for 1993, but likewise they rushed it out in 1994. (except they didn't cram in additional hardware facilitating 3D)


That makes no sense at all as Tomaitheous already elaborated on.

Sega has never really been one for making sense when it comes to designing both Hardware and Software. There are plenty of examples of poorly designed hardware and software throughout their history that when we look back on it makes no sense for why one would design it that way.

A recent example of this that comes to mind is Phantasy Star Universe's Server Logic, it's so poorly designed you'd think a dumb script kiddie wrote it.

So while it may not make sense, knowing Sega it wouldn't be surprising at all if that was their thought process at the time.

As for Saturn using Squares, while in hindsight we can say Triangles would have been a better idea, at the time all of Sega's 3D Arcade Hardware (probably the best in the gaming industry at the time) were all based around Quads. You can't really say it was a bad decision to think that approach would work on a home console too.

kool kitty89
08-25-2010, 12:06 AM
Would it be possible to feed the MIDI information to a FM sound driver ?
That's what Gems did. ;) And that's also why so may developers used it. (more usable by composers who weren't programmers) This came up before, but the main problem with gems is the fixed default instrument set being rather limited.

I think Tiido's engine supports MIDI, but as mentioned, that's not open source. (and Chilly Willy's project is)

Anyway, it would be interesting to have a DMA based sampled synthesizer on the 32x regardless. ;)




Sega has never really been one for making sense when it comes to designing both Hardware and Software. There are plenty of examples of poorly designed hardware and software throughout their history that when we look back on it makes no sense for why one would design it that way.

A recent example of this that comes to mind is Phantasy Star Universe's Server Logic, it's so poorly designed you'd think a dumb script kiddie wrote it.

So while it may not make sense, knowing Sega it wouldn't be surprising at all if that was their thought process at the time.

As for Saturn using Squares, while in hindsight we can say Triangles would have been a better idea, at the time all of Sega's 3D Arcade Hardware (probably the best in the gaming industry at the time) were all based around Quads. You can't really say it was a bad decision to think that approach would work on a home console too.
So you're saying Sega engineers were incompetent? Again, I really find that hard to believe.

They may have been strange decisions on the surface, but I'll bet there's almost always a reasonable explanation. ie: for the SG-1000 Sega had not yet been bought back with CSK yet, so management was a bit iffy, plus using old off the shelf hardware was the quickest way to get their foot in the door for the home console market. Releasing new consoles and upgrades so often thereafter was natural to strengthen competition. The poor marketing of the SMS in the US was understandable as they were new in the market and understaffed (especially lacking a good SoA leader) and Nintendo conversely had an excellent push for marketing in the US (the test marketing probably helped too). The MD's design makes sense if they really felt backwards compatibility was important (though the fact that an external adapter was necessary sort of mitigates that), the missing stuff on the expansion port is pretty much all hindsight other than if they'd made note of what Hudson/NES had been doing -ironically NEC totally wasted that feature which had everything Sega ever wanted on it. (had NEC's port been like the MD's it would have been no worse for the wear, but had the MD port included the sort of features the PCE had, sega would have had a much easier time expanding the MD)
The use of VRAM and PSRAM makes sense due to time and resource constraints: facilitating a shorter design cycle and allowing other features like backwards compatibility.
The MCD makes sense due to NEC's promising market at the time and additional features that really seem to be intended to address shortcomings compared to the SNES as well as arcade. Actually, I'm a bit surprised they didn't have a CD Drive out a year earlier if not more to meet NEC's market. (without all the features of the PCE CD of course)
The 32x is a bit odd, and I'd certainly like to know more about its design, but it seems like SoJ wanted to have an interim console to fill "a gap" in the market in late 1994 (in the west) and they came up with an enhanced MD/Genesis derivative that was compatible though only modestly upgraded in some areas and intended only in the interim and totally incompatible with the Saturn: SoA engineers and staff suggested an add-on instead which resulted in it being handed off to SoA to develop. (which ended up OK until the Saturn mess in 1995 onward -and also likely ended up reducing the amount of late software on the MD and MCD)
The Saturn is as above, though a lot of that is unproven and we have little solid information to work with. (same for the Gigadrive)
SoJ turned down the SGI chipset as it was too expensive (compared to the simpler saturn in 1993) and possibly due to it being more 3D oriented and/or to far from fruition. (that's all guessing due to what happened under Nintendo's management, though Joe Miller could shed more light on that)
The Dreamcast also makes a lot of sense: though in hindsight the whole Ktana vs Black Belt thing was pretty wasteful. (had it been done in 1993 with the Saturn vs SGI it might have been more useful :lol:)

And the Sound Systems in the Saturn and DC were pretty overkill, but that's also largely in hindsight. (both probably could have done without the DSP from what I understand)

TrekkiesUnite118
08-25-2010, 12:19 AM
That's what Gems did. ;) And that's also why so may developers used it. (more usable by composers who weren't programmers) This came up before, but the main problem with gems is the fixed default instrument set being rather limited.

I think Tiido's engine supports MIDI, but as mentioned, that's not open source. (and Chilly Willy's project is)

Anyway, it would be interesting to have a DMA based sampled synthesizer on the 32x regardless. ;)




So you're saying Sega engineers were incompetent? Again, I really find that hard to believe.

I question the abilities of any developer who designs a server that will do whatever the client tells it to do. To further elaborate on what I mentioned with PSU as an example, that server was very poorly designed. All you had to do to "hack" the game was go to an NPC shop and say "I am selling X amount of item Y" and the server would come back with "Ok!" and do it. It didn't check to see if you had X amount of item Y, it wouldn't check to see if it was possible to have X amount of item Y, and it wouldn't check to see if you even had Item Y to begin with. This left the game open to attack. The game would have been much more secure with some better server design. And that design was made not by a kid, but by Sega themselves. We see more instances of poor design when we look back through Sega's history, so it wouldn't surprise me at all if Sega's logic in their design wasn't entirely sound.

I'm not saying they are incompetent, but there are some decisions they have made over the years that have been very questionable. If Sega had Arcade people designing the Genesis who wouldn't be thinking of what's good in Console Design, they would instead be thinking about how do you design powerful but cheap arcade hardware, as opposed to how do you design efficient Console hardware.

Chilly Willy
08-25-2010, 01:38 AM
The trouble with using MIDI on the the MD isn't the instruments - you can always use your own instruments. There's nothing that says that when a MIDI file specifies a trombone, you can't just play a funky synth instrument. The trouble is that MIDI generally uses too many channels for the MD. You have 6 decent FM channels (5 if you use the DAC for PCM drums), and 3 crappy PSG channels. A lot of MIDI music uses many more channels than that - a look over the Doom MIDI music shows as many as 13 channels... and that doesn't include polyphony (playing multiple notes on the same channels). GM1 specifies up to 16 notes at once, and up to 8 percussion sounds at once.

So you have to write the MIDI music with the limits of the MD in mind. Which is again more than I want to do on the sound side of things. My sound engine for the 32X is playing 32 waves: 16 notes, 8 percussion, and 8 sound effects. I've got the wave playing worked out, so now I'm working on the music decoding and control.

kool kitty89
08-25-2010, 09:10 PM
The trouble with using MIDI on the the MD isn't the instruments - you can always use your own instruments. There's nothing that says that when a MIDI file specifies a trombone, you can't just play a funky synth instrument. The trouble is that MIDI generally uses too many channels for the MD. You have 6 decent FM channels (5 if you use the DAC for PCM drums), and 3 crappy PSG channels. A lot of MIDI music uses many more channels than that - a look over the Doom MIDI music shows as many as 13 channels... and that doesn't include polyphony (playing multiple notes on the same channels). GM1 specifies up to 16 notes at once, and up to 8 percussion sounds at once.
Tiido gave me the impression that it was the default FM instrument set available in Gems that really limited it. (hence what Shiny managed to do with Earthworm Jim and Earthworm Jim 2 with a custom reprogrammed instrument set used -though that was beyond developers who focused soley on midi and closer to those using more low-level sound engines like SMPS)

You could easily have a much larger instrument set than the 6 voices available, but you'd only be able to play 6 simultaneously. (5 if you had PCM too) I'm not sure how broad the default instruments available in Gems is though.
As it is, Wolf3D on the PC would have to limit the music engine to 9 voices or less (fewer if some were dedicated to sfx rather than dropping out an instrument for FM sfx and fewer still if any instruments used paired channels with additive synthesis -probably not the latter though). PCM would be separate via the Soundblaster's DAC or a bare parallel port DAC. (Wolf3D supported covox/sound source DAC sound)







I question the abilities of any developer who designs a server that will do whatever the client tells it to do. To further elaborate on what I mentioned with PSU as an example, that server was very poorly designed. All you had to do to "hack" the game was go to an NPC shop and say "I am selling X amount of item Y" and the server would come back with "Ok!" and do it. It didn't check to see if you had X amount of item Y, it wouldn't check to see if it was possible to have X amount of item Y, and it wouldn't check to see if you even had Item Y to begin with. This left the game open to attack. The game would have been much more secure with some better server design. And that design was made not by a kid, but by Sega themselves. We see more instances of poor design when we look back through Sega's history, so it wouldn't surprise me at all if Sega's logic in their design wasn't entirely sound.
But that's without the context of how design was delegated and such: just because it was "Sega" doesn't mean it has handled in-house. ;)
Granted, it was thier responsibility to delegate such outsourcing too, but I don't think Seganet server/client design is necessarily a good example. (and if you went there, there's a lot more examples of odd management in terms of Saturn SegaNet -including non-technical stuff like the market model used often not charging enough money and giving too many freebies)

Still, most stuff is not without reason, and not really grounds to out and out say such things across the board. (especially in the context of hardware design -which would not really parallel something like management of a server, or even game design for that matter, but depend both on the hardware engineers and management of such)
It's not like Nintendo or others didn't make equally strange or poor decisions in many cases. (some that are more obvious in hindsight and others that seem like they should have been obvious when they were made too -but there's almost always circumstances to explain such choices even if they aren't yet known)


I'm not saying they are incompetent, but there are some decisions they have made over the years that have been very questionable. If Sega had Arcade people designing the Genesis who wouldn't be thinking of what's good in Console Design, they would instead be thinking about how do you design powerful but cheap arcade hardware, as opposed to how do you design efficient Console hardware.
But the Genesis doesn't seem at all like "how do you design powerful cheap arcade hardware" it seems more like the same context used on previous console designs following the SG-1000: with how to design an efficient, competitive home game console with backwards compatibility. (undoubtedly use for home arcade ports was a major consideration and possible re-use in arcade boards, but not sheer emphasis on arcade design trends to any extent) Hell, they ended up re-using the SG-1000 in the arcade, and that definitely wasn't designed with the arcade in mind at all. (it was all, old, off the shelf hardware that had been used in several previous consoles and home computers)
I mean, if they were going like they did in the arcade, the SMS should have had 2 Z80s, or a much faster Z80. (not to mention added sound hardware -though doubled PSG wouldn't have been a bad idea)

The System-16 is an example of a low-cost optimized arcade board. ;) (and they probably could have consolidated and cut that down into a home console too, but probably not nearly as cost effectively as what the Genesis was -depending just how much they cut out)

Likewise, the Z80 doesn't make much sense in direct parallel to the Arcade: in particular, if it really was intended as a sound CPU (highly unlikely), then it would have also been like saying: OK we'll use that to control the YM2612 like we do our FM chips in the arcade, but PCM/voice/sfx samples aren't important so we'll leave that out. (such arcade boards having dedicated PCM chips/hardware)
And THAT really doesn't make sense. (especially since the Z80 wasn't used for manage PCM playback as such in the arcade as there was more hardware assistance there, the sound CPUs were rarely maxed out or even pushed very hard at all AFIK -maybe some exceptions doing more than normal sound duties, but that's the exception and NOT using it just for audio)

Had they really wanted to make use of the Z80 (both for the YM2612 FM and PCM) there's several things they should have had the foresight to easily realize in 1987/88: firstly, the YM2612's timers should have been connected (both for FM beat timing and for PCM). Then there's the very cumbersome bank switching used for the Z80 that really hinders PCM playback (especially anything much more than 1 channel): it should have been 8 banks of 8kB instead of 1 32 kB bank (and/or use parallel instead of serial bank switching); for managing the YM2612 for FM that's a non-issue as the 8 kB work RAM is fine, but for anything PCM related that's not going to really work -save for a few cases of very few/small samples being crammed into Z80 RAM.
Then they should have had a higher speed for the Z80 (at least a 6 MHz Z80, if not 8 MHz rated one -as it was many MDs had 6 MHz rated chips) so 5.97 MHz or 7.67 MHz.
And on top of all that, it would still have been very useful to have a DMA driven DAC, or even a small custom custom to provide DMA loading for the YM2612's DAC. (though that might not save much cost or board space over an integrated DAC in the chip) Even without that last bit, the other features would have greatly facilitated utility of the Z80 at minimal cost increase (especially in the long run).

If, on the other hand, they really only wanted master system compatibility with the necessary components tacked-on as cheaply as possible, the most efficient long-term solution would have been to lock the Z80 out when in MD mode, thus preventing any games from using it and allowing later revisions of the MD to remove compatibility and reduce cost. (both the VDP block and the Z80 and RAM being removed to save cost -PSG would probably be minimal to leave in though) That's what Nintendo did with the GBA: locked out the GB/GBC CPU, hence the reduced cost inmplementation in the Micro and DS removed GB/GBC compatibility entirely. (no GB/GBC CPU/RAM or video modes, just the audio hardware)
Doing that would also have facilitated backwards compatibility in the next generation too.


Without the Z80, at very least the YM2612's timers should have been tied to the 68000, as it was they (rather oddly) left them unconnected, though at least the Z80 had the 15.7 kHz Hblank interrupt to work with.



Now, had Sega really wanted to design an evolutionary system that was compatible with and efficiently grew off the SMS hardware, they'd have taken a different route. (ie build the VDP around the SMS VDP architecture, but expanded -say double or tripple it and combine the video layers as well as expanding the master palette and increasing the flexibility and possibly number of the subpelettes and probably beefing up sprites and expanding VRAM: probably not keeping the Z80 as the main CPU though maybe a fast HD64180 or Z180 derivative -sort of like the 65C02 derivative Hudson used, or maybe even a Z800 derivative -though using a 68k+Z80 coprocessor could still make sense too -one big consideration is marketing as a "real 16-bit system" though a Z800 derivative would cover that too then either go with the PSG+YM2413 or expand upon that -like a full OPL2 in place of the 2413, etc, etc)

Sega did that to some extent with their 1985 System E arcade board with 8 MHz Z80, 16 kB work RAM, dual SMS VDPs with 2x 16 kB RAM banks each (64 kB total), and dual PSG. (so a bit more primitive than what you'd want for a real SMS successor) Something like that might have been a good route for a Successor to the GameGear too.

TrekkiesUnite118
08-25-2010, 09:30 PM
But that's without the context of how design was delegated and such: just because it was "Sega" doesn't mean it has handled in-house. ;)
Granted, it was thier responsibility to delegate such outsourcing too, but I don't think Seganet server/client design is necessarily a good example. (and if you went there, there's a lot more examples of odd management in terms of Saturn SegaNet -including non-technical stuff like the market model used often not charging enough money and giving too many freebies)

Still, most stuff is not without reason, and not really grounds to out and out say such things across the board. (especially in the context of hardware design -which would not really parallel something like management of a server, or even game design for that matter, but depend both on the hardware engineers and management of such)




Phantasy Star Universe and it's servers were handled entirely in house by Sega. It's not an external company running them or maintaining them, it's Sega themselves. The issue here is how poor the games Server side logic was designed. As I said earlier they designed the server to do whatever the client tells it to, regardless of how ridiculous it is. And Sega then said it was unhackable because they used SSL between communications. It just goes to show that even the best security encryption won't save you from poor design.

Again, I'm not saying they were entirely incompetent, but they have been known to make some bad decisions. It's entirely possible that Sega's hardware designers thought they were making a good decision with the Z80 used how it was even if in retrospect it was a waste of resources. And again, I'm not saying it was entirely because of how they used the Z80 in the Arcades and not for Master System Compatibility, I'm saying it was probably decided due to reasons from both sides. It killed two birds with one stone. It made the sound system similar to their Arcade boards in a sense as Z80 assembly code for the Arcade would in theory run on the Z80 in the Genesis with little effort, and it would also provide Master System compatibility.

kool kitty89
08-26-2010, 06:05 AM
Again, I'm not saying they were entirely incompetent, but they have been known to make some bad decisions. It's entirely possible that Sega's hardware designers thought they were making a good decision with the Z80 used how it was even if in retrospect it was a waste of resources. And again, I'm not saying it was entirely because of how they used the Z80 in the Arcades and not for Master System Compatibility, I'm saying it was probably decided due to reasons from both sides. It killed two birds with one stone. It made the sound system similar to their Arcade boards in a sense as Z80 assembly code for the Arcade would in theory run on the Z80 in the Genesis with little effort, and it would also provide Master System compatibility.
I really doubt it had much to do with the Arcades: I used to think that, but finding out more details and some actual technical understanding and insight made it seem far less likely.

And, again, the way arcade boards use the Z80 is not nearly as intensive as what the MD does: if the MD used it solely int he manner arcade boards routinely do, you'd have no voice samples or digitized sound effects in any games. :p (and also note that Z80 sound CPUs weren't always used and using a dedicated Z80 for sound was also done on several of Sega's older Z80 based arcade boards -so a Z80 as the main CPU and another for the sound CPU)

I wouldn't be too surprised if, at some point, Sega had planned to make the MD directly cart compatible with the SMS, but later dropped the idea. (they did that for the SG-1000 to mk.III/SMS in Japan) The only issue there would have been providing additional pins needed for the added connections and address space on the genesis. (they could have added outboard pins for that, like the SNES and Atari 7800 did and they could have remapped some of the SMS pins in MD mode as well, to minimized the additional pins required)
One side effect would have been that JP and EU/US carts would have been pin-incompatible due to different connectors used on the western SMS. (which wouldn't have been bad from Sega's standpoint -they'd been implementing lockout for Japanese vs US carts on the MD as it was, just like Nintendo's hardware slot lockout -I wonder if region locking has anything to do with the change in the connector for the western SMS) Doing the outboard pin route would mean larger cart PCBs though and larger pins than the MD used. (SMS and Sg-1000 used larger pins spaced further apart)


And again, I don't think their "strange" or "bad" decisions aren't really any stranger than a number of other companies (Nintendo, NEC, Atari Inc, Atari Corp, Commodore, Sony, Digital Research, etc), and there's almost always an explanation even if that answer hasn't been fully unearthed yet. (many of the SNES's design features are actually a bit more puzzling than the N64 in terms of reasoning -the reasons for the N64's flaws seem more straightforward for sure)


As it was, the Z80 (and compatibility) could have been a really good idea, but the final implementation was rather poor: if they'd only wanted it for compatibility, they probably should have locked it out to potentially be removed on later models (once the feature was less useful) to save cost and possibly simplify future compatibility. (maybe even to give the Z80 its own RAM, but map part of the 68k's work RAM to the Z80 in SMS mode)

OTOH, had they really wanted to make it a useful coprocessor as well as facilitate backwards compatibility, it should have been incorporated significantly differently. (again: better bank switching for ROM access in 68k mapped memory, higher clock speed for MD mode -5.96 MHz should have been reasonable, and connect the YM2612's IRQ line to the Z80 to use the programmable timers)
That would not only have made the Z80 more useful for audio, but as a general purpose coprocessor in the system. (which is what it was)

Separate from that, had they really wanted to facilitate PCM playback, DMA PCM support would have been good, though that could also have been left for on-cart add-ons. (and with the Z80 far less limited, you could do a lot more there too -hell, it would be more useful for driving 32x audio ;))


And again, if they'd really wanted to go all-out and build directly on the SMS architecture to create a similarly competitive system (but more efficiently addressing compatibility), they probably could have done that too, but the MD design seemed to take the more tacked-on route with compatibility.

As it is, it seems a bit more of a waste with the rather bulky Power Base converter necessary rather than direct cartridge compatibility. As such, they could have made the PCB an entirely external unit containing the SMS hardware. (they'd have to make sure enough power could be supplied as such and video input lines would be needed on the cart slot -perhaps the PBC could have triggered a jumper that disconnected the power from most of the MD hardware other than the necessary video encoder and analog audio amp/mixing circuitry)


If they really thought they needed more resource than the 68k could provide, opting for a faster 68k might have made more sense in that respect. (10 MHz rated would be the next step up from 8 MHz that was used) There would have been some cost increase due to that (and correspondingly faster RAM), but dropping the Z80+RAM would already address that to a fair extent (cost in board space/complexity in addition to materials) and much more so later on.


A lot of the other hypothetical changes would not so much be related to the addition of SMS compatibility, but some stuff that would definitely have been nice in hindsight (much that would have been realized already by the time the MCD was being designed). At the time, I'd think Hudson's design with the PCE would have spurred some additions for expansion (then again, detailed pinout information for the expansion bus wouldn't have been public knowledge at the time ;)).
Some things might not have been directly related, but might have been facilitated by the cost reduction from removing compatibility as well as the added R&D resources put to use for things other than compatibility.
In the case of the VDP, that's really obviously tied directly more than anything else.
Something like using DRAM for main memory would not have been particularly related (the use of PSRAM instead for 68k RAM definitely seems very bad in hindsight, let alone the possibility of use instead of VRAM -some cost pluses and minuses in the short term, but pretty much only positives in the long run -and making the system more powerful on top of that). The same could be said for the use of SRAM for the SNES's video RAM or audio, let alone the oddly slow DRAM used for the CPU work RAM. (or the CPU clock speed for that matter)

And the use of on-cart hardware wouldn't have been hindered by the decision to have onboard compatibility either. (the lack of such really is a bit odd, especially audio expansion)

TrekkiesUnite118
08-26-2010, 02:13 PM
Again, I'm not saying it wasn't entirely because of the Arcade Hardware, I am simply saying that Arcade Hardware probably went into some of the decision making for using it the way they did. If they wanted it entirely for backwards compatibility as stated earlier it would have made more sense to just have it off on it's own completely separate from everything else. The reason it is used as a Sound CPU in MD mode is probably to keep it similar to System-16 Technology and possibly because Sega thought it would be better to have the 68000 free to do more important things without worrying about sound. Sega most likely used it the way they did for both Master System Compatibility and Arcade Similarity. It killed two birds with one stone.

retrospiel
08-26-2010, 05:44 PM
Saturn was released as a high end console with quite impressive 2D and 3D capabilities - and as a comparably low cost arcade hardware (http://system16.com/hardware.php?id=711), not unlike Neo Geo and Dreamcast.

EDIT: Okay, you guys are talking about Mega Drive.

kool kitty89
08-26-2010, 09:45 PM
Again, I'm not saying it wasn't entirely because of the Arcade Hardware, I am simply saying that Arcade Hardware probably went into some of the decision making for using it the way they did. If they wanted it entirely for backwards compatibility as stated earlier it would have made more sense to just have it off on it's own completely separate from everything else. The reason it is used as a Sound CPU in MD mode is probably to keep it similar to System-16 Technology and possibly because Sega thought it would be better to have the 68000 free to do more important things without worrying about sound. Sega most likely used it the way they did for both Master System Compatibility and Arcade Similarity. It killed two birds with one stone.
The MD is not much like System 16 tech at all though... and the graphics architecture is a huge deal, even if the CPU is the same, that doesn't necessarily do much other than facilitate porting the source code over. The graphics would have to be completely re-done, both in terms of the actual graphics used (that would also be limited by ROM space) and due to the different way the sprites/tiles work on the MD VDP. (at least that's what I remember from the last discussion on this)

So the arcade angle really doesn't make sense: it's got very broad and vague similarities to the arcade, just like the SMS did to some extent: and, of course, had the hardware re-applied as actual arcade hardware as Sega did with all its consoles. (in the System C -directly based on the MS, Sega removed the Z80 entirely and used 10 MHz rated 68k running at 8.95 MHz)

The Z80 in the MD isn't a sound CPU... it was a general purpose co-processor not dedicated to any specific task: it was often used as such though (many sound engines ran on the 68k too, even Sega's SMPS 68k), but managing the YM2612 isn't a big deal at all for the 68k alone, so the added utility of the Z80 is virtually nill for that. For PCM it was used as a workaround by programmers due to the resource intensivity of that and complete lack of hardware PCM assistance in the MD...
The way the MD is set up really doesn't seem like it was intended for the Z80 to do much at all, and may not have even been intended to do more than provide compatibility (early hardware docs in dev kits might even provide evidence of that).
Sound engines had to be re-written for the MD regardless, so it's not like the Z80 facilitated that in most cases either. (different sound hardware, different configuration, and writing a sound engine for the 68k should have been a non-issue)

As it is, it's rather tacked on, and it seems like Sega wasn't really thinking ahead with PCM playback whatsoever, which even more strongly supports the Z80 not being intended for such.
As it is, they didn't bother connecting the YM2612's interval timers to the Z80 or 68k... (though the 68k has the useful Hblank interrupt too) which would have been important for FM timing as well as PCM. But the limited bank switching of the Z80 heavily limited its utility for PCM playback (let alone any additional effects -like pitch control).

The only thing intensive done by the Z80 is software PCM playback, which would NOT have been part of the duties of such arcade boards, and as it is, isn't very well suited for such in the manner Sega implemented it... but in that respect, there's cheaper and much better options for getting good PCM playback than using a dedicated CPU. (namely DMA)

And again, if they DID want to really make the Z80 useful, there's the various other changes that would have been made.


Again, given the integrated compatibility, I think that at some point, Sega might have been considering making the MD cart compatible with the SMS, otherwise, with a bulky adapter, the utility is sort of missed. (granted the PBC would have been more expensive and that gimmicky Phantasy Star port in Japan wouldn't have been possible -though it was worse than the SMS/Mk.III version due to lack of FM)





Saturn was released as a high end console with quite impressive 2D and 3D capabilities - and as a comparably low cost arcade hardware (http://system16.com/hardware.php?id=711), not unlike Neo Geo and Dreamcast.
Dreamcast, yes, but not anything like Neo Geo. :p Neo Geo was an arcade system plain and simple with an expansive niche rental/home console adaptation made with direct conversions of games.
Now one could argue that the Neo Geo Hardware (or other low-end/mid-range boards like the System-16) could indeed have made a reasonable home game console by simply integrating the hardware in a more cost-efficitive console form factor, but in such a case, you wouldn't be doing those totally unreasonable full MVS games, but carts more like the MD used: slower ROM, single bus, much, much less animation, many fewer and lower quality sound samples (though still hardware ADPCM decompression), etc. (probably remove the Z80 -especially since it would no longer have it's own ROM bus) Some other modifications to the base hardware might have been necessary to really work decently well on a single bus. (ie double buffering for video RAM to avoid DMA contention for VDP and CPU, maybe more main RAM as well -or it could have had a lot more RAM onboard for graphics and audio and stored everything highly compressed in ROM -still would have to be cut-back from the arcade though, maybe not quite neo Geo CD RAM capacity, but maybe not far off -probably leave the Z80 in that case too)

Still would have been a higher-end system with higher price and more expensive games (probably a good bt larger on average), but nothing like the real Neo Geo, which wasn't even part of the mainstream console market with games costing several hundred dollars each.

The Neo Geo CD was a reasonable console though, albeit still high-end. (just too late) Had they pushed it as CD from the start with supplemental RAM, it might have been more practical. (cost of the CD drive in '90 would have been a much bigger factor than '94 though, RAM not nearly as much an issue though -again, compressed single-bus carts might have been a decent option, though they'd still be large if it was just compressed and not actually cut-down in graphics and sound -and sound samples already were ADPCM) As it was, in 1990, the Neo Geo CD (even fully featured as it was in 1994) likely would have been more realistic than the Neo Geo. (probably well over $600 -but could reasonably have had several games bundled with it too -and additional games would be 1/5-1/10 the cost of AES carts) Cutting down the RAM compared to the 1994 CD (and probably including provisions for expansion) would have been more realistic still. (probably still over $500 in 1990 -given the cost of games it would have been night and day though)



OTOH Saturn was a high-end home console like the Mk.III in 1985, MD in 1988, MCS in 1991, etc, and like all of Sega's home consoles (aside from add-ons), it was reworked into an actual arcade board. (even the obsolete SG-1000 had that done to it, though minimally compared to what happened with the Mk.III, MD, Saturn, and DC)
In all cases being applied as low-end or mid-range (and especially low-cost -even if high performance) arcade systems for their times. And in the case of the SMS, MD, and DC, also had enhancement/modifications done for some of the arcade conversions. (and even for almost identical hardware, you had things like much more and faster ROM being usable)

Hell, the Famicom in 1983 was quite advanced for the time too, probably more so than several Sega systems. (and compared to contemporary arcade stuff especially, and in the context of Sega's arcade board conversions, the Famicom could have been more advanced than a lot of the mainstream arcade hardware in 1983/84)


The Playstation was equally high-end in terms of hardware and multimedia capabilities and was also used in the Arcade (I think the 3DO was too, hell the Jaguar hardware was re-worked for the arcade ;)).
It was pretty impressive in 2D too, and while it couldn't compete with some of the VDP2 effects done (both cases of using 4 or 5 BG planes or mode 7 like effects), but could push "sprites" similarly as well as use similar texture effects. (again, cases of having to use textured tiles to do what VDP2 can is where it falls behind)
In terms of some 3D and pseudo 3D there's software rendered effects more possible with the added CPU resource and the sound system has the powerful synthesis capabilities and DSP (and there's the 68k coprocessor).

But one key area at home for the PSX vs Saturn in 2D was pure animation due to the Saturn's added RAM (mainly the RAM expansion or ROM carts). In the arcade: with large, fast ROMs, that would have been a non-issue. (they could have afforded to bump up RAM easily as well for an arcade system) Resolution was rather variable on both. (Saturn used the high-res modes a lot more often though)

And in pure 3D (and some texture effects and software rendering) the model 2 would be ahead of the ST-V in many areas. (it did lack hardware gouraud shading)


And that's not even considering the potential of the N64 chipset. (especially in an arcade environment)

retrospiel
08-26-2010, 10:01 PM
The Mark III required an FM add-on for the FM so releasing Phantasy Star 1 without FM sound is still a nice gesture. Although it would have been entirely possible to include the FM expansion on the cartridge.
Still, better than nothing. Would have been nice if they'd have released it in the West.

Btw, from what I know the Z80 does control the controller port as well, and the Sega's famous SMPS sound driver also had a Z80 variant that probably helped to free some valuable CPU resources (see Sonic 2, 3, K (http://gdri.smspower.org/wiki/index.php/Mega_Drive/Genesis_Sound_Engine_List)).

I don't think it's unlikely that it was included mainly for compatibility reasons, but so what? The fact they made it accessible at all in MD mode, like the PSG and unlike the SMS VDP, is good enough for me.

Remember that all previous Sega hardware was fully bw compatible, and it certainly helped us kids to side with Sega as we knew that if we could afford a Master System we would be able to keep and play our SMS games on our Mega Drives too as soon as we could afford one.

kool kitty89
08-27-2010, 08:56 PM
The Mark III required an FM add-on for the FM so releasing Phantasy Star 1 without FM sound is still a nice gesture. Although it would have been entirely possible to include the FM expansion on the cartridge.
Still, better than nothing. Would have been nice if they'd have released it in the West.
JP SMS had FM built-in (1987), mk.III was add-on like with the MSX's FM.
It would also have been nice if they'd included audio expansion in the western SMS (on cart or via the expansion port)... or at least not removing the FM support from some US games. (including Phantasy Star, so even if you play it with an adapter on a JP SMS/Mk.III with FM or use a homebrew YM2413 add-on, you only get PSG -supposedly doen to make room for english text -though in the case of one or 2 other games, both JP and English text were included and FM works in JP mode, but is disabled in english mode -I seem to recall some games doing that in fusion at least, unless those weren't normal ROM dumps)

In the case of PS1 on the MD, adding it on cart would have required reprogramming I think.



Btw, from what I know the Z80 does control the controller port as well, and the Sega's famous SMPS sound driver also had a Z80 variant that probably helped to free some valuable CPU resources (see Sonic 2, 3, K (http://gdri.smspower.org/wiki/index.php/Mega_Drive/Genesis_Sound_Engine_List)).
You mean it can be used to read controller inputs? I don't think the Z80 is dedicated to that, and I'm almost positive the 68000 can read controller inputs directly (the actual I/O circuitry is on an ASIC on early model 1s -later integrated with the VDP, so nothing like the Ricoh ASICs used by Nintendo where the I/O hardware was actually on-chip with the CPU).

As it is, the Z80 is totally general purpose, you could have the entire game running of the Z80 alone... but it's also unnecessarily hindered by the limited clock speed and crappy bank-switching scheme.

The point is that the MD could have been more powerful AND less expensive if SMS compatibility had been omitted or made fully external. (additional cost related stuff that could/should have been done too, but not so related to SMS compatibility other than sheer time/resources put into R&D)
And also, that with the Z80 onboard, had they really intended it to be of much utility beyond compatibility and really get some milage and good value out of it they would have used a better bank-switching mechanism (smaller banks and/or parallel rather than serial), bumped up the clock speed for MD mode, etc. A 6 or maybe even 8 MHz rated Z80 should have been very reasonable (many MDs already use 6 MHz rated chips), and based on the MD master clock that would be 5.97 MHz or 7.67 MHz (NTSC), but even if only a 4 MHz chip was used, you could at least bump it up to 3.84 or 4.13 MHz. (short of actual overclocking -though most CPUs would be capable of well over their rated speed, the exceptions that did crash might be too numerous to be worth it -and complicate quality control: they could re-grade the CPUs before use, but that would be a lot of overhead -and probably not worth it compared to just buying a higher speed grade)



I don't think it's unlikely that it was included mainly for compatibility reasons, but so what? The fact they made it accessible at all in MD mode, like the PSG and unlike the SMS VDP, is good enough for me.
Yeah, but no PSG+SMS VDP+Z80 could, instead mean (at similar or significantly lower cost) more FM channels, good PCM playback support (simplest being a DMA driven DAC on a small custom IC), more colors and/or palettes (ie 8 palettes indexed from 12-bit RGB rather than 4 from 9-bit), and maybe even a faster 68000 and/or more main RAM. (again, other changes like implementing cheap DRAM would have been extremely significant, but not necessarily directly related to SMS compatibility being there or not -including using DRAM for Z80 RAM -SMS's or SG-1000's Z80 ram would also have been significant for that matter -I think video RAM was already plain DRAM in the SMS)
Additional expandability would again have been not directly related. (but extremely useful in hindsight... except the cart port already is great for expansion -to the extent of making the expansion port largely unnecessary unless 2 add-ons were used simultaneously, video mixing would have had to be via analog as with the 32x vs the potential for digital video mixing as on the PCE, but do remember that later daisy-chained PC graphics cards like the voodoo used a pretty much identical hack with analog RGB -VGA)




Remember that all previous Sega hardware was fully bw compatible, and it certainly helped us kids to side with Sega as we knew that if we could afford a Master System we would be able to keep and play our SMS games on our Mega Drives too as soon as we could afford one.
Yeah, except the SG-1000 was a non-issue in the west, and power base converter was hardly an issue in the US either. (and given it was an external adapter, making it a fully active adapter with Z80+SMS VDP+RAM onboard could have been very possible, just piggybacking off the MD's video encoder, audio amp, and power)
Also, the compatiblity with the SG-1000 is a good bit more efficient: if anything, the only waste is some VDP space (not sure how similar the TMS9918 is to the SMS though -YCbCr palette entires seem to be remapped to 6-bit RGB native to the SMS, so that would be a non-issue), but the same sort of trade-offs would be made with the V9938 and V9958 of the MSX2/2+.
Otherwise it was probably cheaper in some respects in 1985/86 than the SG-1000 had been 2 years earlier (PSG integrated with VDP, same amount of Video RAM, same CPU speed, same cart slot, only a modest jump to 8 kB of main RAM, etc)
In fact, it seems more efficient than the 2600 to 7800 transition and rather like GB-GBC. (again the SMS could have been expanded like that too, but it would have been a very different path than the existing MD -not necessarily less capable, but different)
The fact the Mk.III didn't upgrade sound out of the box (not even a double PSG like some arcade boards) was a bit unfortunate though -the lack of provisions for upgrade in the western SMS was a bigger issue. (like the similar lack on the NES preventing all those neat audio expansions)

From an end-user perspective, the MD having integrated compatibility wouldn't have mattered at all, the existence of the PBC was the only factor.


Again, it makes me think that Sega at one point was planning on making the consoles directly cart compatible, but later ended up dropping the idea to save cost with a cheaper connector.
If they efficiently managed to remap pins as needed for MD mode, the western SMS slot would only have needed to add 14 outboard pins to the cart slot and the JP slot would need 20 added pins, but more depending how many could be efficiently re-mapped in MD mode, but doing custom connectors like that with the outboard pins and the older wider/coarser pins would have made cart PCBs larger and more expensive than a clean, new connector -more so than the with the 7800's rather sleek 8 outboard pins, and unlike the SNES, the outboard pins would likely be needed for every game. (actually, if you cut out all the expansion related signals on the MD, you might make do with 50 or even 44 pins and leave the outboard ones for expanded carts only... -ie the last 2 address lined, audio inputs, added video,clock,sync,read/write,etc and maybe even cut-down some of the redundant gnd and Vcc lines) If they added a few extra pins tot he expansion portion, that could be even better. (cutting out the side expansion port and aiming at using the cart port alone for such expansion would also be significant)

However, that would also mean JP and US/EU carts would be pin incompatible, so those importing software would need and adapter or imported hardware rather than the simple hack needed for the MD/Genesis's cart slot (same for SNES and N64 for US/JP).
Given Sega obviously wanted to region lock the games from the start, it would have been win-win for them. ;) (they did it for the SMS including card port getting remapped and the incompatible cart slot on the MD/Genesis like Nintendo did with NES and SNES games -sans the lockout chip- and NEC did with the PCE)

Barone
03-23-2013, 02:25 PM
I do know though that most stuff on Saturn and PS1 usually sounded better on Saturn, games like Lunar, Grandia, and Megaman 8 come to mind. Saturn can do 32 PCM channels, PS1 can do 24. So Saturn stuff sometimes has more going on I guess. Also I think Saturn's sound chip can also go into FM Synthesis mode which I think is used for some of Capcom's CPS1 ports.

It seems to be a common thing between multiplatform games on the Saturn and PlayStation (some Capcom games are an exception or sometimes sound better on the Saturn, with the most notable example being MegaMan X4, which is the only version to have properly looping music). The Saturn version always appears to have inferior audio quality, and Salamander Deluxe Pack Plus has some spots where the audio quality is particularly bad, worse than other multiplatform games released on the PlayStation and Saturn. Not to mention, the Saturn versions of Konami's Deluxe Packs have some sounds sampled at the wrong speed and pitch, and some sounds are actually missing parts of the sample and replace those parts with a small segment that's looped over and over again to fill in the void.

Now, I believe the lack of a full screen option in the PlayStation version of Salamander Deluxe Pack Plus, at least with Salamander and Life Force, is due to the Saturn not being able to run at 256x224, which is the native resolution of those two games. The minimum the Saturn can do is 320x224, so what you see as a full screen option is really a horizontal stretch to fill in the 64 missing pixels.

As for Salamander Portable, I don't even want to touch that thing as its emulation of the YM2151 in Salamander and Life Force is terrible. I'd rather use my custom EBOOT of Salamander Deluxe Pack Plus I loaded onto my 2GB Memory Stick to play Salamander, Life Force and Salamander 2 on the go.
Necrobump!

I'm pretty much with Ace here. There are many more examples favorable to the PS1 side of things AFAIK.
Street Fighter Zero 3 sounds much better on the PS1, night and day difference, both in music and sfx quality.
MKII buggy port on the Saturn is another example of inferior sounding version on the system, with several sfx missing and all.
Then, there's the Konami's collections... So, what's the deal with the Saturn versions sounding inferior? Is it less capable of streaming audio at good sampling rates or something like that?

TmEE
03-23-2013, 02:30 PM
The devs did not bother to implement sample compression to fit more samples or use synthesis features of the SCSP...

sheath
03-23-2013, 02:49 PM
I am disappointed once again by online documentation on this topic. What I was able to gather of the Saturn's potential sound capabilities years ago is probably overly simplified, as the tech types love to point out, but it also jives with the box specs:



SCU (DMA and Control Processor)
Motorola 68EC000:
32 PCM Channels
8 FM Channels
Audio RAM: 512KB


By comparison here is what system16.com lists for the Model 3 step 1:



Sound CPU : 16bits 68EC000 11.3Mhz
Sound chip : Yamaha SCSP/YMF-292F/"LAKE" FH1 128-step DSP x 2, MIDI interface, 16 bits 64 voices 4 channel, maximum of 16.5 Mbytes ROM, 64 PCM channels
Audio RAM : 1meg (8 megabits, 512K per SCSP chip)

Since TmEE brought it up, is it correct that the Saturn has both the 68k derivative and a Yamaha "custom saturn chip" for FM? The Yaubause wiki (http://wiki.yabause.org/index.php5?title=Main_Page) indicates that is so, but I've seen FAQs wrong less often than wiki. It seems like that chip alone should have dominated the generation for sound quality, so we have yet another Saturn "mess" confusing under resourced developers of the time?

-edit-

I love this forum software and my complete inability to find previous posts and threads on the topic. There is a full Saturn chip diagram complete with bus width in a handy diagram somewhere around here.

-edit-edit-

I should remember that I sometimes actually bookmark stuff.
http://koti.kapsi.fi/~antime/sega/files/ST-077-R2-052594.pdf

See page 14 for the diagram.

Chilly Willy
03-23-2013, 03:55 PM
Since TmEE brought it up, is it correct that the Saturn has both the 68k derivative and a Yamaha "custom saturn chip" for FM? The Yaubause wiki (http://wiki.yabause.org/index.php5?title=Main_Page) indicates that is so, but I've seen FAQs wrong less often than wiki. It seems like that chip alone should have dominated the generation for sound quality, so we have yet another Saturn "mess" confusing under resourced developers of the time?

The SCSP is a 68000, a DSP, and associated control logic in one chip. The control logic could be set as plain PCM channels, or linked together for FM synthesis. There is no compression supported, except via software decompression by the 68000, or by the SH2 as the data is copied into sound ram.

I think the lack of hardware compression support is what made the Saturn sound for games worse than other consoles for the same game - you NEEDED compression to get all the sounds into sound ram, but then you were stuck doing poor ADPCM with the 68000 on a limited number of channels on the Saturn. By comparison, all 24 channels in the SPU of the PSX automatically handled Sony's XA ADPCM format in hardware. In fact, it's the ONLY format the SPU used for samples stored in the sound ram - you couldn't play uncompressed audio. So if uncompressed samples COULD fit in the sound ram, the Saturn would have sounded better since it plays uncompressed samples, while the PSX doesn't.

The DSP was for effects like reverb or echo or QSound. It was not general-purpose enough for decoding compressed samples.

TmEE
03-23-2013, 04:16 PM
That DSP in the YM can do ADPCM if you program it to, it can crunch numbers really well. Only problem is documentation... You only got to see the "algebraic" syntax instead of native. Many modern DSP assemblers take either syntax. There is compares and jump, and that is all you need for most stuff.

Chilly Willy
03-23-2013, 04:52 PM
That DSP in the YM can do ADPCM if you program it to, it can crunch numbers really well. Only problem is documentation... You only got to see the "algebraic" syntax instead of native. Many modern DSP assemblers take either syntax. There is compares and jump, and that is all you need for most stuff.

I think you're confusing the DSP in the SCU with the "DSP" in the SCSP. The DSP in the SCSP is the "standard" step DSP for processing digital filters on audio, like reverb and other digital filters. It certainly does NOT follow a program, nor have compares and jumps. The DSP instructions sets muxes and logical ops at each step through the DSP, leading the inputs through certain operations that result in the output.

sheath
03-23-2013, 06:18 PM
So it looks like the SCSP can work with the SCU DSP and SH2s and I see on page 16 of the document I linked a reference to it feeding itself independent of the rest of the system through Main RAM. Can the additional 512KB CD-ROM sub System RAM be utilized for streaming audio here? I've been wondering what that RAM was for since the SH1 isn't programmable.

TmEE
03-23-2013, 07:29 PM
I think you're confusing the DSP in the SCU with the "DSP" in the SCSP. The DSP in the SCSP is the "standard" step DSP for processing digital filters on audio, like reverb and other digital filters. It certainly does NOT follow a program, nor have compares and jumps. The DSP instructions sets muxes and logical ops at each step through the DSP, leading the inputs through certain operations that result in the output.

I am talking about the SCSP DSP not tho SCU one.

The DSP in YM is completely programmable, and has absolutely no presets, you sent it binary that the assembler spits out and it will do it. Sega gave developers several with the standard driver that most games use that implement various effects. All it does is what you make it do. I don't have firsthand experience, but Steve Snake has told me these things. Looking at the docs there really is no information at all about the DSP, only tiny examples in algebraic format and that is pretty much it. Only hard limit you get is 126 cycles per sample...

zyrobs
03-23-2013, 07:54 PM
The SCSP is a 68000, a DSP, and associated control logic in one chip.

Technically, the SCSP is the synth chip on its own (which houses a DSP). It is controlled by a 68k, and it has 512k RAM, which is also used for 68k code, DSP code, etc.

You can, however, control the SCSP from the SH2. One of the Lobotomy games did that, either Exhumed or Duke Nukem. Most games using ADPCM or ADX audio did that too, decoded the streams with SH2 + SCU DSP, and sent it decompressed to the 68k/SCSP. I don't know if the SCU DSP could control it, though. That would be something really stupid to do.

The only problem with the Saturn audio hardware was the lack of memory, which prevented the use of high quality samples. The lack of hardware compression exacerbated the problem.

For FM functions, very few games used them because the SCSP was, in practice, a Yamaha keyboard. The dev tools worked in a similar fashion. The musicians played tunes in their keyboards, recorded them as MIDI, then uploaded it to the Saturn with their own sample banks. Maybe set some DSP effects (reverb, echo, etc) to make it sound cooler. But, most games didn't even do that, they just streamed audio either from the CD, or from the data track as prerecorded PCM, ADPCM, ADX, etc... which allowed for more sample space for sound effects, anyway - and that was more important in many cases. FM was seldom used, and mostly just for small menu jingles or the odd pitch bend effect. I think the title that used FM the most was Game Basic, but even that mixed in a lot of pre-defined PCM samples.

The Model 2/3 bypassed the low memory problem by having two complete 68k+SCSP+RAM setups on them. That gave double the channels and double the sample space. Sometimes they, too, just played streaming ADPCM though, and so did the ST-V.

The Dreamcast AICA was effectively a SCSP with double the channel count and no FM functions, with more RAM, and controlled by a much faster ARM cpu that could handle decompression on its own.

Chilly Willy
03-23-2013, 08:50 PM
I am talking about the SCSP DSP not tho SCU one.

The DSP in YM is completely programmable, and has absolutely no presets, you sent it binary that the assembler spits out and it will do it. Sega gave developers several with the standard driver that most games use that implement various effects. All it does is what you make it do. I don't have firsthand experience, but Steve Snake has told me these things. Looking at the docs there really is no information at all about the DSP, only tiny examples in algebraic format and that is pretty much it. Only hard limit you get is 126 cycles per sample...

No, you're clearly describing the SCU DSP other than the 126 cycles per sample. The SCSP DSP is shown in the SCSP User Manual on page 106 and looks like this:

http://i.imgur.com/0L4dTdP.png

The "Microprogram" is a series of 128 64-bit values stored in a small ram buffer in the SCSP, where one 64-bit value is used per step of the DSP. Each 64-bit value drives the selectors and shifters and adders and muxes and whatnot shown in the image.

From the SBL manual, the SH2 actually decodes the ADPCM on the fly, streaming it to the sound ram as it does so. Up to four ADPCM streams are permitted, and may be streamed straight off the CD. The manual even gives the percentage of CPU time the decompression takes away based on the sample size (8 or 16 bit) and the sample rate (up to 44.1kHz).

TmEE
03-24-2013, 04:38 AM
my PDF has half the pages missing... got te redownload it. I see now how that would not really work out. It can still calculate lots of stuff, and store it in main RAM (or take stuff from main RAM)

Chilly Willy
03-24-2013, 04:56 PM
my PDF has half the pages missing... got te redownload it. I see now how that would not really work out. It can still calculate lots of stuff, and store it in main RAM (or take stuff from main RAM)

Yes, it has a ring buffer for main sample storage, and temp ram for coefficients, but I don't see how you'd be able to use that to decode ADPCM. It's primarily meant for FIR filters and the like. By adjusting the coefficients and tap points and length of the ring buffer, you can do everything from simple low/high/band pass filters to reverb to QSound.

Now the SCU DSP, on the other hand, is a standard Harvard Architecture DSP with a program and such like you described. You can DMA data into it, let it work on that data, and then the DSP can start a DMA out on the final data. That could EASILY be used to decode ADPCM. If you were using the slave SH2 for 3D calculations instead of the SCU DSP, the SCU DSP would be prime for helping with audio decoding.

TmEE
03-24-2013, 05:16 PM
You don't necessairly need to do ADPCM :P

sheath
03-25-2013, 01:00 AM
So wait, do I understand correctly that the PS1 sound system and the PS2 sound system are entirely CPU driven, so decompression would be handled by the CPU in either? If so, how is this different than the Saturn allowing for the SCU DSP or slave SH2 doing the same?

Chilly Willy
03-25-2013, 01:44 AM
So wait, do I understand correctly that the PS1 sound system and the PS2 sound system are entirely CPU driven, so decompression would be handled by the CPU in either? If so, how is this different than the Saturn allowing for the SCU DSP or slave SH2 doing the same?

No, the SPU decompresses the samples in the PS1/PS2. The difference is the PS1 allows 24 channels of compressed sound all playing at the same time, and the Saturn maybe 4 channels of compressed sound playing at the same time. If you want to use those 32 channels, most of them MUST be uncompressed samples.

And the reason it matters is the PS1 and Saturn both have 512KB of sound ram, but the PS1 sound ram is equivalent to 2MB of sound ram due to the compression. So the common problem on the Saturn is getting that 4:1 compression, and the most common method is to switch from 16-bit to 8-bit samples (for 2:1) and from 44100 to 22050 Hz sample rates (another 2:1 for a total of 4:1). And that's why many Saturn ports don't sound as good as the PS1 port.

Barone
03-25-2013, 02:44 AM
No, the SPU decompresses the samples in the PS1/PS2. The difference is the PS1 allows 24 channels of compressed sound all playing at the same time, and the Saturn maybe 4 channels of compressed sound playing at the same time. If you want to use those 32 channels, most of them MUST be uncompressed samples.

And the reason it matters is the PS1 and Saturn both have 512KB of sound ram, but the PS1 sound ram is equivalent to 2MB of sound ram due to the compression. So the common problem on the Saturn is getting that 4:1 compression, and the most common method is to switch from 16-bit to 8-bit samples (for 2:1) and from 44100 to 22050 Hz sample rates (another 2:1 for a total of 4:1). And that's why many Saturn ports don't sound as good as the PS1 port.
Great stuff, Chilly, thanks for the explanation ("You must spread...").
But I must ask you for a bit more (:p): How does the 3DO hardware compare to them both (in terms of compression, number of channels, etc...)?

sheath
03-25-2013, 10:33 AM
No, the SPU decompresses the samples in the PS1/PS2. The difference is the PS1 allows 24 channels of compressed sound all playing at the same time, and the Saturn maybe 4 channels of compressed sound playing at the same time. If you want to use those 32 channels, most of them MUST be uncompressed samples.

And the reason it matters is the PS1 and Saturn both have 512KB of sound ram, but the PS1 sound ram is equivalent to 2MB of sound ram due to the compression. So the common problem on the Saturn is getting that 4:1 compression, and the most common method is to switch from 16-bit to 8-bit samples (for 2:1) and from 44100 to 22050 Hz sample rates (another 2:1 for a total of 4:1). And that's why many Saturn ports don't sound as good as the PS1 port.

Okay, I didn't want to leave that unquestioned from an earlier post in this thread and wasn't sure myself besides. I didn't find anything about the SCU or SCSP last time I checked years ago. It makes perfect sense that Sony would carry over ADPCM-like compression from its earlier chips, such as in the SNES. Sounds like Sega ran into the same problem as the rest of the Saturn, software/assembly solutions weren't fast and easy enough for developers that generation.

Can we get some idiot-tube videos of this in action to put a face on it please?

Make sure to click highest quality settings before listening: (will replace videos if we find better ones)

https://www.youtube.com/watch?v=N2SRGmJ79eY


https://www.youtube.com/watch?v=2IoLuxGnrMQ


https://www.youtube.com/watch?v=yJFEFa3fLfQ


https://www.youtube.com/watch?v=wAOl0YfV7GU

Barone
03-25-2013, 11:35 AM
What you'll hardly notice in the MKII videos is that the Saturn version is lacking several samples. One that is noticeable is the "flawless victory" one. But there are several in game ones lacking. I can list them later, tonight.

sheath
03-25-2013, 11:44 AM
I noticed that the Shao Kahn samples are missing in the Saturn version, the laugh is the most prominent. The music sounds bad to me in both versions, kind of indistinct like the SNES game.

Barone
03-25-2013, 11:50 AM
The music is said to be reused from the midi-based PC version, but IDK... I do know they suck, really.

Chilly Willy
03-25-2013, 03:45 PM
Great stuff, Chilly, thanks for the explanation ("You must spread...").
But I must ask you for a bit more (:p): How does the 3DO hardware compare to them both (in terms of compression, number of channels, etc...)?

The 3DO is rather similar to the Jaguar - there's no "sound chip" per se, instead, they have a processor whose job is the generate all the sound using data in regular memory and a custom program. The 3DO has a fairly standard 16-bit DSP (rather like the SVP) which generates a single 16-bit stereo stream to the DAC. The program run by the DSP determines how many channels are added together, how large the samples are, and what format/compression there may be. The DSP at least is running at twice the speed of the ARM (25MHz instead of 12.5). So in that it has no sound-related hardware, it's much worse than the Saturn or PSX. However, if you need to have on-the-fly algorithmically generated audio for some reason, it's better than the PS1 (you would need to use the main CPU in the PS1 for that kind of audio), and about the same as the Saturn (which could use one of the SH2s or the SCU DSP).

sheath
03-25-2013, 06:14 PM
The music is said to be reused from the midi-based PC version, but IDK... I do know they suck, really.

Just got to listen to the SFZ3 videos on the Dolby Prologic System, the PS1 is obviously higher frequency, which sorts some musical instruments to my satellite speakers while the Saturn remains in the front. Like you said in PM, neither one sounds "bad" but the PS1 music is definitely higher fidelity. Interestingly, the Dreamcast version recorded by the same fellow (https://www.youtube.com/watch?v=f6devCa5zik) doesn't sound any better than the Saturn game.

Let's see what Youtube's lazy posters can do with these vids:
Scorcher (https://www.youtube.com/watch?v=h3lyBL-FOkc) (Hey Look who it is)
Panzer Dragoon Zwei (http://www.youtube.com/watch?v=7VM9MGtG9cg&feature=share&list=PL420827C8056C0CE3)

Both of the above surround me with sound on my ancient Dolby Pro-Logic system similarly to what SFZ3 on PS1 does with its music. That's all I got.

kool kitty89
03-25-2013, 07:44 PM
So wait, do I understand correctly that the PS1 sound system and the PS2 sound system are entirely CPU driven, so decompression would be handled by the CPU in either? If so, how is this different than the Saturn allowing for the SCU DSP or slave SH2 doing the same?
No, the SPU decompresses the samples in the PS1/PS2. The difference is the PS1 allows 24 channels of compressed sound all playing at the same time, and the Saturn maybe 4 channels of compressed sound playing at the same time. If you want to use those 32 channels, most of them MUST be uncompressed samples.

And the reason it matters is the PS1 and Saturn both have 512KB of sound ram, but the PS1 sound ram is equivalent to 2MB of sound ram due to the compression. So the common problem on the Saturn is getting that 4:1 compression, and the most common method is to switch from 16-bit to 8-bit samples (for 2:1) and from 44100 to 22050 Hz sample rates (another 2:1 for a total of 4:1). And that's why many Saturn ports don't sound as good as the PS1 port.

Tomaitheous also mentioned that not only does the PSX (and PS2) sound system use the same sample format as the SNES's SPC module, but the audio DSP in the PSX is a direct derivative of the SPC units, but with a different configuration on the actual sound channels supported, RAM uses, and connectivity to the main bus (ability to update sample RAM). I'm also pretty sure the PSX doesn't have a dedicated CPU/MCU (like the 6502 based SPC700) and is controlled by the main CPU instead. (not positive on this though, but it shouldn't have a huge impact either way . . . especially with the very limited way the SPC unit was used in the SNES)

Chilly Willy
03-25-2013, 10:12 PM
Tomaitheous also mentioned that not only does the PSX (and PS2) sound system use the same sample format as the SNES's SPC module, but the audio DSP in the PSX is a direct derivative of the SPC units, but with a different configuration on the actual sound channels supported, RAM uses, and connectivity to the main bus (ability to update sample RAM). I'm also pretty sure the PSX doesn't have a dedicated CPU/MCU (like the 6502 based SPC700) and is controlled by the main CPU instead. (not positive on this though, but it shouldn't have a huge impact either way . . . especially with the very limited way the SPC unit was used in the SNES)

No, the SPU doesn't have a control processor. It has a filter unit much like the DSP in the SCSP, capable of echo, reverb, QSound, etc, but any changes to the channel controls (note on/off, change of pitch, etc) must be done by the main CPU. In that respect, the Saturn is superior since it has the 68000 to do the music handling. Of course, that's not a major source of slow-down on a processor like the MIPS, but every little bit helps when you're trying to squeeze every last bit of power from a console.

Basically, the Saturn is superior in most respects except for one: no hardware support for compressed samples. Oh well - can't have everything. :D

sheath
03-25-2013, 10:23 PM
SNES SPC audio uses filters heavily to obscure 32khz, though much more limited, audio samples. Is it possible that these systems could blur the lines between 22khz, 32Khz and 44Khz audio samples in a similar fashion? I would think that filters would work better with greater source material.

kool kitty89
03-27-2013, 03:36 AM
SNES SPC audio uses filters heavily to obscure 32khz, though much more limited, audio samples. Is it possible that these systems could blur the lines between 22khz, 32Khz and 44Khz audio samples in a similar fashion? I would think that filters would work better with greater source material.
The filtering was less related to the 32 kHz output and more related to the artifacting of relatively low bitrate samples . . . you'd want FAR less aggressive filtering for just the 32 kHz output.

This is similar to the Amiga's filter settings, with one moderate filter that's forced and a software controllable one that's much more aggressive. (unfortunately, the SNES's external filtering is forced)

Black_Tiger
03-27-2013, 09:03 AM
Just got to listen to the SFZ3 videos on the Dolby Prologic System, the PS1 is obviously higher frequency, which sorts some musical instruments to my satellite speakers while the Saturn remains in the front. Like you said in PM, neither one sounds "bad" but the PS1 music is definitely higher fidelity. Interestingly, the Dreamcast version recorded by the same fellow (https://www.youtube.com/watch?v=f6devCa5zik) doesn't sound any better than the Saturn game.

Let's see what Youtube's lazy posters can do with these vids:
Scorcher (https://www.youtube.com/watch?v=h3lyBL-FOkc) (Hey Look who it is)
Panzer Dragoon Zwei (http://www.youtube.com/watch?v=7VM9MGtG9cg&feature=share&list=PL420827C8056C0CE3)

Both of the above surround me with sound on my ancient Dolby Pro-Logic system similarly to what SFZ3 on PS1 does with its music. That's all I got.

Did you check to see what the arcade version sounds like? This may just be another port that strives for authenticity over sound quality. The SFZ1 port defaults to lower (arcade) quality samples, but higher quality ones can be unlocked.

sheath
03-27-2013, 11:19 AM
That thought occurred to me but I didn't want to load up the thread with videos, and didn't want to compare emulation (MAME) to real hardware videos and make any claims. I wonder if SFZ3 has an arranged soundtrack option in any version. I can only check the Dreamcast version of Alpha 3 here.

TrekkiesUnite118
03-27-2013, 11:40 AM
There isn't an option like that in the Saturn version to my knowledge, but I can check again tonight when I get home. I could also do some recordings of the Saturn version if anyone wants me to.

Though I think Joe's video of Alpha 3 on the Saturn sounds better than the one you linked:

pr8NEv4SIP8

I am curious though if there's some kind of hidden options menu similar to whats in Vampire Savior in Capcoms other 2D Fighter ports on the Saturn.

TmEE
03-27-2013, 11:43 AM
The filtering was less related to the 32 kHz output and more related to the artifacting of relatively low bitrate samples . . . you'd want FAR less aggressive filtering for just the 32 kHz output.

This is similar to the Amiga's filter settings, with one moderate filter that's forced and a software controllable one that's much more aggressive. (unfortunately, the SNES's external filtering is forced)

The external filtering in the SNES hardware has almost no effect on the sound. All that does effect sound happens in the digital domain.

kool kitty89
03-28-2013, 02:38 AM
The external filtering in the SNES hardware has almost no effect on the sound. All that does effect sound happens in the digital domain.
I know the compressed interpolated samples will be muffled sounding in general at low bitrates (low sample rates), but I'd thought the external filtering is what prevented high bitrate samples from sounding clearer. (the actual use of high bitrate samples would be limited, of course, given the wave RAM and limited -and painful- mechanism to update wave RAM on the fly, but it's still technically possible)
Or is there also very heavy digital filtering going on internally as well that would ruin high sample rate stuff too?

TmEE
03-28-2013, 02:49 PM
It has same effect on high bit rates too, all stuff that is too close to each other gets flattened... that means high freqs, in the context of the sample itself. High parts in a 4KHz sample get flattened, and same is true for 40KHz sample.

kool kitty89
03-28-2013, 04:57 PM
It has same effect on high bit rates too, all stuff that is too close to each other gets flattened... that means high freqs, in the context of the sample itself. High parts in a 4KHz sample get flattened, and same is true for 40KHz sample.
I understand that aspect of low-pass filtering in general, I just wasn't aware that the internal digital filtering of the SPC unit cut things off that much.

Does the PSX's sound system have similar problems, or does that change filtering compared to the SPC implementation in the SNES?

TmEE
03-28-2013, 07:19 PM
External filtering in SNES has almost no audible effect on the sound. It only works on stuff beyond 16KHz that the SPC cannot do anyway (well aliases can).

PSX is modified, it is not vanilla SPC. It has different filtering constants and probably more changes. I am not intimately familiar with PSX audio.

Chilly Willy
03-28-2013, 11:23 PM
Does the PSX's sound system have similar problems, or does that change filtering compared to the SPC implementation in the SNES?

The PSX was designed for 44kHz samples, so even though they're compressed, they sound much better than compressed 16kHz samples like on the SNES.

I think the "worst" you see for sample rates on the PSX is 22kHz.

zyrobs
03-29-2013, 10:43 PM
The PSX was designed for 44kHz samples, so even though they're compressed, they sound much better than compressed 16kHz samples like on the SNES.

I think the "worst" you see for sample rates on the PSX is 22kHz.

Divisions of the samplerate used by XA Audio were also used. XA Audio is 37.8khz, and at least the Command & Conquer titles had the sounds in half of that.

Chilly Willy
03-30-2013, 12:36 AM
Divisions of the samplerate used by XA Audio were also used. XA Audio is 37.8khz, and at least the Command & Conquer titles had the sounds in half of that.

Yes, but notice that that is still very high quality compared to older PCM rates. That's probably not noticeable by most folks from CD rates. This is probably a good time to post this:

http://people.xiph.org/~xiphmont/demo/neil-young.html

TmEE
03-30-2013, 01:29 AM
That article is great but it fails to mention one thing : your modern sound card (ever since AC97) is locked to one particular sample rate (always a multiple of 48KHz) and when you play any sample that has differing rate from that one native rate you will have a dirty resample process going to happen and it severly skews the results. 48KHz can and usually does sound noticably different from 96KHz on most modern sound cards...
My Yamaha plays all same rates natively like old sound cards before AC97 did, and there are no such artifacts involved.
I do agree with most on that article, except the "All signals with content entirely below the Nyquist frequency (half the sampling rate) are captured perfectly and completely by sampling; an infinite sampling rate is not required. Sampling doesn't affect frequency response or phase. The analog signal can be reconstructed losslessly, smoothly, and with the exact timing of the original analog signal."
A frequency that is close to nyquist limit has its volume and phase info so shifted together that you'll not be able to recreate it, you only have 3...4 samples to represent something and it really is messy... most people cannot hear the difference though, not 30+ folks anyway...
High sample rates and bit depths do matter a lot for synthesis of sounds, and mixing different stuff together. These are however all realtime stuff not some recording that will never change, which that article deals with. Game consoles do the realtime bit however...
EDIT: unrelated, but the article brought in a really naiss example using light. I can see light from remote controls that do not have tinted IR LEDs in a dark room :P

sheath
03-30-2013, 09:22 AM
EDIT: unrelated, but the article brought in a really naiss example using light. I can see light from remote controls that do not have tinted IR LEDs in a dark room :P

Must study Tiido, write paper. *rubs hands greedily*

zyrobs
03-30-2013, 03:08 PM
That article is great but it fails to mention one thing : your modern sound card (ever since AC97) is locked to one particular sample rate (always a multiple of 48KHz) and when you play any sample that has differing rate from that one native rate you will have a dirty resample process going to happen and it severly skews the results. 48KHz can and usually does sound noticably different from 96KHz on most modern sound cards...


What makes it irrelevant is that 99.9% of all modern speakers have a frequency range topping at 20khz, so they can't play back anything that uses a higher frequency rate than CD Audio to begin with.

Is Azalia HD still affected by the 48khz lock by the way? I know that Soundblasters were hard locked to it ever since the Live, and AC97 is only locked onto it if you use its own internal DAC - but not if you use digital out to a receiver.

kool kitty89
03-31-2013, 02:37 AM
The PSX was designed for 44kHz samples, so even though they're compressed, they sound much better than compressed 16kHz samples like on the SNES.

I think the "worst" you see for sample rates on the PSX is 22kHz.
For games making heavy use of in-game speech/SFX where streaming is impractical (or limited), or for games trying to include lots of speech within few CDs (or just one) I'd imagine there were still cases using considerably less than 22 kHz . . . probably not super common though.

I know there were still some late 90s multimedia-intensive games that settled for some pretty poor quality samples overall. I tried out The Elder Scrolls Adventures: Regduard a couple months back and it's got a LOT of quite low quality speech samples and some relatively low quality streaming music or ambient sounds in some areas (more tolerable sounding music typically, though). It's also not just low quality, but relatively poorly preprocessed . . . not well filtered or optimized (and no interpolation), and really straining with some high frequency stuff that bleeds through the filtering in old Sound Blaster cards. (or at least the SB-16 Apolloboy was using at the time)
That's a very dialog intensive game though, and I assume it's just using 4-bit ADPCM. With the RAM and HDD space typical of 1998 PC games, I assume it's more a restriction of actual CD-ROM space they were willing to use. (still, it's a 2 disc game) Maybe it's just 8-bit PCM at low sample rates. (seems kind of odd they'd resort to that given the circumstances though . . . I could see uncompressed 8-bit PCM if they could afford the bitrates to allow that at decent quality -or ulaw for that matter- but that's definitely not the case here -and with the sort of CPU resource required for that game -or 1998 games in general, a few ADPCM streams would seem like a drop in the bucket to deal with)

Then again, even in some more extreme cases, you'd have the filtering and interpolation of the PSX's SPU to mask poorly preprocessed stuff. (optimized formatting and preprocessing really seem to be a huge issue for quality in general, including a lot of really strained sounding samples that seem to assume heavy filtering on the output to mask that . . . or developers simply didn't care -but given there's a ton of old DOS games with samples that sound like they fit much better with typical early 90s Sound Blaster filtering, and really rough without filtering, I'd assume many were relying on external filtering as such)

TmEE
03-31-2013, 12:22 PM
What makes it irrelevant is that 99.9% of all modern speakers have a frequency range topping at 20khz, so they can't play back anything that uses a higher frequency rate than CD Audio to begin with.

Is Azalia HD still affected by the 48khz lock by the way? I know that Soundblasters were hard locked to it ever since the Live, and AC97 is only locked onto it if you use its own internal DAC - but not if you use digital out to a receiver.

The effects of this dirty resampling are heard well into audible range. AC97 resamples even the digital stuff in many cases (not always), direct loopback from SPDIF input to SPDIF output in usually left untouched (you have to look at datasheets of the chips to know if that happens or not).
HD Audio / Azalia is is a bit more flexible, there's 48, 96 and 192KHz native rates, all inbetweens are resampled though, most else is same as AC97. 48 and 96 are not always present though. Again datasheets help to let you know what the hardware does, but there's also a huge software layer involved. Sound Blasters have software based noise reduction in them for example, very clearly seen in spectrograms of recordings, also resampling artifacts too.

Tom M.
01-15-2014, 08:30 AM
I have been reading through rougly 60% of this thread trying to find definite answers to my questions:

1. Can Playstation 1 sound hardware generate sound without any external sound data? Meaning: can it for instance produce 3 channel PSG music to be played during a real PSX game without any sort of externally generated sound data?

2. Can Saturn do that?


Thank you!

Barone
02-08-2014, 02:30 AM
So, what's the deal with the Saturn versions sounding inferior? Is it less capable of streaming audio at good sampling rates or something like that?
Let's see what Yuzo has to say about that:
"Kikizo: What was working with the Saturn like? It's notorious for being a difficult system.

Koshiro: Oh, of course. We made Vatlva and Thor for the system. Vatlva was CD redbook audio, but Thor... it was a lot more difficult. The sound in the game is orchestral, and the sound memory was also limited to 512KB. It's bigger than that of the SFC, but for orchestral-style music, its limitations are very strict. It's tough to fit all of the orchestral instrument samples you need into that space. You didn't need the sort of programming skills you did for the SFC and Megadrive, though - you just used a MIDI input sequencer. I used a Mac program called Vision for Thor's sound. Still, the memory limitation was the biggest issue to work around.

Kikizo: The PlayStation was much easier, right?

Koshiro: Yes, it was much better. The memory size for sound was the same, but the compression algorithms were much better than the Saturn. It used the same compression system as their minidiscs did at the time. It allowed us to fit more and better quality music and sound into smaller space."
http://archive.videogamesdaily.com/features/yuzo_koshiro_iv_oct05_p2.asp

Barone
02-08-2014, 03:08 AM
I also found what seems to be a copy-paste text version of the "Playstation Sound Artist" manual in an old thread at assemblergames (tons of text there):

"The PlayStation sound artist board (DTL-H700, hereinafter referred to as the PlayStation
sound board) and the PlayStation sound artist tool (DTL-S710, hereinafter referred to as the
PlayStation sound tool) are applications executed on Apple Macintosh. They are tools for
creating sound data for the PlayStation unit. Using the tools along with existing sound tools
enables music creation for the PlayStation unit."

"The PlayStation sound tool supports the following sound data formats.
* SMF: Standard MIDI file (Format 1)
* AIFF: 16-bit audio interchange file format (AIFF)
* SDII: SoundDesignerII file format


The PlayStation sound tool supports the following sound formats for the PlayStation unit.
* SEQ: PlayStation sound sequence format
* VAG: PlayStation waveform format
* VAB: PlayStation wave bank format
* DA: PlayStation CD-DA format
* XA: PlayStation CD-ROM XA audio channel format
The PlayStation sound tool also supports the following sound formats for the
PlayStation unit.
* SEP: PlayStation sound sequence chuck format
* VH: PlayStation wave bank header format
* VB: PlayStation wave bank body format
The XA format supported by RAW2XA is based on the following specifications.
CD-ROM XA"

http://www.assemblergames.com/forums/showthread.php?10146-Playstation-Sound-artist-DTL-H700-DTL-S710-docs


Some additional info on how it worked can be found here at Chapter 11: CD/Streaming Library and Chapter 16: Basic Sound Library of the Playstation's "Run-Time Library Overview":
http://read.pudn.com/downloads25/sourcecode/windows/multimedia/82020/LIBOVR.PDF

zyrobs
02-08-2014, 11:27 AM
It was already known that the Saturn SCSP's biggest disadvantage is lack of memory space, exacerbated by lack of hardware compression support. It could play anything that the 68k or the SH2s could decode, though (adpcm, later ADX).

Barone
02-08-2014, 11:32 AM
It was already known that the Saturn SCSP's biggest disadvantage is lack of memory space, exacerbated by lack of hardware compression support.
A lot of people don't want to believe it though; so maybe after reading God's Yuzo's words they'll admit it.

gamevet
02-09-2014, 01:54 PM
I used to think that the music in Street Fighter Alpha 2 (Saturn) was being played from the CD, until I opened the CD lid on the Saturn and noticed that the music was still playing. It sounded pretty good to me.


Errr, maybe not. I just tried it and the Saturn goes to the menu screen. I could have sworn there was a Saturn title that kept playing music when I opened the lid. Maybe I'm thinking of the Dreamcast.

Da_Shocker
02-09-2014, 02:08 PM
Ya'll know that the 4MB ram cart eliminates the cant play compression issues.

zetastrike
02-09-2014, 02:11 PM
Ya'll know that the 4MB ram cart eliminates the cant play compression issues.

I thought the carts were only for VRAM

Da_Shocker
02-09-2014, 02:29 PM
I thought the carts were only for VRAM

It's actually general purpose really. One thing that seems to get overlooked with these ports is that the voices are clear an no longer have that trademark Saturn muffled effect.

Chilly Willy
02-14-2014, 10:12 PM
Ya'll know that the 4MB ram cart eliminates the cant play compression issues.

No, it doesn't. All it allows is for more space for decompressed samples, but they would still need to be DMA'd into sound ram before they could be played. A better way to handle compressed samples would be have the Slave SH2 decompress the samples on the fly into a buffer that would be DMA'd into sound ram in a double-buffered manner. While the 68000 could be used for decompression, the SH2 is better suited for the task. My tests on the 32X shows what could be possible... save a low bitrate OGG into that ram cart, then play it in real-time using the Slave SH2. That would leave all the sound ram for game sounds. You could also load a MOD/XM into the ram cart and play it via the Slave SH2. Again, the sound ram is free for game sounds.

zyrobs
02-14-2014, 10:20 PM
I believe later Saturn games used ADX audio just like that.

Barone
02-15-2014, 12:29 AM
LbEk3zG_Tqc

Xan
02-28-2014, 12:42 AM
Great topic!

Does anyone know about the accuracy of the PSX SPU emulation on PS2? I presume the PS2 only includes the CPU+GTE+MDEC ASIC, so all of the rest (such as the SPU) is done in software. I know of one case where the reverb is definitely missing, so the emulation is not perfect. This needs more attention and research I think...

Speaking of which, does anyone know which games use the different DSP presets to great effect? AFAIK only one preset can be used at a time (and toggled for each voice), and using an effect cuts the sample rate in half (downsampling from 44.1 kHz to 22.05 kHz)?

For example, Squaresoft games seem to have rather nice sample quality, while the King's Field series and Doom are a bit on the "muddy" side (which adds a lot to the atmosphere in those games, however).

On the subject of QSound on the Playstation, unlike what was stated in this thread, it is said here (http://www.giantbomb.com/q-sound/3015-3007/) that the effects processor isn't capable of doing that and it's only supported through pre-recorded CD audio. Perhaps one of the presets could have been mistaken for QSound?

As far as the Saturn goes, I always thought that Duke Nukem 3D used its FM capabilities; I guess I can't be 100% sure that it's not just sampled. At least some tracks seem to have a very analog-like quality to them:

0w7XWgIedI4
XZwynuOCAUg

Also, there are a lot of reports about the Dreamcast AICA actually being XG compatible, but apparently not many games used that format. The software for that obscure MIDI interface is supposed to have used it. What's the verdict here on this?

TmEE
02-28-2014, 10:15 AM
Duke3D on Saturn plays CDDA exclusively and that is what most games do. Few games stream ADX format, but there's a bunch that do realtime music. Look for SSF collections.
Most Dreamcast games stream ADX sound, few do CDDA and even less do realtime sound.

Xan
02-28-2014, 12:19 PM
Fair enough, but what was the purpose of including an elaborate 32-channel sound setup with FM capability and a dedicated 68000 if it wasn't used by most games anyway? I suppose the lack of ADPCM was just too crippling for its 512 KB sound RAM.

Obviously redbook streaming has the disadvantage that no other data can be loaded, or else the music stops, which would be inaccpetable for games with rapidly changing content. For the genres that are prevalent on the Saturn I can see how that would be less of an issue, though.

Chilly Willy
02-28-2014, 03:50 PM
Does anyone know about the accuracy of the PSX SPU emulation on PS2? I presume the PS2 only includes the CPU+GTE+MDEC ASIC, so all of the rest (such as the SPU) is done in software. I know of one case where the reverb is definitely missing, so the emulation is not perfect. This needs more attention and research I think...

The PS2 SPU is merely an upgraded version of the PS1 SPU - it keeps the orginal 24 channels and adds another 24 channels (for a total of 48) while increasing the sample rate to 48kHz. It should be identical to the PS1 SPU in PS1 games - it's not emulated at all. If the game has problems with the sound, it's probably doing something like not clearing bits in control registers that Sony told people to clear for future improvements... like adding another 24 channels and increasing the sample rate.


Also, there are a lot of reports about the Dreamcast AICA actually being XG compatible, but apparently not many games used that format. The software for that obscure MIDI interface is supposed to have used it. What's the verdict here on this?

Like most other sound systems, the DC sound uses a processor to handle things like music scores (an ARM7), so it is indeed XG compatible... just like every other sound system with a programmable sound processor. ;) :D

I think GM level 2 put an end to the XG craze of the time.

Xan
02-28-2014, 04:16 PM
Heh, I guess I forgot about the PS2 SPU :D

Is there any information on how the Gameboy sound channels are done on the DS? The GB ASIC with Z80 and sound is included on the main GBA chip alright, and the DS has an ARM7, but did they include the hardware for those channels (which are used by a multitude of GBA games, of course) or is it done in software on the ARM9?

TmEE
02-28-2014, 05:21 PM
I think GM level 2 put an end to the XG craze of the time.
GM Level 2 is still technically inferior to vanilla XG spec. What did put end to XG (and whole GM thing) is the various software based DAWs, hardware is kinda irrelevant these days. It is also something Yamaha pioneered but decided to stop because it hurt their hardware sales... now it has bitten them in the ass, if they continued they would have ruled the sound world.

Chilly Willy
02-28-2014, 09:08 PM
Heh, I guess I forgot about the PS2 SPU :D

Is there any information on how the Gameboy sound channels are done on the DS? The GB ASIC with Z80 and sound is included on the main GBA chip alright, and the DS has an ARM7, but did they include the hardware for those channels (which are used by a multitude of GBA games, of course) or is it done in software on the ARM9?

The NDS has the GBA sound channels, plus 16 pcm channels.


GM Level 2 is still technically inferior to vanilla XG spec. What did put end to XG (and whole GM thing) is the various software based DAWs, hardware is kinda irrelevant these days. It is also something Yamaha pioneered but decided to stop because it hurt their hardware sales... now it has bitten them in the ass, if they continued they would have ruled the sound world.

It might have been "technically" inferior (and not by much), but what it was is open so that you could make compatible equipment without paying Yamaha. :)

A prioprietary system will lose to an "open" one no matter how much better (see the VCR wars as an example).

Xan
02-28-2014, 09:22 PM
Well, for example in Pokemon HGSS the "8-bit" tunes in there sound blatantly wrong when compared to the original games, with repurposed channels and overall different output. I was thinking that if the original hardware was present in the DS they could have just used that instead of providing some butchered renditions. Or maybe that hardware is only accessible in GBA mode. The Mega Man Zero collection could potentially suffer from similar issues, if there are some tracks in there that use the legacy GB channels (not quite sure on that).

On the other hand, I don't recall any major differences when playing GBA games on the DS that definitely make use of the GB channels...

Chilly Willy
02-28-2014, 09:52 PM
Well, for example in Pokemon HGSS the "8-bit" tunes in there sound blatantly wrong when compared to the original games, with repurposed channels and overall different output. I was thinking that if the original hardware was present in the DS they could have just used that instead of providing some butchered renditions. Or maybe that hardware is only accessible in GBA mode. The Mega Man Zero collection could potentially suffer from similar issues, if there are some tracks in there that use the legacy GB channels (not quite sure on that).

On the other hand, I don't recall any major differences when playing GBA games on the DS that definitely make use of the GB channels...

The push was on at that time for everyone to move to sampled music, no matter what. I doubt there was a game dev company exec anywhere that would approve of "GBA" music for an NDS game, even if it would sound better. :)

Xan
02-28-2014, 10:12 PM
Sure enough, in that time and age the GB channels would have been totally useless for a DS game... it was a bit different on the GBA though where the system could use the GB channels many devs were already familiar with to accompany those poor quality 8-bit samples and save a bit CPU time on mixing. Mario Kart Super Circuit is perhaps the most famous game I can think of to use the GB channels prominently, but there are lots of others (and of course a good amount of PCM-only ones).

Just to make sure that everyone knows what I'm talking about, here's an example of a game with the PCM channels turned on and off:
k7J910J9vk0
HbthgfrOUp0
Funnily enough, when listening to the music with everything present you don't even notice the GB channels playing, but they are certainly there :)

Silanda
02-28-2014, 10:20 PM
I think GM level 2 put an end to the XG craze of the time.

GM2 sucked balls. I suppose I can see where they were coming from: unify the warring GS and XG camps under the banner of GM2, but instead it became a watered down third standard that was universally adopted and helped to kill virtually all interest in developing GM hardware. The spec was way too conservative when even the first GM/GS compatible module (Roland SC-55) exceeded or matched it in some respects in 1991, and I don't think there were any really interesting GM instruments developed after the MU-2000 and the SC-8850 (the last which respectively advanced XG and GS). Yes, DAWs and samplers did eventually kill the need for GM hardware, but having a hardware box with a good variety of sounds was still pretty useful in the early years of this century. Hell, I still think it's useful now.

On the open standard aspect of GM2: That was actually part of its problem IMHO. It encouraged boring modules or further incompatibility. GS and XG modules of the time that GM2 was introduced were sporting roughly four to six times the number of sounds that the GM2 standard provided, as well as being equipped with DSP driven effects. 256 different instruments with limited effects was not enough, so any module wanting more would have its own instrument/NRPN mapping above the standard that GM2 provided (or possibly have GM2 compatibility as a separate mode). Yeah, you could make your instrument compatible only to the limited standard, and therefore be poorly equipped in terms of variety, but if you tried to make something more than that you'd either be left with something largely incompatible with everything else above GM2, or you'd have to adopt XG or GS anyway.

Xan
02-28-2014, 10:35 PM
GM2 sucked balls. I suppose I can see where they were coming from: unify the warring GS and XG camps under the banner of GM2, but instead it became a watered down third standard that was universally adopted and helped to kill virtually all interest in developing GM hardware. The spec was way too conservative when even the first GM/GS compatible module (Roland SC-55) exceeded or matched it in some respects in 1991, and I don't think there were any really interesting GM instruments developed after the MU-2000 and the SC-8850 (the last which respectively advanced XG and GS). Yes, DAWs and samplers did eventually kill the need for GM hardware, but having a hardware box with a good variety of sounds was still pretty useful in the early years of this century. Hell, I still think it's useful now.
Fully agree. Well, they still make these "hardware boxes with sounds" in the form of INTEGRA-7 nowadays; I don't think Sound Canvas is a name that ever had the best reputation with the majority of pro musicians, so I can see why they dropped it. That thing is still touted as GM2 compatible, interestingly enough, but of course it won't be compatible with MIDI files that make profound usage of GS...

Silanda
02-28-2014, 10:51 PM
Fully agree. Well, they still make these "hardware boxes with sounds" in the form of INTEGRA-7 nowadays; I don't think Sound Canvas is a name that ever had the best reputation with the majority of pro musicians, so I can see why they dropped it. That thing is still touted as GM2 compatible, interestingly enough, but of course it won't be compatible with MIDI files that make profound usage of GS...

For the pro's I'd agree, the Sound Canvas range had quite an amateur following though and I really liked those Konami Midi Power CDs. Those Integra-7s sound nice but they're too rich for my blood for a module alone these days, especially when I'm using an old Roland D-50 as my master keyboard.

Chilly Willy
03-01-2014, 04:21 AM
It may suck (how much is debatable, but suck it does), but GM2 + downloadable sounds spec is now the standard. You use that, or a fully mixed stream (MP3, OGG, FLAC, whatever). Of course, many people still use older formats as they prefer them. XM and IT are still HUGELY popular ways to put out music. I'm sure XG and GS have big followings still.

Da_Shocker
06-04-2014, 02:39 AM
Well how does the Saturn compare to the likes of the MT-32, AWE32/64, Ensoniq Soundscape Elite 2000, and the Turtle Beach Multisound Pinnacle. Might as well throw a Gravis Gravis UltraSound MAX in the mix. :D

Da_Shocker
04-01-2018, 05:04 PM
bumped