This present a demo program that plays a specific WAV file (to avoid introducing a RIFF parser to the already too-long-for-SO code.
The program has been tested in DOSBox, but a lot of things can go wrong on different configurations.
Finally, I was forced to split the code into two answers.
This is part 1.
Though the question may classify as off-topic1 I believe it could be a precious resource to have on this site.
So I'm attempting to respond it.
A few notes on the environment:
I've used TASM as the assembler,
there is no particular reason behind this choice but childhood memories.
The code should be compatible with MASM.
I'm using DOSBox to emulate a DOS environment.
DOSBox ships with a preconfigured SoundBlaster 16 card.
TASM can be run under DOSBox without any problem.
A scanned version of the TASM 5 manual2 is
available online.
Though no uncommon syntax has been used, being unfamiliar with the assembler directives makes any code harder to read and understand.
The TASM 5 pack is available online.
Assembling, general source format and debugging
As a matter of convenience, the code developed for this answer can be found on GitHub.
The binary format is the MZ executable with memory model SMALL, one data segment named _DATI3 and one
code segment named _CODE.
Each segment is defined multiple times for convenience4, both segments are PUBLIC so all these different definitions are merged together by the linker, resulting
in just two segments5.
The sources target the 8086 as per OP request.
The sources use conditional macro and symbolic values6 in order to be configurable, only three values need to be adjusted eventually.
The default values match the default configuration of DOSBox.
We will see the configuration soon.
Due to the not elementary nature of this task, debugging is essential.
To facilitate it, TASM and TLINK can be instructed to generate, and include, debugging symbols.
Coupled with the use of TD debugging is greatly simplified.
Assemble the sources with
tasm /zi sb16.asm
tlink /v sb16.obj
to generates full debugging symbols.
Use td sb16 to debug the program.
Some notes on debugging:
- Sometimes DOSBox crashes.
- During debugging the DOS environment can be corrupted if the program acts incorrectly or is terminated earlier. Be ready to restart DOSBox often.
- Place an
int 03h (opcode CC) instruction where you want TD to break. This is handy to debug the ISR.
Soundcard configuration
The SoundBlaster 16 (SB16) had a simple DSP that when filled with
digital samples converted them into an analogue output.
To read the samples the card took advantage of a special transfer mode called Direct Memory Access (DMA), the chip that handled
such transfers was capable of handling 4x2 in flight data movements.
The SB16 had a jumper, or a switch, to configure the channel to use to read the samplings.
When a block of sampling was over the card requested the attention of the CPU through an interrupt,
the chip handling the interrupts had 8x2 request lines.
The SB16 had another jumper to select the Interrupt ReQuest line (IRQ) to use.
Finally, as every legacy device, the SB16 was mapped in the IO address space where it occupied sixteen
continuous bytes.
The starting address, a.k.a. base address, of this block was configurable too. A part was fixed and a part was variable, the base address
had a form of 2x0h where x was configurable.
All these options are reflected in the DOSBox configuration file.
The program given has been tested with these options7:
[sblaster]
sbtype=sb16
sbbase=220
irq=7
dma=1
hdma=5
sbmixer=true
oplmode=auto
oplemu=default
oplrate=44100
Sources configuration
Though this is a premature introduction to the sources, it is handy to present the configuration constants now that we have just seen the DOSBox configurations.
In the file cfg.asm there are these constants
;IO Base
SB16_BASE EQU 220h
;16-bit DMA channel (must be between 5-7)
SB16_HDMA EQU 5
;IRQ Number
SB16_IRQ EQU 7
The values here must reflect the ones present in the DOSBox config file.
Every other constant defined in the file is for the use of the program and not intended to be modified unless you know what you are doing8.
The cfg.asm has nothing else of interest and won't be discussed again.
How to play samples
After a long introduction, we are now ready to see how to play a buffer of samples.
A very good and synthetic reference is [available here]tutorial/documentation on the SB16 here.
This answer is basically an implementation of what is written there, with some verbose explanation.
These are the step we will follow:
To playback a buffer of samples the step requested are:
- Allocate a buffer that does not cross a 64k physical page boundary
- Install an interrupt service routine
- Program the DMA controller for background transfer
- Set the sampling rate
- Write the I/O command to the DSP
- Write the I/O transfer mode to the DSP
- Write the block size to the DSP (Low byte/high byte)
The goal is to play this WAV file of a Super Mario Bros coin.
Sources organization
There are seven files:
sb16.asm is the main file that includes the others.
It performs the steps above.cfg.asm contains the configuration constants. buffer.asm contains the routines for allocating the samples buffer. data.asm contains the routines that fill the buffer.
This is the file to edit to adapt the source to other goals. isr.asm contains the routines that set the ISR and the ISR itself. dma.asm contains the routines that program the DMA. dsp.asm contains the routines that program the DSP.
In general, the files are short.
The sample buffer
The high-level process is as follow: the card is given a buffer to read, when done it triggers an interrupt and stops; the software then update the buffer and restart the playback.
The drawback with this method is that it introduces pauses in the playback that present themselves as audible "clicks".
The DMA and the DSP support a mode called auto-initialize where, when the end of the buffer is reached, the transfer and the playback start over from
the start.
This is good for a cyclic static buffer but won't help for an ever-updating buffer.
The trick is to program the DMA to transfer a block twice as large as the block the DSP is programmed to read. This will make the card generate an interrupt at the middle of the buffer.
The software will then resume the playback immediately and then update the half just read. This is explained in the diagram below.
How big should the buffer be?
I have chose a size of 1/100 sec at 44100 samples per second, mono, 16-bit per sample. This is 441 samples times 1 audio channel times 2 bytes per sample.
This is the block size. Since we have two blocks, the buffer size should be twice as much.
In practice, it is four times as much (in the end, it is about 3.5 KiB).
The big problem with the buffer is that it must not cross a physical 64KiB boundary9.
Note that this is not the same as not crossing a 64KiB logical boundary (which is impossible without changing segment).
I couldn't find a suitable allocation routine in the Ralf Brown Interrupt List, so I proceeded by abstracting the behaviour in
two routines.
AllocateBuffer that must set the variables bufferOffset and bufferSegment with the far pointer to the allocated buffer of size at least BLOCK_SIZE * 2.
Upon return, if CF it means the procedure failed.FreeBufferIfAllocated that is called to free the buffer. It is up to this procedure to check if a buffer was effectively allocated or not.
The default implementation statically allocates in the data segment a buffer that is twice as needed, as said.
My reasoning was that if this unmoveable buffer crosses a 64KiB boundary than it is split into two halves, L and H, and it is true that L + H = BLOCK_SIZE * 2 * 2.
Since the worst case scenario is when L = H, i.e. the buffer is split in the middle, the double size gives a size of BLOCK_SIZE * 2 * 2 / 2 = BLOCK_SIZE * 2 in the worst case scenario for both L and H.
This guarantees us that we can always find a half as large as BLOCK_SIZE * 2, which is what we needed.
The AllocateBuffer just find an appropriate half and set the value of the far pointer mentioned above. FreeBufferIfAllocated does nothing.
Note that by "buffer" I mean two "blocks" and a "block" is the unit of playback.
What format should the buffer use?
To keep the things simple, the DSP is programmed to playback 16-bit mono samplings.
However, the procedures that fill the blocks have been abstracted into data.asm.
