George Logemann and Roger Dannenberg
CMT has drivers for several non-MPU-401 MIDI interfaces for IBM-compatible personal computers. Under DOS, there is no standard MIDI device driver interface, and CMT accesses MIDI interfaces directly through I/O instructions. CMT is not smart enough to detect your device type automatically and call the appropriate interface routines. Instead, the proper interface routines are selected manually and linked with the CMT library
cmtlib.lib. All CMT programs in turn are linked with
cmtlib.lib. These programs will only work with one particular type of interface, but you can re-link to make new versions that work with different interfaces.
A further restriction is that these alternative interfaces are only provided for users of Microsoft Quick C. We suspect that the files may work with other compilers, but we have not tested all the permutations. The approach describe in Section ``Sound Blaster Configuration'' should work with all compilers.
The supported non-MPU-401 devices are:
In order to support all of these possibilities, the idea is to replace
mpu.c (that handles MPU-401 and lookalikes)
with a module that replaces
mpu.c function calls (e.g., to send and receive
data, to reset, etc.) with calls similar in function but of the same name
(e.g., to send data, one uses
mPutData(); this is an entry in
that will be replaced by one in each of the other modules). Thus, only
cmtlib.lib is modified, allowing applications to be rebuilt with the
same make file and configurations of object files.
Please note that Voyetra and Keytronics supply proprietary drivers and other software that obviously CMT cannot provide due to copyright restrictions. Please contact the manufacturer for their interface software. The Sound Blaster protocol is known publicly and therefore can be supported by CMT. (And Sound Blaster v4.xx cards work with the normal MPU-401 drivers in CMT; see Section ``SoundBlaster and MPU Compatible Interfaces'').
The modules required for the various interfaces are (note that
InterfaceSupplied with CMTProprietary from manufacturer
In order to construct a
cmtlib.lib for an alternative interface, build
qcmtlib.mak. (Recall that we only include support for Quick C.) Then run the batch (
.bat) file indicated above. The batch file will modify
cmtlib.lib by replacing the old
mpu.obj code with code for a different interface.
mpusb.cperforms by default. In addition, Sound Blasters 2.xx thru 4.xx can employ "Uart" MIDI I/O mode, which is invoked in
mpusb.cby defining MPUUART=1 in the environment.
voyvapi, you can support regular MPU-401's as well by loading
vapimpu.comin place of
vapivp11.com. See the Voyetra documentation for details.
Another Option for Sound Blaster UsersHere, we discuss a simpler way of
supporting Sound Blasters 1.xx through 3.xx by replacing
mpu.c for the MPU-401 with an "
mpu.c" for the Sound Blaster.
Section ``Default MPU-401 Configuration'' describes the default configuration for the MPU 401, and Section ``Sound Blaster Configuration'' describes the
mpu.c replacement for the Sound Blaster.
Default MPU-401 Configuration
As released with CMT,
mpu.c contains code for an MPU-401.
Mpu.obj is contained in
cmtlib.lib, which is in turn linked with CMT applications.
Mpuok.c is a copy of
mpu.c. In case you lose the original
mpu.c, you can copy
mpu.c and rebuild
By default, the standard
mpu.c assumes the following:
To override defaults, in environment set:
Sound Blaster Configuration
Mpusb.c is modified from
mpuok.c. You can copy
mpu.c and build
qcmtlib.mak. The resulting programs will not work with MPU-401 look-a-likes.
mpu.h. Do not change either
mpusb.c assumes the following:
Use the environment to override:
More Information on SoundBlasters
There are many flavors of SoundBlaster (at least eight), but for our purposes
there are three classes:
The Pro series have two modes of MIDI I/O, one compatible the original series, another that is new to the Pro series. Both modes use DSP register locations, not at all like the MPU-401's; both require a special reset routine unrelated to MPU-401.
The difference between the two Pro modes is that the original one, called "Normal" requires status changing, i.e., turning off interrupt-driven input when you want to output, and requires outputting two bytes for every MIDI byte (essentially an escape byte to route the following byte to the MIDI interface). The other mode, called "Uart", does not work on the originals and does not co-exist with 8-bit DMA sound, but requires no status change and no escape byte.
There are a lot of changes needed to
mpu.c, so George Logemann created an alternate version of
mpusb.c that does both Uart and Normal protocol. Normal is done by
default since that is common to all SoundBlaster's (so far).
Defining MPUUART uses Uart mode; this should be a little faster than Normal mode.
mPutCmd is now useless and does nothing so that you do not have to change
midifns.c when you switch from
You can build versions of CMT with Quick C for various interfaces. There are two basic approaches. One is to alter the
cmtlib.lib library file with code that was written specifically for different interface hardware. The other is to replace
mpu.c with alternate versions. In general, you can adapt CMT to other hardware by supplying all the entry points mentioned in
A comment: this would all be simpler if the
mpu.c functions were included in a device driver. Then, you could simply install the right device driver and applications would run with different devices without recompilation or relinking.