Index of /knowledgemedia/MIDI/MSDOS/PC_MIDI

      Name                    Last modified       Size  Description


[DIR] Parent Directory        11-Jun-2003 14:51      -  
[TXT] FARCALL.INC             11-Jun-2003 14:50     1k  
[TXT] HUGEDATA.INC            11-Jun-2003 14:50     1k  
[TXT] MANIFEST                11-Jun-2003 14:50     1k  
[TXT] MPU401.ASM              11-Jun-2003 14:50    61k  
[TXT] MPUIO.ASM               11-Jun-2003 14:50    13k  
[TXT] MPUIO.H                 11-Jun-2003 14:50     1k  
[TXT] NEARCALL.INC            11-Jun-2003 14:50     1k  
[TXT] SMALDATA.INC            11-Jun-2003 14:50     1k  

1.	INTRODUCTION

The files in this package are broken out of a modified toolkit for
manipulating MIDI data with the Roland MPU401 interface. The original
software was the Carnegie-Mellon MIDI Toolkit (CMT), which is in the
public domain. The original CMT did all it's I/O access work directly,
which I did not like. So I wrote the driver included in this package
(MicroSoft MASM 4.0), plus an interface module in 'C' to access it. Only
very minor modifications to the other CMT programs were needed.

For more info on the CMU MIDI Toolkit, the reference is Roger Dannenberg
(from siesmo, his email address is  ...!seismo!a.cs.cmu.edu!dannenberg).

2.	DRIVER

NOTE:	The driver source code (MPU401.ASM) was over 50 kbytes, and there-
	fore was split into two parts - MPU401.AS1 and MPU401.AS2 - before
	I put the shar archives together. After you unpack the files, you
	will have to splice the parts together again, for example by
	doing 'cat MPU401.AS1 MPU401.AS2 > MPU401.ASM' or by using a text
	editor.

The driver is loaded (as a character type driver) during system boot. To
effectuate this, the line

	DEVICE=MPU401.SYS

must be in your CONFIG.SYS file. You can specify some non-default para-
meters in that line too, but that is described in the source. Note that
although the MIDI driver resides in the file 'MPU401.SYS', the name of
the actual driver (when you access it from a program) is 'MPU401$$'. This
is because in MSDOS the name of an installed driver overrides any file
name, in any directory, on any disk  drive, and with any extension. This
complicates file copying etc, so I appended two '$' signs to make the
driver's name unique.

When you use the driver from your application, the driver is NOT accessed
via DOS, since that would be far to slow in a real-time music application.
Instead, when the driver is started at boot time, it will grab one of the
software interrupt vectors in low RAM, and point that to itself (after first
saving the original value in a local variable). Later the application exe-
cutes the software interrupt with a 'function code' in  a register, and
this brings execution right into the driver code (this is very much like
the DOS 'INT21' system calls, except the function code in in CPU register
AX and not in AH).

There are a number of function codes. Before the driver can be used at all,
it must be activated, and after the application terminates, the driver should
be deactivated (the latter is to clean up hardware interrupt stuff). In
particular, if the application has set up it's own buffers for the driver
(as described below), failure to deactivate the driver may case memory to
overwritten if data is received by the MPU401, even after the application
is terminated.

The function codes are 'documented' in the source (fairly well I think, but
you probably need to know assembly language...).

Driver parameters you can set at boot time are the software interrupt
'number, the hardware interrupt number, and the size of the buffer(s).
The software interrupt number can also be examined and changed by each
application program. Normally the driver ignores MIDI exclusive messages,
but an application can set up an own buffer for exclusive messages. Also,
the driver has a buffer for normal messages, the size of which can be set
at boot time. But the application can override this and specify an own
buffer, which can have a maximum size of 32 kbyte.

The driver was written and tested on an IBM PC/XT clone. The interrupt
structure on an AT type computer is different, and has not been tested.
The driver finds out if the computer it is running on is an 8086 or an
80286 CPU, and then it goes into a table to install Interrupt related
data accordingly. The table for the XT is correct, and that is what has
been running for about a year now. The AT table is not correct, because

	a) I do not have the information that would be needed
		and
	b) if I had the info, I could not test it anyway

For these reasons, I suggest that if you have an AT, check up on those
things and fix the table (the 'ATTAB' table at the end of the source
code). If you get it to work on an AT, I would suggest you kindly send
the patches to me, so I can incorporate them into the originals, and
post the 'approved' patches to the net.

3.	INTERFACE MODULE

There is a small interface module in the package, called MPUIO.ASM. That
module is intended to be linked into your 'C' programs to simplify the
access to the MPU401 driver. The interface module was written for MicroSoft
'C' v.3.0, but since TurboC 1.0 and MSC (both 3.0 and 4.0) are so very similar,
even at the object file level, it should link perfectly in TC programs too.
I have not tested with TC 1.5, TC 2.0, or MSC 5.x, but I would expect no
problems with those. For other compilers, you may need to modify the inter-
face module according to register usage conventions etc. For example, Lattice
C uses another register for function return values.

The interface module includes two one-line files. These files define what
memory model is used. the file FARNEAR.INC specifies if code accesses
(subroutine calls) use far or near op-codes, and SMALHUGE.INC specifies
far or near data accesses. Four prototype files are included - just select
the two that are appropriate and copy the to FARNEAR.INC and SMALHUGE.INC.

The MPUIO.H contains declarations for the functions in MPUIO.ASM, and should
be #included in all files that use the MPUIO.ASM module.

4.	AND...

As I have stated above, this is a working set of software. It may not be
appropriate for your use, and there may be problems with it (specifically
the use on an AT). STill, I think it is useful to have a standardized way
of accessing the MIDI harware, and this was an attempt in that direction.
I am sorry I cannot provide a better manual than these notes that I
scribble down just before posting. It is my hope that some of the netters
will find this useful. If - oh, I mean when - you find bugs, and if you make
modifications or improvements, I would like to know about them.

For all you netters in the US: Form the mail I have received answering my
original offer to post this stuff, it seems that a lot of the mail has
been routed via dscvax2 in Santa Barbara, with which we have a direct
dial-up connection. That may be because you have addressed me as
'bl@infovax'. The problem is, our connection with dscvax2 may be dis-
continued at any time, since we do not use it anymore. So I would suggest
you address in such a way that the mail goes via

	'seismo!mcvax!enea!infovax!bl'.

Otherwise, it may bounce back. I think the basic problem is the routing
tables here in Europe, since even mail from England has taken the way via
California on its way here in one case....! By the way, Dennis Pelton
received my posting with return path (!!!)

	att!pacbell!ames!pasteur!agate!ucbvax!decwrl!sun!pitstop!
		sundc!seismo!uunet!mcvax!enea!infovax!bl

and his return letter came via dscvax2. UseNet is truly amazing!

Finally, I would wish that the music groups on the net became more active
(well at least we do not see much activity here in Sweden). I encourage
you all to share what software you have, if you can do it. There must be
a lot of individual good work and effort going on out there, that is known
just by one or a few people. I hope this package can be the start of some-
thing more...
			Good luck to all of you!		-- bl