Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
To my knowledge, neither MS-DOS nor BIOS offers any kind of API for sound cards. Therefore the concept of a "driver" is absent, as we know it today. Apart from accessories and sample files and Windows-related stuff found in the setup package, what is the essentials needed for a DOS-program to use a sound card?
One thing I've read somewhere and cannot find anymore is that some sound cards are 'inactive' at power-up and need some sort of initialization to work. Can you please comment on this?
The typical way to provide "driver" services to other programs in DOS is to run a TSR (Terminate and Stay Resident) program installing a software interrupt vector such that running DOS programs could invoke this INT for services (see Ralph Brown's Interrupt List).
In the sound context, however, programs would typically do the device I/O directly by reading and writing I/O ports directly, handling interrupts and DMA transfers when relevant. Maybe due, in part at least, to the fact that multimedia services were rapidly evolving.
With no resource management provided by DOS, you would have to detect devices manually which could be a bit tricky and potentially trigger crashes depending on what happened to be installed in the I/O space. It is possible that some devices only monitored a minimal I/O footprint until an init sequence was performed to reduce this risk, but this is not behaviour I recognize from the sound routines I wrote myself for AdLib, Roland MPU-401 MIDI and classic SoundBlaster cards.
Mainly, detection was based on conventional I/O, IRQ and DMA allocations supplemented by environment variable conventions specifying these configuration points.
You basically wrote a piece of code that should only give a certain result in the presence of the expected device (fx setting up the on-board timers on the AdLib card), ran it blindly against the conventional or specified I/O addresses and saw what dropped out of the sky.
Summary:
Real ISA Sound Blaster cards don't need any drivers to initialise or support them. Later PNP Sound Blasters (SB16/AWE) and clones may need a driver that performs one-time initialisation. Exotic cards may need memory-resident translation layers.
Games use a collection of per-card drivers to talk to the appropriate hardware interface of the sound card, such as one of the Sound Blaster interface tiers, or the Gravis Ultrasound wavetable. These drivers can be hard-coded into the game, or stored as a collection of external files like in HMI or Miles.
Depending on the game and card you have, one or both of these may apply:
To play Halloween Harry on a real Sound Blaster ISA card, no extra drivers are needed in autoexec.bat. The SB support is hard-coded in the game.
To play Theme Hospital on a SB Live! PCI under MS-DOS, two different kinds of drivers are used. The SB Live! PCI itself requires a Creative resident MS-DOS driver to imitate the hardware interface of an MS-DOS-era SB16 card. The game itself uses a third-party Miles driver to abstract the Sound Blaster (or Pro Audio Spectrum, Windows Sound System, Wavjammer...) card for the game's use - this is what you select when you pick Sound Blaster 16 on the setup screen.
Detail:
All the other answers given here so far are correct, for different scenarios. What may confuse the reader is that there are two distinct phases that both could correctly be called 'drivers'. Let me describe what I mean:
Pretty much everything here applies to both digitised audio output and AdLib/OPL2/OPL3 support equally, but I'll focus on digitised audio.
1) Initialisation and support to -provide- the hardware interface
Legitimate, first-party Sound Blaster series cards are programmed directly through I/O ports. There's a chip on-board known as the 'DSP'* which handles all the data movement between system memory (requested through a system DMA channel) and the card's DAC/ADC. If you have a real Sound Blaster card, and the game is hardcoded to 'talk Sound Blaster'** then that's all that's needed.
If you have a clone card, a third-party 'compatible card', or a later SB16/AWE card then one of the following applies:
SBEINIT.COM, which emulates an SB16 card in software, setting up a 'phantom' card at IRQ 2/5/7/10 which responds to the standard set of DSP commands and ISA bus behaviour.These drivers would come shipped with your sound card.
*(Not to be confused with a 'DSP' in other usage which provides programmable effects like reverb or echo.)
**(You can read about this in the Sound Blaster Series Hardware Programming Guide)
2) Game support to -consume- the hardware interface
Now that your sound card is ready to receive commands, the games have to know how to play sound through its hardware interface. In MS-DOS, every game ships with its own set of drivers to control the sound card hardware.
Each card has its own set of primitive capabilities and interfaces, such as streaming digitised audio output (Sound Blaster, Windows Sound System, etc.), FM synthesis (Adlib, Sound Blaster, GUS SBOS), wavetable hardware accelerated output (Gravis Ultrasound, SB AWE) and MIDI support. The sound card drivers included with the game interact with the motherboard and sound card hardware directly to abstract the capabilities of the sound card into a uniform interface for the game programmer.
Because digitised audio output, wavetable output, FM synthesis and MIDI playback are dissimilar in nature, the sound card drivers at this layer typically also take on the role of an audio library, providing useful functions such as sound effect playback and looping, sound mixing (with volume and panning support), and music playback/cueing. Tracker music and sound effect playback map onto the features of the Gravis Ultrasound directly, but to do this on a Sound Blaster requires a software mixer with a wavetable-like system in software to pitch and combine the channels.
Early games would have their sound card drivers coded directly into the game in a sort of ad-hoc fashion because the interface is so simple - Halloween Harry supports the original Sound Blaster card, and the support is hard-coded into the game. (Luckily, all SB series cards support the original Sound Blaster interface tier, so Harry works with these cards too.) Rise of the Triad has its own huge sound library; since RoTT is open source, you can see all of the different initialisation and support routines on Github.
For late, mature MS-DOS games like Theme Hospital, a commercial library like Miles or HMI is used. If you've seen a sound card set up screen with dozens of sound cards available, then they most likely use one of these libraries. I point this out since the different sound card drivers can be shown in a directory listing as .386 or .ovl or .hmi files. Epic MegaGames Jensen-library games like One Must Fall 2097 and Jazz Jackrabbit store their sound card drivers in MDRV---R.MUS files. These are good examples of a games which support both Gravis Ultrasound and Sound Blaster.
Most PCI soundcards do not have hardware support for games and other applications that expect a SoundBlaster or AdLib to be present. Older cards made a special effort to provide what's known as "register level compatibility", so they could be used with a wide range of existing games. By the time PCI arrived, Windows had become the PC operating system of choice, so compatibility with DOS games was less important at the hardware level.
The DOS "driver" for these newer cards is actually emulation software, which intercepts accesses to the I/O ports normally occupied by Adlib and SB hardware, and converts them into commands to the actual soundcard present. This may include performing audio synthesis and/or mixing in software.
Like any hardware, the hardware of a sound card needs to be “prepared for operation” after having powered up in an unconfigured state.
Usually this consists of writing certain values to certain hardware ports and/or memory addresses (after testing for the presence of said sound card). After this, the sound card is ready for operation.
In Windows or any other modern Operating Systems this is done by a driver upon booting the operating system and scanning for any hardware that’s present. In DOS this configuration is (usually) done by the game or application utilizing the sound card when it is started. Before the application starts, the hardware is not yet configured.
When the Sound Blaster was first introduced, the documented way to use the digitized audio features was to make use of a supplied blob of code which was supplied by Creative Labs. If memory serves, using this blob of code required reading it into RAM at a multiple-of-16 address, and invoke it with a normalized form of that address (offset zero of whatever segment it happened to start at). If memory serves, the MIDI interface was defined in terms of I/O port operations, and the documentation may have specified how code which was able to run fast enough could output individual samples to an I/O port without using DMA [which ended up being how many programs actually used the SoundBlaster], but I think Creative Labs' expectation was that people would use the supplied blob of code. I don't think it was clear, however, whether they expected that programmers would always put that blob in a file with a certain name in a certain place so as to allow it to be replaced with alternative implementations, or how much space they expected programmers to allocate for it.
