26

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?

Improve this question
6
  • 3
    From what I recall, all a DOS program needs or gets is the address of the SoundBlaster, its IRQ line, and a DMA channel. The rest is up to it. But I never programmed a sound card, so take that with a pinch of salt. Compare with printer drivers, which were also supplied by application programs. – another-dave Dec 30 '20 at 23:20
  • 4
    A driver is something that knows how to talk to the hardware on the card. The official soundblaster software read the configuration from an environment variable, so many other soundblaster drivers for games supported it too to avoid a configuration step. This in turn prompted other sound card vendors wanting to be soundblaster compatible to do the same. – Thorbjørn Ravn Andersen Dec 31 '20 at 11:28
  • My experience is pretty much limited to an AWE-64, and I think there was a TSR although I don't know what the API was like. ISA PnP devices did something odd using- I think- one of the printer port addresses to expose their configuration, but this is not something I ever fiddled with directly. – Mark Morgan Lloyd Dec 31 '20 at 12:30
  • 3
    I wonder what you imagine a driver to be :) The difference between DOS and Windows is in the abstraction - on DOS, if you cared about performance or capability, you talked directly to the hardware (using IO ports, interrupts and memory access). On Windows, this is still done - just by the driver. There were sound libraries on DOS that abstracted access to the hardware - these were pretty much the same thing you would call "drivers". Funnily enough, on 32-bit Windows, most of the DOS software still works - Windows intercepts the accesses and redirects them to the appropriate drivers. – Luaan Dec 31 '20 at 12:38
  • 2
    Bear in mind that DOS did not even have an interrupt driven serial interface driver. The BIOS just contained a very simple, polled, interface. Every application was responsible for finding out where the port was and hooking the appropriate interrupt. – JavaLatte Jan 1 at 9:26
5

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 presense of the expected device (fx setting up the on-board timers on the AdLib card) and ran it blindly against the conventional or specified I/O addresses and saw what dropped out of the sky.

Improve this answer
1
  • So, again, there is no "driver". The game (or any program) talks directly to the driver using DMA and I/O ports. That's what I assumed and wanted clarification for. – Dercsár Jan 2 at 19:46
22

Summary:

  1. Real Sound Blasters don't need a driver to initialise or support them. Clones may need one-time initialisation. Exotic cards may need memory-resident translation layers.

  2. Games use a collection of per-card drivers to 'talk' to the appropriate hardware interfaces. These can be hard-coded into the game, or a collection of external files like in HMI or Miles.

Depending on your situation, one or both of these may apply.

To play Halloween Harry on a real Sound Blaster, no extra files are needed. The SB support is hard-coded.

To play Theme Hospital on a SB Live PCI under MS-DOS, the game uses a third-party Miles driver to abstract the SB card. The card itself requires a Live driver to imitate the hardware interface of an older SB card.

All the answers given here so far are correct, for different scenarios. What may confuse 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.

1) Initialisation and support to -provide- the interface

Legitimate, first-party Sound Blaster series of cards are programmed directly through I/O ports. There's a chip on-board known as the 'DSP'* which handles all the data movement to and from the card. If you have a real Sound Blaster, and the game knows how to 'talk Sound Blaster' to the DSP using the interface described in the Sound Blaster Series Hardware Programming Guide then that's all that's needed.

*(Not to be confused with a 'DSP' in later usage which typically provides a programmable effect like reverb.)

If you have a clone card or a third-party 'compatible card', then one of the following applies:

  • The clone card exactly acts as one of the Sound Blaster series cards and no further intervention by a 'driver' is necessary.
  • The card starts off 'inert' and requires some initialisation. This is common with 1995-1997 PnP compatible cards whose IRQ and DMA settings are done in software rather than by jumpers. My Avance ALS100+ based card and CMI8330 cards require a start-up program to be run before they will work. This program talks to the card, tells it what IRQ and DMA to use, and from that point onwards the card acts as a clone card. No persistent program resides in memory to translate a game's Sound Blaster DSP commands into Avance commands, etc. If you've installed the 'driver' for a clone-like card, this most likely applies to you.
  • If the card is not capable of directly acting as a clone card because it is exotic like a Gravis Ultrasound, or a very new (relatively speaking: post 1996) Sound Blaster / Ensoniq PCI card, then it cannot be simply initialised into acting as an SB clone card. These cards require a software shim layer to be loaded resident to intercept Sound Blaster DSP commands and translate them in real time to commands the card understands. For the GUS, this is SBOS. If the game you're playing natively supports GUS, then you don't need SBOS. For cards without FM chips/clone chips present, the shim layer may synthesize the audio in software in real-time, with mixed results.

