home *** CD-ROM | disk | FTP | other *** search
/ Audio 4.94 - Over 11,000 Files / audio-11000.iso / msdos / midi / pc_midi / pc-midi / readme < prev    next >
Encoding:
Text File  |  1988-11-24  |  7.2 KB  |  143 lines
  1. 1.    INTRODUCTION
  2.  
  3. The files in this package are broken out of a modified toolkit for
  4. manipulating MIDI data with the Roland MPU401 interface. The original
  5. software was the Carnegie-Mellon MIDI Toolkit (CMT), which is in the
  6. public domain. The original CMT did all it's I/O access work directly,
  7. which I did not like. So I wrote the driver included in this package
  8. (MicroSoft MASM 4.0), plus an interface module in 'C' to access it. Only
  9. very minor modifications to the other CMT programs were needed.
  10.  
  11. For more info on the CMU MIDI Toolkit, the reference is Roger Dannenberg
  12. (from siesmo, his email address is  ...!seismo!a.cs.cmu.edu!dannenberg).
  13.  
  14. 2.    DRIVER
  15.  
  16. NOTE:    The driver source code (MPU401.ASM) was over 50 kbytes, and there-
  17.     fore was split into two parts - MPU401.AS1 and MPU401.AS2 - before
  18.     I put the shar archives together. After you unpack the files, you
  19.     will have to splice the parts together again, for example by
  20.     doing 'cat MPU401.AS1 MPU401.AS2 > MPU401.ASM' or by using a text
  21.     editor.
  22.  
  23. The driver is loaded (as a character type driver) during system boot. To
  24. effectuate this, the line
  25.  
  26.     DEVICE=MPU401.SYS
  27.  
  28. must be in your CONFIG.SYS file. You can specify some non-default para-
  29. meters in that line too, but that is described in the source. Note that
  30. although the MIDI driver resides in the file 'MPU401.SYS', the name of
  31. the actual driver (when you access it from a program) is 'MPU401$$'. This
  32. is because in MSDOS the name of an installed driver overrides any file
  33. name, in any directory, on any disk  drive, and with any extension. This
  34. complicates file copying etc, so I appended two '$' signs to make the
  35. driver's name unique.
  36.  
  37. When you use the driver from your application, the driver is NOT accessed
  38. via DOS, since that would be far to slow in a real-time music application.
  39. Instead, when the driver is started at boot time, it will grab one of the
  40. software interrupt vectors in low RAM, and point that to itself (after first
  41. saving the original value in a local variable). Later the application exe-
  42. cutes the software interrupt with a 'function code' in  a register, and
  43. this brings execution right into the driver code (this is very much like
  44. the DOS 'INT21' system calls, except the function code in in CPU register
  45. AX and not in AH).
  46.  
  47. There are a number of function codes. Before the driver can be used at all,
  48. it must be activated, and after the application terminates, the driver should
  49. be deactivated (the latter is to clean up hardware interrupt stuff). In
  50. particular, if the application has set up it's own buffers for the driver
  51. (as described below), failure to deactivate the driver may case memory to
  52. overwritten if data is received by the MPU401, even after the application
  53. is terminated.
  54.  
  55. The function codes are 'documented' in the source (fairly well I think, but
  56. you probably need to know assembly language...).
  57.  
  58. Driver parameters you can set at boot time are the software interrupt
  59. 'number, the hardware interrupt number, and the size of the buffer(s).
  60. The software interrupt number can also be examined and changed by each
  61. application program. Normally the driver ignores MIDI exclusive messages,
  62. but an application can set up an own buffer for exclusive messages. Also,
  63. the driver has a buffer for normal messages, the size of which can be set
  64. at boot time. But the application can override this and specify an own
  65. buffer, which can have a maximum size of 32 kbyte.
  66.  
  67. The driver was written and tested on an IBM PC/XT clone. The interrupt
  68. structure on an AT type computer is different, and has not been tested.
  69. The driver finds out if the computer it is running on is an 8086 or an
  70. 80286 CPU, and then it goes into a table to install Interrupt related
  71. data accordingly. The table for the XT is correct, and that is what has
  72. been running for about a year now. The AT table is not correct, because
  73.  
  74.     a) I do not have the information that would be needed
  75.         and
  76.     b) if I had the info, I could not test it anyway
  77.  
  78. For these reasons, I suggest that if you have an AT, check up on those
  79. things and fix the table (the 'ATTAB' table at the end of the source
  80. code). If you get it to work on an AT, I would suggest you kindly send
  81. the patches to me, so I can incorporate them into the originals, and
  82. post the 'approved' patches to the net.
  83.  
  84. 3.    INTERFACE MODULE
  85.  
  86. There is a small interface module in the package, called MPUIO.ASM. That
  87. module is intended to be linked into your 'C' programs to simplify the
  88. access to the MPU401 driver. The interface module was written for MicroSoft
  89. 'C' v.3.0, but since TurboC 1.0 and MSC (both 3.0 and 4.0) are so very similar,
  90. even at the object file level, it should link perfectly in TC programs too.
  91. I have not tested with TC 1.5, TC 2.0, or MSC 5.x, but I would expect no
  92. problems with those. For other compilers, you may need to modify the inter-
  93. face module according to register usage conventions etc. For example, Lattice
  94. C uses another register for function return values.
  95.  
  96. The interface module includes two one-line files. These files define what
  97. memory model is used. the file FARNEAR.INC specifies if code accesses
  98. (subroutine calls) use far or near op-codes, and SMALHUGE.INC specifies
  99. far or near data accesses. Four prototype files are included - just select
  100. the two that are appropriate and copy the to FARNEAR.INC and SMALHUGE.INC.
  101.  
  102. The MPUIO.H contains declarations for the functions in MPUIO.ASM, and should
  103. be #included in all files that use the MPUIO.ASM module.
  104.  
  105. 4.    AND...
  106.  
  107. As I have stated above, this is a working set of software. It may not be
  108. appropriate for your use, and there may be problems with it (specifically
  109. the use on an AT). STill, I think it is useful to have a standardized way
  110. of accessing the MIDI harware, and this was an attempt in that direction.
  111. I am sorry I cannot provide a better manual than these notes that I
  112. scribble down just before posting. It is my hope that some of the netters
  113. will find this useful. If - oh, I mean when - you find bugs, and if you make
  114. modifications or improvements, I would like to know about them.
  115.  
  116. For all you netters in the US: Form the mail I have received answering my
  117. original offer to post this stuff, it seems that a lot of the mail has
  118. been routed via dscvax2 in Santa Barbara, with which we have a direct
  119. dial-up connection. That may be because you have addressed me as
  120. 'bl@infovax'. The problem is, our connection with dscvax2 may be dis-
  121. continued at any time, since we do not use it anymore. So I would suggest
  122. you address in such a way that the mail goes via
  123.  
  124.     'seismo!mcvax!enea!infovax!bl'.
  125.  
  126. Otherwise, it may bounce back. I think the basic problem is the routing
  127. tables here in Europe, since even mail from England has taken the way via
  128. California on its way here in one case....! By the way, Dennis Pelton
  129. received my posting with return path (!!!)
  130.  
  131.     att!pacbell!ames!pasteur!agate!ucbvax!decwrl!sun!pitstop!
  132.         sundc!seismo!uunet!mcvax!enea!infovax!bl
  133.  
  134. and his return letter came via dscvax2. UseNet is truly amazing!
  135.  
  136. Finally, I would wish that the music groups on the net became more active
  137. (well at least we do not see much activity here in Sweden). I encourage
  138. you all to share what software you have, if you can do it. There must be
  139. a lot of individual good work and effort going on out there, that is known
  140. just by one or a few people. I hope this package can be the start of some-
  141. thing more...
  142.             Good luck to all of you!        -- bl
  143.