The DOSEMU Alterer Novices Guide
PrevNext

14. The Sound group of Modules

The sound code provides emulation of the SB. The actual emulation provided depends upon the support available from the kernel sound driver. Because this is very OS dependant the driver code itself is kept in architecture specifc files under src/arch/osname/dosext/sound/. Communication is via a set of interface functions and the device independant structures.

14.1. Functions in dosext/sound/sound.c

These are the functions defined in dosext/sound/sound.c.

14.1.1. sb_io_read

Arguments are:

  • port - The I/O port being read from.

This handles all of the reads for the SB emulation. The value read is returned. The value of 0xFF indicates an invalid read. (assumes the ports float high when not pulled low by the hardware.)

14.1.2. adlib_io_read

Arguments are:

  • port - The I/O port being read from.

This handles all of the reads for the adlib (FM) emulation. The value read is returned. The value of 0xFF indicates an invalid read. (assumes the ports float high when not pulled low by the hardware.) The FM emulation is not written yet. The current plan is to use the midi emulation where available as this is the most common use for the FM sound.

14.1.3. mpu401_io_read

Arguments are:

  • port - The I/O port being read from.

The MPU-401 functionality is primarily provided by 'midid' - a standalone program. This makes most of the MPU-401 code simply a pass-through driver.

14.1.4. sb_io_write

Arguments are:

  • port - The I/O port being written to.

  • value - The value being output.

This handles the writes for the SB emulation. Very little of the processing is performed in this function as it basically consists of a very large switch() statement. The processing here is limited to trivial (1 line) items and distinguishing between the different actions and responses that the different revisions of the SB series give.

14.1.5. sb_dsp_write

Arguments are:

  • value - The value being written to the DSP.

The SB DSP is a complete I/O system in itself controlled via a number of data bytes. The number of bytes depends upon the function. The function to be executed is determined by the first byte. If there is no existing command then the command is stored. This then used in the switch to identify the action to be taken. When the command has supplied all of its arguments, or failed, then the command storage is cleared. Each DSP function is responsible for clearing this itself. Again, this function relies on other functions to do the real work, and apart from storing details of the command and parameters is basically a large switch statement.

14.2. Remarks in dosext/sound/sound.c

Write silence could probably be implemented by setting up a "DMA" transfer from /dev/null - AM

14.3. Items for Fixing in dosext/sound/sound.c

The file header needs tidying up a _LOT_ ! */

-----

Adlib status reads are unimplemented */

-----

Advanced adlib reads are unimplemented */

-----

CMS Writes are unimplemented.

-----

DSP Status is unimplemented

-----

Adlib Waveform tests are unimplemented */

-----

Advanced Adlib register writes are unimplemented */

-----

Advanced Adlib data writes are unimplemented */

-----

SB Midi is Unimplemented

-----

Sine Generation is unimplemented

-----

AUX Status is Unimplemented

14.4. Remarks in base/dev/dma/dma.c

**** WARNING **** This Code _HAS_ changed.

-----

The Emulated DMA channels are provided by using files and writes. This means that they are easy to track. It might cause problems when attempting to interface to the REAL DMA controller. (Necessary to talk to hardware which uses DMA.)

Note that DMA controller 2 uses word granular addressing and controller 1 uses byte granular address ... this simplifies the code !

14.5. Items for Fixing in base/dev/dma/dma.c

: Cascade Mode Reads are not supported

-----

: The Verify Mode is not supported

-----

: The Invalid Mode is not supported (!)

PrevHomeNext
The PIC group of Modules The FileAccess group of Modules