Next
Previous
Contents
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.
Maintainers
Alistair MacDonald
<alistair@slitesys.demon.co.uk>
David Brauman
<crisk@netvision.net.il>
Rutger Nijlunsing
<rutger@null.net>
Functions in dosext/sound/sound.c
These are the functions defined in dosext/sound/sound.c.
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.)
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.
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.
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.
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.
Remarks in dosext/sound/sound.c
Write silence could probably be implemented by setting up a
"DMA" transfer from /dev/null - AM
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
-----
Write Silence is not implemented.
-----
Adlib register writes are unimplemented
-----
Adlib data writes 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
-----
Stero Input is no implemented
-----
ADC is Unimplemented
-----
Stopping Auto-Init DMA is not implemented
Next
Previous
Contents