What a nightmare it was to have sound AND your CD drive drivers to load and leave enough memory for some of those nasty old DOS games.
Felt like being a hacker.
(I might have realized I’m the old guy in the picture)
I built a config.sys file with a menu that then passed the menu choice on to autoexec.bat so I could choose at boot time between 3 configurations- one with expanded memory for older games that required it, one with extended memory for everyday use and newer games, and one with everything extra (including CD-ROM drivers) stripped away to maximize free conventional RAM for the one or two games that needed that…
I know that was a thing and I tried to get it done, but never managed to get it to work properly.
So back to manual configuration and rebooting it was.
But I like to think that’s how I learned how my PC works and what it does when doing so, which helped me identify the cause of many issues over the years.
Sound typically (*) didn’t require “drivers” or any TSR though. The game had to do all the hardware control itself.
It was usually enough to set a BLASTER variable to point it at the correct IRQ, DMA and memory address, and perhaps run a program at boot to initialize the card and set volume levels, but no TSR eating up memory.
(*) Some exceptions are later soundcards of the Win 9x era that did crappy emulation of a real Soundblaster via a TSR in DOS.
Speaking of memory, I had a weird 486 machine which had baked in 16MB of ram which were accessible through EMS and 16MB of replaceable RAM sticks accessible through XMS interface. The thing is EMS worked faster in DOS, but XMS worked faster in Windows 95. So when booting up into DOS, all the apps would use baked in EMS RAM, but when booting into Windows, all the apps would use XMS RAM.
What a nightmare it was to have sound AND your CD drive drivers to load and leave enough memory for some of those nasty old DOS games. Felt like being a hacker.
(I might have realized I’m the old guy in the picture)
And that dedicated sound cable for DVD CD drive to your soundblaster
Oh wow. I totally forgot about those.
And if that cable’s isolation was crap, you could hear your mouse movement through your speakers.
That also happened with the early onboard sound cards.
I built a config.sys file with a menu that then passed the menu choice on to autoexec.bat so I could choose at boot time between 3 configurations- one with expanded memory for older games that required it, one with extended memory for everyday use and newer games, and one with everything extra (including CD-ROM drivers) stripped away to maximize free conventional RAM for the one or two games that needed that…
How could you have a menu in config.sys?? I wasn’t aware that was even possible.
I don’t remember at this point… So I googled, this looks familiar: http://smallvoid.com/article/dos-multiple-configurations.html
That’s crazy. It’s like some ghetto DOS version of grub.
I know that was a thing and I tried to get it done, but never managed to get it to work properly. So back to manual configuration and rebooting it was.
But I like to think that’s how I learned how my PC works and what it does when doing so, which helped me identify the cause of many issues over the years.
Sound typically (*) didn’t require “drivers” or any TSR though. The game had to do all the hardware control itself.
It was usually enough to set a BLASTER variable to point it at the correct IRQ, DMA and memory address, and perhaps run a program at boot to initialize the card and set volume levels, but no TSR eating up memory.
(*) Some exceptions are later soundcards of the Win 9x era that did crappy emulation of a real Soundblaster via a TSR in DOS.
Speaking of memory, I had a weird 486 machine which had baked in 16MB of ram which were accessible through EMS and 16MB of replaceable RAM sticks accessible through XMS interface. The thing is EMS worked faster in DOS, but XMS worked faster in Windows 95. So when booting up into DOS, all the apps would use baked in EMS RAM, but when booting into Windows, all the apps would use XMS RAM.