Using EMS in QuickBASIC: Part 2

by Plasma (Jon Ρetrosky)

Welcome Back: A Brief Review

In part one, we set up a basic EMS interface with QuickBasic. We also created a sample program, which did nothing more than test the EMS routines and shuffle some memory around.

Note: If you missed part one, you should read it before continuing. It's available in the tutorials section at Phat Code. It's also published in issue #3 of the QB Chronicles.

Now we're going to get to the fun stuff: playing sounds stored in EMS!

Sound Blaster: Some More History

The Sound Blaster card (and every card compatible with it) supports two types of sound: FM synthesis sound and digitized sound.

Figure 2-1: FM synthesis sound

FM synthesis sound uses different parameters to control the sound, allowing the programmer to crudely "emulate" instruments. When you play a MIDI file in Windows (without a wavetable sound card), you are hearing FM synthesis. FM synthesis is used mainly for music, although it is sometimes used for sound effects.

Figure 2-2: Digitized sound

Digitized wave sound works by playing many sound "samples" each second, which produces sound. Any sound can be produced with a digitized wave, if the frequency (the number of samples/sec, aka "sampling rate") is high enough. This makes digitized sound a popular choice for speech and sound effects. The frequency usually ranges from 8,000 Hz to 44,100 Hz. Also, each sample can have an 8-bit or a 16-bit value. (Needless to say, a 16-bit sample is much more precise than an 8-bit sample.) When you play a WAV file from Windows, you are hearing digitized sound.

As you may have guessed, digitized sound has greater sound quality than FM synthesis. Besides that, FM synthesis is becoming outdated, and it tends to sound "cheesy" anyway. So we'll be using digitized sound in this tutorial.

So How Does EMS Help Us?

The main problem with digitized sound is that it takes up a lot of memory. One second of 16-bit stereo sound sampled at 44 KHz (that's 44,100 samples/sec, CD-quality) takes up 176K! However, most games can get by with 22 KHz sampling and 8-bit mono sound, which only takes 22 K/sec. That's still a lot, but it's easier to deal with.

Another reason DOS games use lower sampling rates and 8-bit sound is that most Sound Blaster clones are only compatible with earlier SB models (1, 2, or Pro) which don't support 16-bit sound (in DOS) or high sampling rates.

Even if we're using 22 KHz 8-bit mono sound, we're going to run out of memory quickly if we're limited to storing our sounds in the 640 K base memory. This is where EMS comes into play! With EMS, we have vast quantities of memory to store digitized sounds without wasting any base memory. We can even play back the sound directly from EMS without the need for a buffer in base memory.

Since this is an EMS tutorial and not a Sound Blaster tutorial, I'm not going to go into detail on the workings of the various Sound Blaster cards. We'll just use the basic functions that are compatible with all Sound Blaster cards. (But don't worry, I've got a mega Sound Blaster tutorial coming soon...)

Let's Get Started!

We will be using the EMS functions I presented in part 1 of this series. However, I'm not going to list them again; I will just add on to the code.

Note: You can find the complete source code for this tutorial in ems2.zip.

First, we'll need to define a few global variables and constants to store the sound settings and status.

Detecting and Resetting the Sound Blaster

Before we can use the Sound Blaster card, we need to check to make sure it is present and initialize it. In order to do this, we need to know the base address and DMA channel (8-bit) of the card. The base address ranges from 210h to 260h, and the DMA channel ranges from 0 to 3. Because the user can change these settings, you can't be absolutely sure what they are.

There are two ways to find out: Ask the user, or look at the "BLASTER" environment variable

The BLASTER environment variable is set in the user's AUTOEXEC.BAT file. This variable contains the sound card settings in a string like so:

Warning: This variable may not exist. Even if it does, it may not have the correct settings if the user or another program has tampered with it!

The only two settings we are interested with are "A", the base address, (220h in the example above) and "D", the DMA channel (1 in the example above).

If the BLASTER variable is not present, your only other option is to ask the user for the settings. If the user doesn't know, try 220h for the base address and 1 for the DMA channel (because these are the most common settings) and cross your fingers!

After we have the base address, we can determine the I/O register (aka port) addresses for the DSP chip on the sound card. The I/O registers are used to communicate with the DSP chip, which controls the sound card.

Before we can use the Sound Blaster, we need to reset the DSP chip. This is done by sending a "1" and a "0" to the reset register, then checking the read register for the value AAh. If the read register does not return AAh after 65,535 reads, then the base I/O address is either incorrect or no sound card is installed.

Since we also know the DMA channel, we can determine the channel-specific registers used to control DMA transfers: the page register, address register, and length register. (We will use different sets of registers depending on which DMA channel the sound card is using.)

The DMA controller also uses three general registers which are used no matter which DMA channel the sound card is using.

Before we do any DMA transfers, we should reset the DMA controller. This is done by setting the mask bit in the DMA mask register (channel + 4h), and then sending a "0" to the DMA clear register.

Below is the complete function to reset and initialize the Sound Blaster.

Enabling the Sound

Even after we have reset the Sound Blaster, we still won't hear any sound until the "speaker" is turned on. (That's Creative-speak for enabling the sound output.) This should only be done once at the beginning of your program, since it causes the speakers to "click". Before your program ends, it should also turn the "speaker" back off.

Loading Sounds into EMS

