MMPM/2 Device Driver Reference:MAD16 PDD and VDD Sample Device Drivers

=MAD16 PDD and VDD Sample Device Drivers (Watcom C)= The Developer Connection Device Driver Source Kit for OS/2 includes a PDD/VDD pair that program the OPTi/MediaChips 82C928/82C929 Audio Controller (MAD16). The MAD16 is an integrated digital audio controller for PC sound applications.

Beyond its use for multimedia device developers, the sample provides a reference for using Watcom 16 and 32-bit C compilers for OS/2 device driver development.

The device drivers are located on the CD-ROM in the multimedia section.
 * PDD \ddkx86\mmos2\samples\mad16
 * VDD \ddkx86\mmos2\samples\vmad16

Board Architecture
The reference design for the MAD16 includes the following primary parts: The MAD16-based board can support applications and device drivers written to a variety of CD-ROM, audio and MIDI interfaces.

MAD16.ADD Device Driver Overview
All device configuration is performed through software programmable settings. Base I/O address and DMA and IRQ selections for CD-ROM and audio are initialized from software through the MAD16.ADD device driver. There are no jumpers.

Once enabled, existing device drivers can be used to perform audio and CD- ROM actions. For example, existing AD1848 business audio device drivers can be used on configurations with the AD1848. Existing CS4231 device drivers can be used in board configurations that have the CS4231 device. Likewise, the MAD16 device can be set to enable Sony31A, Mitsumi, Panasonic or IDE CD -ROM interfaces. An appropriate CD-ROM device driver is loaded later to perform CD-ROM activities.

The job of the MAD16.ADD is to initialize the device.

Boot Sequence
To initialize the device before the other device drivers load, the MAD16.ADD device driver has to load before the other device drivers (Audio/CD-ROM). OS/2 loads device drivers in a specific order. Device drivers needed to boot the system are loaded early. Less critical device drivers including audio are loaded toward the end of the device driver load sequence. In a particular class of device drivers, load order is based on order in the CONFIG.SYS.

Device driver load order is as follows: To load early, the MAD16.ADD wakeup code is written as a BASEDEV.ADD. This insures that regardless of CONFIG.SYS order, it loads early. For CD-ROM however, both the wakeup code and CD-ROM device driver are .ADDs. This creates an install requirement that the MAD16.ADD precede the CD-ROM device driver in CONFIG.SYS.
 * 1) Kernel known basedevs (resource manager)
 * 2) BASEDEVs
 * a) .ADDs first
 * b) .SYS
 * 1) Non-BASEDEVs (for example, Audio)

PDD Operation and Architecture
The MAD16.ADD does most of its work during initialization. Device modes and settings are read from a persistent database (CONFIG.SYS). The MAD16 device is programmed to set the base address of all the other parts on the board. For CD-ROM, turning the device on is all that is required. For audio, an initialization sequence is required to bring the audio Codec and MAD16 to a state where both Windows Sound System and Sound Blaster applications can be supported.

Using Watcom 16-bit C, the MAD16.ADD device driver has very little assembler code. The strategy routine is executed with no assembler stub. Watcom provides "pragma aux";, which allows the programmer to specify that parameters arrive in registers rather than on the stack. With this, much of the stub code popular in C device drivers is unnecessary.

VDD Operation and Architecture
Because all audio operations are performed by the audio CODEC, only one audio mode can be active at one time. The device is not capable of performing two concurrent wave audio play operations.

At initialization, one mode must be selected. By convention, the Windows Sound System mode is the default because this support is used by MMPM/2 and WinOS2 for wave audio operations.

Because OS/2 and WinOS2 audio are controlled by the audio CODEC PDD, DRV, and VDD, the VMAD16 VDD must communicate with the other drivers to negotiate use of the audio device.

Audio operations are performed using existing audio device drivers. Sound Blaster games are supported in a virtual DOS machine through a OS/2 Virtual Device Driver (VMAD16).

The figure below illustrates the architecture. +--+ +--+  +--+ +---+ +---+  |QMAD16.exe|  |MMPM/2    |  |WinOS2    | |DOS Session| |DOS Session| |Diagnostic| |MME subsys|  |MME subsys| |WSS App    | |SB App     | +--+ +--+  |--| +---+ +---+       |             |        |Audio.DRV |      |             | | Ring-3     |        +--+      |             | -|-|--|---|-|---      | Ring-0      |              | +-+             | +-+    +-+     +-+            +-+  |MAD16.ADD|     |Audio PDD|-|AudioVDD |            | VMAD16  | +-+    +-+     +-+            +-+        |               +--+  |        +-+ When a Sound Blaster specific application, such as a game, programs the device from a Virtual DOS machine, the VMAD16.SYS VDD intercepts the first port I/O and takes this as a request to use the audio hardware. It communicates with the audio CODEC PDD to gain ownership. Once ownership is attained, the VMAD16 VDD sends a command to the MAD16.ADD wakeup code commanding it to switch the device from Windows Sound System mode into Sound Blaster mode.

When the owning DOS application terminates, the VDD commands a switch back to Windows Sound System mode and returns device ownership to the audio CODEC PDD.

The following table describes the VMAD16.SYS source code.