In the first waves of multimedia PCs - the CPU was tasked with doing sound, networking, hard drive control, etc. - pretty much all of the cost savings came from having minimal hardware for the auxiliary components and doing it all in drivers.
A common "Trick" was to buy cards that had essentially their own processors to handle this stuff - SoundBlasters, 3Com nics, IDE drive controllers that had their own processor (hell, even up to their own OS) since that freed the CPU up for doing actual work - gaming. Even an external or other
CPUs were a bottle neck but most people didnt tax the single core machines doing most daily work (office work, browsing the web) so it was fine, but once you load up a game that needs sound, 3d, networking, disk access all at once it would start stealing clock cycles trying to do all of that in one place.
A 16(!!!) bit ISA slot card, which revolutionized PC-audio-experience.
Are they still on the market or crashed by the ever-more-increasing onboard chips?
And there was Gravis Ultrasound, where you could upload samples into the RAM of the soundboard (that was like superpowermegatech back at these days :-)
IIRC, the highest degree of fidelity was fu**ng 16 MB of onboard RAM on the soundboard.
> had essentially their own processors to handle this stuff
Most of the benefit came from the sound card doing DMA from a memory buffer instead of using a high-frequency interrupt to have the CPU give it sound samples one or two bytes at a time (fetched from the very same memory buffer(s)).
More sophisticated cards could also do mixing of several sounds in "hardware" (usually by having their own little CPU do the work) instead of having the main CPU doing the mixing. Some of them could even play the constituent sounds at different speeds (Gravis Ultra Sound and Midi cards but the Midi cards usually had fixed sound samples). This mattered for more sophisticated game audio for a few years until x86 performance improvements made it irrelevant. DMA is still crucial.
I vividly remember playing around on a friend's 486 that had a scsi controller for the hard drives, that was the best 486 I ever used! It's been all win modems and liquid glass window borders since then!
MY NAME IS DOCTOR SBAITSO.
I AM HERE TO HELP YOU.
SAY WHATEVER IS IN YOUR MIND FREELY,
OUR CONVERSATION WILL BE KEPT IN STRICT CONFIDENCE.
MEMORY CONTENTS WILL BE WIPED OFF AFTER YOU LEAVE,
SO, TELL ME ABOUT YOUR PROBLEMS.
The sound card took sound computation off the CPU as well. Back in the day, every aspect of the game was fighting for CPU cycles.
Way back in the day there were some very impressive (given the technology) arcade ports to things like the Apple ][. That system's audio required running an assembly function that literally touched a memory address over and over again at a specific time rate; each touch flipped the electromagnet on the speaker. So games with theme music had to time slice hanging out in the audio routine versus doing anything else.
I grew up with a copy of Moon Patrol on Apple ][c and I didn't know for years that the theme song isn't supposed to sound like it's being played through a tea kettle.
I think it's because adding a sound card offloaded sound processing from the CPU and it had more cycles to draw frames! Probably back when we were at like 25Mhz
CPUs from that era were single core and pretty slow. They had to do everything like game logic, graphics, sound, etc all at once, so it was often resource starved. Sound took some resources, sometimes significant depending on the sound and what else the cpu was doing, unless it was a really simple sound (think NES style sound). Moving that to a dedicated sound card meant the cpu didn't have to worry about sound anymore.
Sound, like a lot of things, could be seen as a peripheral and a lot of peripherals back then needed their own cpu to perform well. One interesting fact I recently learned is the commodore 64 was so resource starved, the external floppy drive you could buy had its own 6502, just like the C64 did as its main processor. It just had to off-load that to another cpu because its own cpu was too busy to reliably run a disk drive. There are other reasons for this like commodore's experience in drives previously was this kind of architecture so they went with what they knew, but its a bit interesting to know your floppy drive was essentially another C64 with its own commodore OS and ram and 6502.
Off-loads sample mixing to the sound card. Computers of that era were slow enough that doing 44100 additions per second was expensive (IIRC quake had 8Khz samples anyway).
Something that always seems to surprise me when I remember it today: Playing an MP3 on my Pentium CPU in 1996 worked, but it _really_ brought the system to its knees. I could choose between listening to MP3 music or interacting with some other program (mIRC, Netscape, etc) but certainly not both.
I'm interested in hearing more
In the first waves of multimedia PCs - the CPU was tasked with doing sound, networking, hard drive control, etc. - pretty much all of the cost savings came from having minimal hardware for the auxiliary components and doing it all in drivers.
A common "Trick" was to buy cards that had essentially their own processors to handle this stuff - SoundBlasters, 3Com nics, IDE drive controllers that had their own processor (hell, even up to their own OS) since that freed the CPU up for doing actual work - gaming. Even an external or other
CPUs were a bottle neck but most people didnt tax the single core machines doing most daily work (office work, browsing the web) so it was fine, but once you load up a game that needs sound, 3d, networking, disk access all at once it would start stealing clock cycles trying to do all of that in one place.
SOUNDBLASTER 2.0 !!!!!!
A 16(!!!) bit ISA slot card, which revolutionized PC-audio-experience.
Are they still on the market or crashed by the ever-more-increasing onboard chips?
And there was Gravis Ultrasound, where you could upload samples into the RAM of the soundboard (that was like superpowermegatech back at these days :-) IIRC, the highest degree of fidelity was fu**ng 16 MB of onboard RAM on the soundboard.
:-D
9 replies →
> had essentially their own processors to handle this stuff
Most of the benefit came from the sound card doing DMA from a memory buffer instead of using a high-frequency interrupt to have the CPU give it sound samples one or two bytes at a time (fetched from the very same memory buffer(s)).
More sophisticated cards could also do mixing of several sounds in "hardware" (usually by having their own little CPU do the work) instead of having the main CPU doing the mixing. Some of them could even play the constituent sounds at different speeds (Gravis Ultra Sound and Midi cards but the Midi cards usually had fixed sound samples). This mattered for more sophisticated game audio for a few years until x86 performance improvements made it irrelevant. DMA is still crucial.
I vividly remember playing around on a friend's 486 that had a scsi controller for the hard drives, that was the best 486 I ever used! It's been all win modems and liquid glass window borders since then!
what’s old is new: check out dpus
Reading this brought back memories of the odd intonation of that text to speech engine. “Striiict confidence”
1 reply →
The sound card took sound computation off the CPU as well. Back in the day, every aspect of the game was fighting for CPU cycles.
Way back in the day there were some very impressive (given the technology) arcade ports to things like the Apple ][. That system's audio required running an assembly function that literally touched a memory address over and over again at a specific time rate; each touch flipped the electromagnet on the speaker. So games with theme music had to time slice hanging out in the audio routine versus doing anything else.
I grew up with a copy of Moon Patrol on Apple ][c and I didn't know for years that the theme song isn't supposed to sound like it's being played through a tea kettle.
I think it's because adding a sound card offloaded sound processing from the CPU and it had more cycles to draw frames! Probably back when we were at like 25Mhz
CPUs from that era were single core and pretty slow. They had to do everything like game logic, graphics, sound, etc all at once, so it was often resource starved. Sound took some resources, sometimes significant depending on the sound and what else the cpu was doing, unless it was a really simple sound (think NES style sound). Moving that to a dedicated sound card meant the cpu didn't have to worry about sound anymore.
Sound, like a lot of things, could be seen as a peripheral and a lot of peripherals back then needed their own cpu to perform well. One interesting fact I recently learned is the commodore 64 was so resource starved, the external floppy drive you could buy had its own 6502, just like the C64 did as its main processor. It just had to off-load that to another cpu because its own cpu was too busy to reliably run a disk drive. There are other reasons for this like commodore's experience in drives previously was this kind of architecture so they went with what they knew, but its a bit interesting to know your floppy drive was essentially another C64 with its own commodore OS and ram and 6502.
So was Waterluvian, I assume, which is probably why they added the card!
Off-loads sample mixing to the sound card. Computers of that era were slow enough that doing 44100 additions per second was expensive (IIRC quake had 8Khz samples anyway).
Something that always seems to surprise me when I remember it today: Playing an MP3 on my Pentium CPU in 1996 worked, but it _really_ brought the system to its knees. I could choose between listening to MP3 music or interacting with some other program (mIRC, Netscape, etc) but certainly not both.
6 replies →
[dead]
“I just need to find another 12K of conventional memory to launch this game…”