Programming Sound Cards

home *** CD-ROM | disk | FTP | other *** search

/ Programming Sound Cards / Programming Sound Cards.iso / sound_37 / ibmmidi.txt < prev

Wrap

Text File | 1995-01-01 | 11.4 KB | 227 lines

IBM MIDI INTERFACE Version 1.0 Harley A. Burton Copyright 1987 Burtech Ind. GENERAL The Musical Instrument Digital Interface (MIDI) worked out by Casio, Roland, and others a few years ago has be come the widely accepted standard of the musical industry for interfacing everything from keyboard synthesizers, tape recorders, mixers to drum machines and everything else conceivable. The impact of this technology on the music industry has been dramatic. Although hardware and software exists for this technology, in general it has been quite expensive. As an example, the Roland MPU401 interface, the most powerful interface for the IBM-PC family of computers is about $600 list price. While there have been others developed for a lower cost, for example the board listed in the June 1986 BYTE magazine article, these are somewhat complex. I hope to offer the hobbiest/experimenter with a lower cost alternative, and yet a challenge to develop some or all of the software as a project. Without going deeply into the technical side of MIDI, it seems to at first scare the world. It runs at a high data rate, 32.1250Kbps, use the odd interface of approximately 5ma current loop and be optically coupled. This sounds like something totally out of the realm of the home hobbiest. Not at all, in fact, it is not only possible, it is quite easy. Originally, IBM made the Asynchronous Communications Adapter for our IBM-PC's and they didn't know anything about MIDI. They did however give us the tools we need that can be used to interface to MIDI systems with minimum hardware modification and software generation. From here on, I will be discussing modifying an IBM Asynchronous Communications Adapter to work with MIDI systems. While I have no experience with clone serial communications boards, I will assume that they could be modified similarly and will attempt to do it sometime. This discussion will be quite technical, but not beyond the average experimenter. I hope you will try the ideas presented here and pass your findings along to all of us on the various BBS's. DATA RATE GENERATION The original IBM Asynchronous Communications Adapter was capable of serial data rates from about 45 baud to 19200 bits per second in 5,6,7 and 8 data bits with 1, 1.5 and 2 stop bits, even, odd or no parity. In MIDI, we would like to run at 31250 bits per second, 8 data bits, no parity and one stop bit. Well, just change the initialization number, we would think. Unfortunately, the comm port can't be programmed as it stands for that baud rate which brings us to the first modification. The baud rate timing in the comm port is generated by a 18.432MHz oscillator labeled in my schematic as U10. This is then divided by 10 in U6 to get 1.8432MHz, the standard baud rate generator. The 8250 UART U11 which actually does all the work has an on-chip oscillator which could be used to generate the desired frequency. As it turns out, by removing U6, the 7490 used to divide by 10 and connecting a 3MHz crystal between pins 16 and 17 of U11, the 8250, the comm port will now operate at 31250 bits per second, the MIDI standard. The comm port will no longer operate as a standard serial board, but who cares. These things are cheap enough to convert to MIDI permanently. On the Serial/Printer Adapter which is the type used in the IBM- PC/AT, the generation is slightly different. The base oscillator is 1.8432MHz as it comes from the factory. This is buffered in U11, a 74LS05. The final serial port device is a NS16450, an upgraded 8250. This board requires breaking the foil trace between pin 2 on U11 and pin 16 on U5, the NS16450. This can be simply a cut with an X-Acto knife. Then connect a 3MHz crystal between pins 16 and 17 as in the other board. The maximum operating frequency of both boards is 3.1MHz, but there is adequate "head room" for this to work satisfactorily. It also turns out that by using the 3Mhz crystal, the internal divisor ratio is such that when you tell the port to initialize for 19200bps, it will actually configure itself for 31250bps. The ratio of 3.0Mhz to 1.8432MHz equals the ratio of 31250bps to 19200bps (3/1.8432 = 31250/19200). This will have implications which will be described later in the software. 5 Ma CURRENT LOOP The original IBM Asynchronous Communications Adapter had provisions for the archaic 20 ma current loop standard. This has disappeared on the Serial/Printer Adapter and most clone adapters. For our purposes, this is a shame. I will describe first converting the IBM Asynchronous Communications Adapter to 5ma current loop then provide some thoughts on the other adapters. On the IBM Asynchronous Communications Adapter, the 20ma current loop was configured by turning jumper block XU5 around opposite of that required by RS-232 (yes, I am being intentionally vague, because I can't remember off hand which way that is). The 20ma current loop is provided by 3 sections of U8 paralleled and driving the 20ma loop through a 100 ohm resistor, R3. By changing this resistor to a 390 ohm resistor, the current should be a little hot 5ma. A 470 ohm resistor could be used if you are not driving long 5ma lines. Either will be within safety range of the MIDI requirements. A 220 in series with a 180 ohm, would of course be exact. Any of the above will work fine. On the recieve side, the IBM Asynchronous Communications Adapter already has an opto-coupler interface provided by U4. This should be useable without modification. An adapter will be needed to go from the 25 Pin "D" connector on the back of the Asynchronous Communications Adapter to a MIDI 5pin DIN connector used for MIDI. The parts for this can be purchased from Radio Shack and since I don't have schematic capability with this word processor, I won't go into it here. For a board other than the Asynchronous Communications Adapter such as a clone or the IBM Serial/Printer Adapter, an RS-232 to 5ma adapter will need to be built. I won't design one here, it's really pretty trivial, but I would suggest receiving the RS-232 with a MC1489 then driving the 5ma with 3 sections of a 74LS04 tied in parallel then driving MIDI through a 390 ohm resistor. The receive side could use any of the optocouplers that are usually specified for MIDI, such as the one in the BYTE article mentioned above. This could then drive a MC1488 RS-232 line driver. A small 5volt power supply will have to be provided in this interface. I might suggest that if you have to build the RS-232 to 5ma converter, use some of the extra sections of the devices to build some MIDI through buffers, splitters, etc. MIDI SOFTWARE Without going into the software in great detail, there are several built-ins and hints that I can give which may help in writing your own software package. All of the software ideas are in IBM BASIC for clarity. These built-ins are probably available in other languages as well. The first thing we will need is beat timing or tempo. I have chosen the easy way out again. I built a tempo generator with a type 555 timer and a few components that generates a pulse at 24 times the quarter note beat. This allows me to generate 32nd notes and 16th triplets, not that I would ever play that fast. I built it with a range of 20 to 240 beats per minute (8 pulses/second to 96 pulses/second). This I connected to the trigger input of a game port. Again, I had one and didn't feel like building a trigger timer board. This I control manually, but you could use the internal timer section 2 of the 8253 on your IBM-PC mother board. I don't know how to do this and would appreciate if anyone knows how, please tell me. I use the "ON TRIG(1)" statement in BASIC to jump to a subroutine in which I keep track of which portion of a beat I am in. This provides the basic timing for both transmit and receive. I will come back to this later. I wish that IBM had given us better resolution on the ON TIMER function, it could have been used as a beat counter but with only 1 second resolution there isn't much you can do with it unless your music is VERY VERY slow. The initialization of the serial port is quite simple to implement for MIDI. I use the "OPEN COM1:19200,N,8,1,CS,DS" statement to initialize the port. Remember that because we changed the crystal to 3MHz, opening at 19200 in software is actually opening at 31250 bps. This works!!! I don't like error checking in hardware, so I disable the CTS and DTS signals. I have notes to be transmitted assigned to portions of a beat. These are built off-line by a conversion routine that takes information from the music processor SongWright and builds a file of notes and timing to be transmitted over MIDI. I won't go into how this works until I get it totally ready, but what it does is this: When a TRIG(1) interrupt occurs, the software checks if a note or group of notes are to be sent. If they are, it builds the group of notes with statements like J$ = CHR$(14)+CHR$(23)+CHR$(77)... Then transmits the string with a PRINT#1,J$ Since the output is a buffered, interrupt driven transmit, the notes are transmitted at 31250 bps. with no further assistance from the user. Unless there is a LOT of notes to be sent, as in 16 voice chords, along with big drum sounds, they should sound correct. This is a limitation of the transmission media, MIDI, however and not the IBM hardware. I also use the "ON COM(1)" statement to set up a receive routine for MIDI. This allows me to avoid polling the receive side so that I can do other things. When a note is received via MIDI, I jump to a routine that gets the note, then reads the portion of beat counters to see what beat time I should assign to it. It checks for several other things, like note off, system messages, etc. These are interpreted and used where appropriate. I assume that I can receive anything anytime and I have to know what I received and what to do with it so this routine is potentially a little longer than necessary. CONCLUSION I have attempted to describe a hardware and software experiment into the fascinating world of MIDI. I hope to continue with this experiment and eventually build a full MIDI system with all of the features we have dreamed about. I would like to get input from all you and hope you will help me in this experiment. If you develop any software in this line, please make it public domain so that we all can enjoy it.