This describes the code SBDVP.EXE. It uses TR's existing interface to the K1EA digital voice processor card. I have not implemented the backcopy features of the K1EA card, so don't attempt to use them.
To use SBDVP.EXE, you need:
Most of this manual will assume that you are using a SoundBlaster TM card. If you are using a Windows Sound System compatible sound card, the slight changes you need to make are described in section 10. Make sure that your sound card is set up for microphone input. SBDVP doesn't manipulate those settings. Use one of the utilities that came with the sound card to change any input, output, and volume settings.
My CONFIG.SYS file contains the line
STACKS=9,256
which defines 9, 256 byte, hardware interrupt stacks. Nearly all
of my testing has been done with this statement in CONFIG.SYS, but
I have tested it with
STACKS=0,0
which defines no hardware stacks and it seemed to work.
If you will be using vox,
start the code by typing
SBDVP
If you want to use push to talk, you need an interface
exactly like the CW ones described in the TR manual. If you already
use push to talk on CW, you are all set. The interface
can be on a parallel or serial port. If it is on parallel
port 2, start the code by typing
SBDVP -p2
replace the 2 by the correct parallel port if it is not port 2.
Alternatively if you want to use a serial port for push to talk,
then for serial port 2 type,
SBDVP -s2
where again you should replace 2 with the number of the serial
port you are using if it is not 2.
The code will look for a standard BLASTER environment variable. This
is normally set up in AUTOEXEC.BAT when your sound card is installed.
It should be a line like
SET BLASTER= A220 I5 D1 T4
It may have additional entries, but only these are looked at
by SBDVP. If this is already set, then you can just try
running SBDVP. If not then you need to set this up first.
The Axxx needs xxx set to the hexadecimal address of
the sound card. Dx needs x set to the 8 bit DMA channel of the
sound card. It must be 0, 1 or 3 for SBDVP to work. Ix needs x
set to the hardware interrupt of the sound card.
Finally, Tx gives the type
of sound card you have. This is only used by SBDVP to detect
SoundBlaster TM 1.X cards. In that case autoinitiate transfers are turned
off.
In the future,
I plan to turn on the FIFO memory on the
SoundBlaster TM 16 for better
audio quality when I get access to one to test it. Tx with
x = 1 is the
SoundBlaster TM 1, 2 is the
SoundBlaster TM Pro, 3 is the
SoundBlaster TM 2, 4 is the
SoundBlaster TM Pro 2, 5 is
the
SoundBlaster TM
ProMCV, and 6 is the
SoundBlaster TM 16.
SBDVP will also attempt to open the file SBDVPCFG.DAT in the current directory and if this file exists SBDVP will read a list of file names (just file names, not full path names) each on a single line. These should match the file names that TR uses and be audio files that were produced previously. The file SBDVPCFG.DAT should not be used the first time you fire up SBDVP.
The program if successful will terminate but stay resident. If you type
MEM/P/C
at the DOS prompt, you will get a list of programs in memory. You
should see SBDVP listed along with the amount of memory that it
is using (about 25Kbytes). You can unload the program by typing
SBDVP -u
at the DOS prompt.
If you have available high memory (use MEM to find out),
you can load SBDVP into high memory leaving extra conventional
memory for
TR, by typing
LOADHIGH SBDVP
The program can be unloaded using
SBDVP -u
as in the usual case.
To use LOADHIGH, you need to have EMM386.EXE or equivalent
loaded after
HIMEM.SYS in your CONFIG.SYS file and you need to tell DOS to manage
the upper memory blocks by including DOS=UMB,HIGH in CONFIG.SYS.
See your DOS manual if you need more details. Typically running
MEMMAKER will add EMM386 and the DOS commands automatically.
To try out the DVP, make sure a microphone and speaker(s) are
connected to
the sound card.
Fire up TR as usual, and use the Control-J menu to choose
ENABLE DVP = TRUE.
In SSB mode, you should now see DVP ON, and you should be able
to toggle between DVP on and off using Alt-K.
Function keys are programmed as described in the TR manual.
Press Control-F1 to start recording CQF1.DVP and say a CQ
into the microphone. When you finish press ESCAPE to terminate
the recording. Pressing F1 will send your CQ out the speaker.
Hit ESCAPE just like
in CW to terminate the output before it finishes.
You can program all the function keys using the Alt-P command as described in the TR manual. If you subsequently unload SBDVP using the SBDVP -u command, a file with the name shown while recording it will be produced or overwritten in the current directory. If you add these file names as single lines in SBDVPCFG.DAT, SBDVP will load them when it is started in that directory. The BACKCOPY functions have not been implemented. Do not enable BACKCOPY - unpredictable things may happen.
The default sampling rate of 12048 Hz is a compromise between
sampling quality and speed. Higher rates with only
8 bit samples don't increase the quality substantially since the signal
to noise ratio is not very high. Lower rates will give lower
quality audio, but the recordings will take up less memory.
If you want to change the sampling rate, start SBDVP with the
command
SBDVP -rnnnn
where nnnn is the sampling integer rate in Hertz. For example,
SBDVP -r8000
will set the sampling rate to 8000 Hz. If you record at one
setting and play back at another you get the usual frequency
and speed shift. This will be most useful to annoy your friends
during multiops. The -r option can be used with the -p or -s options
for push to talk operation.
As mentioned above, if you use push to talk, you need to have a push to talk interface attached to a serial or parallel port as described in the TR manual. Include on the command line either -pn where n is replaced by the number of the parallel port (1, 2, or 3), or include -sn where n is replaced by the number of the serial port (1, 2, 3, or 4). SBDVP.EXE looks up the corresponding port address in the ROM bios area and toggles the request to send line on the serial port or it toggles the init and strobe lines on the parallel port. This should work fine for single radio contesting. Two radio contesting with one radio calling CQ using the voice keyer while you are copying an exchange on a second radio (or whatever you two radio guys do - I can barely operate one) will require Tree to modify TR to operate the push to talk in SSB mode and keep track of which radio is transmitting. If neither a -pn or -sn option is included on the command line of SBDVP.EXE push to talk output from SBDVP will be disabled, and you need to use vox.
The simplest method is to use separate microphones for the
soundcard and your rig. To help with interfacing the rig microphone
to the soundcard, SBDVP can make one of the parallel port data
lines (pins 2 to 9 on the DB25 connector) go high when you are
recording. This line can be used with an external circuit
to switch the rig microphone to the soundcard. To enable this,
add the command line switch -m2p1. This stands for microphone
pin 2 parallel port 1. You can set the pin number from 2 to 9
and the parallel port number can be 1 to 3. For example,
to use both push to talk and toggle pin 5 of parallel port
1 when recording you would start SBDVP with
SBDVP -m5p1 -p1
I use a separate microphone connected to the sound card. The output jack of my sound card is an 1/8 inch stereo phone jack. I use a Radio Shack ``Dual Stereo Headphone Adapter'' part number 274-313, to give me two outputs. One output goes to the computer speakers in the usual way so that I can monitor the audio. I run one channel (the output of my card is stereo) of the other output across a 100K ohm potentiometer and run the wiper arm of the pot to the back panel audio input of the rig (in this case N7LR's TenTec Corsair). I mounted the pot in a small aluminum box and used RG-174 to keep the connections shielded. Kenwood owners might want to check out technical correspondence page 71, June 1996, QST, where KN3C describes hooking the audio output of a SoundBlaster TM 2.0 to the data input of a TS-850.
When I use the soundcard, the rig microphone will also modulate the transmitter. If you want to carry on a conversation while the soundcard is playing, you need to switch off the rig microphone or otherwise disable it while the soundcard is outputting audio. The command line switch -oxpy, will cause pin x (must be 2-9) of parallel port y (must be 1-3) to go high while the soundblaster is transmitting. The syntax is exactly the same as the microphone switching line above except it starts with -o instead of -m. You need to build an external interface to use this line to control the switching of your rig input.
The older
SoundBlaster TM 1.0 and 1.5 cards do not support autoinitiate DMA
transfers. This means that the CPU has to intervene to reprogram
the sound card at the end of every buffer transfer, leading to
gaps that make the sound quality poorer. I have found that
sound quality for playing sound files is adequate without autoinitiate
mode, but the recording quality is somewhere between terrible and
almost acceptable.
If for some reason your card doesn't support
autoinitiate transfers and doesn't have T1 set in the blaster environment
variable, you can force autoinitiate DMA transfers off by including
-a on the command line, i.e.,
SBDVP -a
To make the record quality better, the sound buffer can be made larger
so the gaps occur less frequently. I have included a version of the
executable SBDVPB.EXE that is identical to SBDVP.EXE except that it
has been compiled with the option -DBLOCK_LENGTH=4096, which increases
the sound buffer to 8K. This necessarily increases the code size by
16K, and the memory use will be around 40K. If you can use the loadhigh
command, this doesn't matter, otherwise this memory cannot be used by
TR, and you need to decide what to do. One ``solution'' is to use
SBDVPB before the contest to record your files, and then use SBDVP
during the contest, but don't make any recordings with it. Another
``solution'' is to record on a friends computer that has a newer
card, and use these files during the contest.
If you have a SoundBlaster TM 2.0, Pro, or 16, none of this concerns you and you should always use SBDVP without -a.
I have included experimental support for Windows Sound System compatible
chips. To use these you need to include the command line flag -w8 or -w16,
i.e. use
SBDVP -w8
or
SBDVP -w16
which will play/record 8 bit samples at a 11KHz rate or 16 bit samples
at at 16 KHz sampling rate. In addition you must set the environment
variable WSS for example,
set WSS=A530 I5 D1
where 530 should be replaced by the I/O address of the WSS card,
5 with the hardware interrupt, and 1 with the playback DMA of the
WSS card (this is normally the first DMA listed when 2 are given).
The Windows Sound System (WSS) or Microsoft Sound System was a sound card produced by Microsoft that is no longer made; I don't think Microsoft makes any sound hardware now. It used an Analog Devices AD1848 as its sound chip. I think that when manufacturers say that their sound card is Windows Sound System compatible, they mean that to some degree it is compatible with the AD1848 chip. I could not find a data sheet for the AD1848, but the Analog Devices web site says that the AD1845 is the nearest current equivalent, and its data sheet is available on line. I have access to two computers that have sound cards that claim to be WSS compatible. The first uses an Opti 82C924 chip, and the second uses a Crystal CS4236 chip. Data sheets for both of these chips are available at the Opti and Cirrus Logic Web sites respectively. The data sheets for the CS4236 and AD1845 give enough details to learn how to program the WSS.
The documentation for my soundcards gives the usual default Windows Sound System ``I/O Address'' as hex 530. Other standard I/O addresses are hex 640, E80, and F40. To use the Opti sound card in WSS mode, I first make sure that the DOS initialization utility has initialized the card in WSS mode. I then set the WSS environment variable to tell SBDVP that the I/O address is 0x530, the DMA is 1, and the interrupt is 5. My Crystal CS4236 based sound system is the sound system on the Intel PRO 440FX motherboard. It automatically detects whether it is being used in SoundBlaster TM or WSS mode. I have both the BLASTER and WSS environment variables defined, and by firing up SBDVP with or without the -w8 option I can use it in either WSS or SoundBlaster TM mode.
Nearly all of the newer WSS compatible chips allow the use of 2 DMA channels and can be set up for simultaneous 16 bit playback and record. While this would be useful to properly emulate the back copy function of the K1EA DVP, I haven't bothered with this. If yours is setup with separate DMA channels just list the playback channel as the DMA in the WSS statement.
The advantages to using the WSS driver are that it can use 16 bit samples for higher quality, and some WSS chips have a FIFO to reduce or eliminate pops due to other computer activity. The Soundblaster 16 has these same advantages, but I do not have access to one to test out code, so I do not support these Soundblaster 16 features. If you are having trouble in Sound Blaster mode and your card is WSS compatible, consider trying it in WSS mode.
I have set the mixer settings for the Sound Blaster Pro to what I think are reasonable ones. If these don't work on your system, you can disable all mixer changes by using the -v option on SBDVP.
I have successfully fired up Windows 3.1, and then in a DOS window used SBDVP and then TR. I could play the files that I loaded in with SBDVPCFG.DAT. To record, I have to first record something from the microphone using one of the windows sound utilities. This seems to set the correct microphone input. Also I have to use the PIF editor to lock extended memory and disallow background processes. However, the windows sound quality seems worse than the same recordings under DOS, and the likelihood of having problems is much higher since I don't really know what windows is doing and how SBDVP and TR interact with Windows.
SBDVP.EXE uses an extended memory handle for every audio file. The number of extended memory handles can be increased up to a maximum of 128 by using /NUMHANDLES=128 as a parameter when installing HIMEM.SYS in your CONFIG.SYS file. The default number is 32, and some of these may be used by other drivers etc. that use extended memory. It costs 6 bytes of conventional memory per handle. Although TR has about 30 default file names, you will probably only use a CQ and a few default exchanges. If the small number of available file handles becomes a problem the code can be rewritten. Eventually, if I get time, I'll change to using a single extended memory handle. Internally SBDVP has a limit of 40 audio file names set by the parameter MAXFILES. This can trivially increased and the code recompiled if needed.
Every time you choose to record a function, the following steps are taken.
The audio data is written to your hard disk only when you unload
SBDVP using
SBDVP -u
The file name will be the file name used by TR when the audio was
recorded.
Neither SBDVP.EXE or the HIMEM.SYS driver does anything very clever, so if you make a lot of rerecordings, you can fragment your extended memory space so that a recording cannot be as large as the amount of free extended memory. As an example, assume you have 4 functions recorded each using 100Kbytes, and you have 1 Megabyte of extended memory total. If you decide to rerecord the second file, it will free up the block of 100Kbytes, and then allocate the largest block of contiguous extended memory, which will be the 600Kbytes at the top of extended memory. If the new recording takes 100Kbytes, the memory will look like 100K for file 1, 100K free, 300K for files 3,4 and the new number 2, and finally 500K free. The largest contiguous free block is now 500K. Continued random rerecording will further fragment the extended memory. If this becomes a problem, a work around is to exit TR, unload SBDVP using the command SBDVP -U, and then rerun SBDVP using SBDVPCFG.DAT with the list of files you want.
When the DVP is enabled in TR, it looks to see if DVPTSR is loaded by examining the 0x60 interrupt address to see if the label DVPTSR00 is in the eight bytes before the interrupt driver. SBDVP also sets itself up this way so that TR will know that the DVP interrupt is available. TR then queries the DVP driver to find a shared memory area where it transfers file names and commands. When you press function keys on TR that need to communicate with the DVP, TR puts filenames and commands in the shared memory area and generates interrupt 0x60. SBDVP installs an interrupt routine that is called when TR generates interrupt 0x60. This routine parses the commands from TR to see what to do.
SBDVP when first installed not only takes over interrupt 0x60, but it also installs an interrupt routine that copies data between extended memory and a buffer that is used by the direct memory access chips that connect to the sound card.
If TR tells SBDVP to transmit CQF1.DVP, the following steps are taken
Recording is done similarly except that all the data directions are reversed. Additionally, a note is made of any newly recorded audio. When SBDVP is unloaded, using SBDVP -u, any newly recorded data is copied to hard disk so that it can be reloaded if desired. If the computer is shut off or crashes before SBDVP is unloaded, any newly recorded data will be lost. If you want to make sure that a recording is saved you must unload SBDVP and then restart it with the appropriate SBDVPCFG.DAT file.
The SoundBlaster TM Pro does not have any memory on the digital sound processor. Therefore if any other process or interrupt is using the data bus when a DMA data transfer is required, a click can occur in the sound input or output. Some clicks will therefore occur in normal operation. The SoundBlaster TM 16 does have a first in first out memory that can be turned on. I haven't turned it on in this code since I don't have an SB16 to play with. However, that should improve the audio quality. The SB16 can also support 16 bit audio which would also improve the sound quality.
You can set up TR in debug mode to help test out your configuration. Record messages for CQF1.DVP, CQECXHNG.DVP (sic), and QSL.DVP, and include these names in your SBDVPCFG.DAT startup file. Pick a contest like CQWW where DEBUG works in CW mode. Set up you LOGCFG.DAT so that it runs in CW mode when you type TR DEBUG. See the TR manual for details. Now set CW TONE = 0 (unless you enjoy hearing both CW and voice at the same time), MODE = SSB, and start TR DEBUG. With a standard cw exchange set, and CW speed set to 99 wpm, the ssb rate is 900 to 1000 per hour on my computer (I have smartdrv enabled; without smartdrv the rate is around 600 per hour). The program sends CW and the voice memories at the same time. This exercises the program a lot. I have let it run over night and it has successfully ``worked'' over 10,000 Qs on my system.
I would like to thank Tree, N6TR, for providing me with some information on the TR interface to the DVP and for writing a great logging program. I also thank Linda, N7LR and Natalie, KC7FWM for initial testing of the software. The TSR routines were adapted from public domain code written by Sherif El-Kassas, EB dept Eindhoven, U of Tec, Netherlands. Some of the sound card code is adapted from public domain code distributed by the SoundBlaster TM freedom project. SoundBlaster TM is a trademark of Creative Technology Ltd. and the name is used here solely to help identify hardware that might work with this software.