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.
The Sound Blaster 2.0 wasn't 16-bit. It could do a higher sample rate than 1.0 but it was still doing 8-bit audio in an 8-bit ISA slot. The Sound Blaster 16 was a separate product another year or two later.
They might be thinking of the Sound Blaster Pro or Pro 2 which were 16-bit ISA cards, although really they were basically still 8-bit ISA cards that only used the extra pins on the 16-bit connector to give you a few more choices for IRQ/DMA. My gut feel is that the Pro and Pro 2 were when the SB really hit the mainstream. A lot of people I knew had them at the time, at any rate.
> Are they still on the market or crashed by the ever-more-increasing onboard chips?
I don't think any major vendor has made ISA sound cards in almost 30 years. Discrete PCIe sound cards exist but I don't know who exactly their intended market is. Audio pros?
You can find old 90's ISA cards used on eBay and whatever. The more sought after types (e.g. SB Pro) may not be exactly cheap, though.
Also, for the retro PC market, there are hobbyist cards such as the PicoGUS. [1]
So, yes or no, depending on what you're asking for.
The thing is that Duke3d ran fast/sounded just fine even on a slow Pentium with a basic sound blaster. GUS was very useful in the 486 era, but it sounds like it was actually better to not use it with a faster computer in this case.
> 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.
Decompression in conjunction with primitive multi-tasking on MacOS and Windows. That remained an issue until Windows XP.
(Very small groups of) people used be in awe at LAN parties when I showed them how Linux could play an MP3 without stutters while copying large files across the network and browsing images.
Then it was time to play games and people were less impressed by me not being able to join any other game than Quake...
Winamp was perfectly fine by itself as I recall it. Even on a P100 without MMX which was what I rocked around 96-97. But as soon as you did anything else that involved any kind of IO, there would be skips and stutters.
Odd. I distinctly remember listening to music via Winamp, and updating my tsv-databases, while copying downloaded data (mostly e-books and music) from the local uni's internet saved to Zip 100 disks (and later Zip 250s on a Pentium II). Same for the ubiquitous LAN parties. One thing to add is that the read and written data were completely sequestered (i. e. on different drives); an early safety practice that became a habit a long time ago.
Just don't forget the versioning script needed on at least Linux. It's either that or build with the same older distro Godot uses, so you have a matching libstdc++ version. You can link with a newer stdlibc++ but you will need a linker versioning script that hides your impl from the dynamic linker so you don't get random ghosts in your machine.
Hi! Yes, you are right, thanks for pointing this out. It's something to keep in mind when distributing an extension for Linux. I have just updated the post with a note about it.
Reasonable, now we have to wait for the ban for under 18. And one hopeful day the complete ban and mass jailing of anyone who had anything to do with the big social media networks of today.
First we're going to kill anonymity because that's the only way you can enforce any of these age bans, that as you show completely miss the point that these companies are bad for everyone.
Atleast some EU countries have ”strong authentication” services, which work like Google login, except there’s a network of trusted providers - like banks or telecoms.
To get started, you need get an account at one of the providers by physically visiting their store or office and show your ID. With their account you can sign up to the services or other auth providers fully online. Auth providers use 2-factor auth (typically website username + phone app), but they also include physical sim cards or key generator devices…
Anyways, while it’s currently used to pass some required personal info to the other party (name, social security number), it could propbably be changed to send just one bit: adult true/false.
This goes well with JD Vance wanting to end US Dollars reserve currency status. Truly the robber barons can't just leave a shell, it has to be graveyard dead too.
I'm looking for brutal feedback for my game that I'm working on.
I'm working on a cozy voxel game with RPG and platforming elements. Still early days, so I'm still figuring things out. Players play on their own private instances. The world is very malleable as player instances are based on a "master tape" world that I maintain. After creation that fork is the players own, and they do whatever they want.
Hm that's strange. I have 300mbit here and the entire WASM blob is 30mb, it really should go through fast. It's hosted by Deno as a WebSocket proxy and file server.
I'm wondering if it's mostly the WASM setup itself (after transfer).
reply