Once the Sound Blaster is all reset and initialized, we are ready to play some sounds! The only problem is, we don't have any sounds to play!

Figure 2-3: Four pages are allocated to each sound slot

The easiest way to get sounds is to load them in from WAV files. We'll designate a different "slot" for each sound when we load them. Using this method, we can load multiple sounds and play them back by telling our playback sub which slot to play.

Because DMA transfers can only handle 64K at a time, each sound will be limited to 64K in length. The sounds will also be limited to 22 KHz 8-bit so our routines will work on all Sound Blaster cards.

There is one more limitation: We can only play one sound at a time. This is because the Sound Blaster only has one digitized sound channel. However, we can use a priority-based sound system to improve this a bit.

If you remember from part one, each EMS page is 16K. So we'll allow each sound slot 4 pages (16 x 4 = 64K). This might waste a little memory, but it will be much more simpler than trying to dynamically allocate pages to each sound based on the sound's size!

So how does one load a wave file? Well, it's just like any other binary file! The only thing we have to be concerned with is making sure that the sound is 8-bit, 23 KHz or less, and 64K or less in length. Luckily, all this information is stored in a "header" in the wave file.

The only problem left is the question of getting the actual wave data into EMS. We could read the data directly from the file into EMS (if the correct pages were mapped to the page frame). However, this would require use to use DOS interrupts for file transfers, which can get messy. But don't worry, there's another way!

We can create a small buffer (1K or so) in base memory. Then QuickBasic can read the file 1K at a time and put that into the buffer (which is actually a 1K string variable). From there, we can use our EMS.CopyMem routine from part 1 to copy the data from the buffer to a logical page EMS. Then the program just loops around and gets another 1K until the whole file has been loaded.

After the sound has been loaded into EMS, we'll need to save the frequency and length of the sound so we can play it back later. We'll also save the sound's priority (more on this later). We can use the shared SB.SlotInfo array defined at the beginning of our program to do this.

So What is this "Priority" Thing?

Since the Sound Blaster can only play one sound at a time (in hardware), we will be using a priority-based system. Using this system, each sound is assigned a priority when it is loaded. Before we play a new sound, we check to see if another sound is already playing. If so, we check the priority of the currently playing sound. If the sound currently playing is more important, we don't interrupt it. But if the new sound has the same priority or is more important, we stop the currently playing sound and play the new sound.

The following function will tell us whether or not the Sound Blaster is playing a sound by checking to see if the DMA channel is in use. We can use this function with our SB.PlaySound sub to implement the priority-based system.

Playing Sounds

Figure 2-4: Mapping the sound to play to the page frame

Once a sound has been loaded, it is ready to be played. To play a sound, we need to know four things: the priority, frequency, length, and memory location.

We stored the priority, frequency, and length in the SB.SlotInfo array when we loaded the sound, but what about the memory location? Since we can only perform DMA transfers from the 1 MB memory region, the EMS logical pages containing the sound must be mapped to the page frame first. Then we can use the page frame address for the memory location.

So how do we know which logical pages to map to the page frame? Well, because each sound slot is 4 pages, we can use:

(We have to subtract 1 from the slot number because the sound slots are numbered starting at 1, while the EMS pages are numbered starting from 0.)

Once the correct pages have been mapped, we can program the DMA controller to transfer the sound from memory to the sound card.

1. Mask the DMA channel which we will be using by setting the mask bit in the DMA mask register. This can be done by adding 4 to the DMA channel number and sending that value to the DMA mask register.
2. Send a 0 to the DMA clear register to stop any current transfers.
3. Set the DMA transfer mode to output by adding 48h to the DMA channel number and sending it to the DMA mode register.
4. Set the address and page.
5. Set the length to transfer.
6. Clear the mask bit on the mask register. The DMA transfer will begin as soon as the Sound Blaster is ready.

After programming the DMA controller, the only thing left to do is tell the Sound Blaster DSP that we want to play a sound. But to do this we have to wait until the DSP is ready and then send the commands. This sub checks the DSP write register and waits until the DSP is ready before sending the byte.

1. Tell the DSP that we want to set the digitized sound transfer time constant by sending 40h.
2. Send the time constant: 256 - 1,000,000 \ Frequency
3. Tell the DSP that we want to output a sound using 8-bit single-cycle DMA by sending 14h.
4. Send the length of the sound.

The Sound Blaster will begin playing the sound immediately after step 4 is complete. And since we are using DMA to play back the sound, our program can do whatever it wants while the sound is playing. That's right, the sounds are played in the background!

Pausing the Sound

Although the sound is playing in the background, it can be paused at any time. To do this, all we have to do is send D0h to the DSP write register. This will pause any sound that is currently playing for an indefinite amount of time.

To resume a paused sound, we just send D4h to the DSP write register. The sound will then continue playing where it left off.

Another Sample Program

Here is a sample program I wrote to test out all the Sound Blaster routines presented in this tutorial. The sample program simply loads 9 wave files into EMS and allows you to play them back by pressing 1-9. It also demonstrates the priority-based sound system by assigning different priorities to each sound. Check it out!

That's All for Now...

Well, I hope you enjoyed part 2 of the EMS tutorial series. Heck, maybe you even learned something! In part 3 (coming in a month or two), I'll finish up the series by showing you how to store graphics and huge data arrays in EMS.

If you have any questions or comments about this article, or found an error, please e-mail me or post a message on the Phat Code forum.