2) Game support to -consume- the interface

Completely independently of the above, is the 'driver' that provides the game's ability to talk to a specific sound card. This could be more precisely called an audio library, but since it also has to talk to the Sound Blaster / Windows Sound System etc DSP processors, it's also a driver. In this respect, a DOS game is sort of like a mini-operating-system into itself.

This driver takes the form of a library of routines that abstract the base primitives of the sound card interface into a useful, consistent set of commands for game developer.

By itself, a Sound Blaster provides a single output stream of audio and FM capability. A Gravis Ultrasound or SB AWE provides a wavetable interface to multiple short looping streams of sound-card-RAM-resident samples (in addition to the SB digitised stream and FM, for the AWE). The PC speaker goes beep.

The game programmer doesn't want to think about this level of detail - they want to start music, play an explosion, etc. It would be the driver's job to abstract these details: begin/stop output, start/stop sound effects, mix them, alter volumes, etc.

Early games would have these drivers coded directly into the game in a sort of ad-hoc fashion - Halloween Harry can only support original Sound Blasters, and the support is hard-coded into the game. 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 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.

The sound card drivers in 1) would be provided on an installation disk with your sound card, if required.

The sound card drivers in 2) would be provided with or part of the games themselves.

Improve this answer
11
  • Sound Blaster did need a driver, but it was built into each program. – chrylis -cautiouslyoptimistic- Dec 31 '20 at 20:27
  • 2
    @chrylis-cautiouslyoptimistic- That's not really the same thing. You could argue that in DOS, the Adlib & SB register set was the API for sound output. A driver would be a layer that sits between the API and the hardware. – Chromatix Dec 31 '20 at 21:59
  • 1
    @Chromatix Or, alternatively, you could say that a driver is some code specific to a given hardware interface that abstracts differences between different hardware away from the API the application is coded for. – ssokolow Dec 31 '20 at 23:31
  • 1
    "By itself, a Sound Blaster provides a single output stream of audio.", it also provides adlib-compatible FM synthesis chips. IIRC many DOS games used the digital audio for sound effects and the FM synthesis chips for music. – Peter Green Jan 1 at 2:32
  • 1
    Thanks for your efforts to explain this. I find it strange to call a piece of code coming the application 'driver'. I would call it 'library'. But that's just my preference. – Dercsár Jan 2 at 19:51
16

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.

Improve this answer
2
  • IIRC, Sound Blaster Live! required launching its sw to emulate opl3, which it didn't really had on board. And it did use emm386 for ports trapping. – Vlad Dec 31 '20 at 10:05
  • @Vlad SB Live was a PCI card, wasn't it? That seems to support my argument. – Chromatix Dec 31 '20 at 21:54
4

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.

Improve this answer
1
  • What I meant with this idea is that the sound card does not work at all right after boot-up. Unlike early SB products that default to port 220h, irq 5, etc. Later clone cards were 'deaf' on power-up and needed special operations to set DMA, IRQ and other values that they would work with -- until power-off or restart. What you describe is the actual using of a sound card, including starting and stoping sound or setting modes of operation (8 or 16 bits, FM or wave or MIDI, etc.) Is that correct? – Dercsár Jan 2 at 19:41
1

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.

Improve this answer
2
  • That's new to me :) This 'blob of code' is what @knol above refers to as 2nd type, right? I wouldn't call it a driver, but it's really just a word. If I am not mistaken, that code should be part of the application, not the system. Maybe it was just a sample or demonstration program for better understanding, aimed at programmers. – Dercsár Jan 2 at 19:31
  • If memory serves, Creative Labs referred to the blob in their documentation as a "driver", though elsewhere such a thing might have been called a "library". Since what CL supplied doesn't really fit either description, I think the term "blob of code" seems appropriate. I don't think CL gave much thought to whether it should be part of the application or the system; I don't remember whether the SB itself came with a copy of the blob in question. – supercat Jan 3 at 6:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.