Fullscreen HTML5Med Res (??MB)HTML4

MIDI for a song: a low-cost MIDI ADAPTOR for your PC or Amiga Here’s how to build a low-cost Musical Instrument Digi­tal Interface (MIDI) for your PC using a standard I/O card & little else. You need to build a small PC board inside a D15 or D25 plug & make some modifications to the I/O card. By GEORGE HANSPER A while ago, I was looking for a MIDI (Musical Instrument Digital Interface) for my PC. Although there are numerous sound cards on the market with some sort of MIDI interface, the cheaper ones are all FM-synthesis based (ie, not suitable for music) and the wave-table based ones were all up around $500 or more. At that price, given the rapid rate of obsolescence of computer hardware, it makes better economic sense to buy a stand-alone MIDI sound module for a little extra. What really irked me was that invariably you had to pay another $90 or so to get the MIDI interface, sold as an optional ‘MIDI cable’. This project is my answer. It should cost about $35, plus the cost of a serial I/O card. About another $50 should get you a reasonable high speed serial I/O card, with at least one 16550A UART (Universal Asynchronous Receiver Transmitter) on it (the 16550A is not essential but nice). The bonus is you can still use the extra I/O card for ‘normal’ serial I/O, except that the maximum data rate will now be 250 kilobaud instead of 38.4 kilobaud. Suitable platform Since this MIDI adaptor works from a standard RS232 serial interface, I have tested it on the following hardware platforms and found it to work properly in all cases: • IBM-PC with doctored serial card, running Linux OS • Amiga (using standard hardware and software) • Sun Sparc10 with standard hardware and modified kernel soft­ware. This MIDI adaptor will work with a 9-pin serial port, when used with a normal 9-25 pin serial adaptor. If you have a Sound Blaster equivalent or a Gravis Ultra Sound, this adaptor cannot be used unless a further modification is made. This is because the logic levels for 0 and 1 which appear on the D15 plug are inverted when compared with a normal serial port. I’ll also describe these mods a little later. Performance The performance of this circuit is limited mainly by the delays through the optocoupler. Any delays on the transmit cir­cuit were insignificant in comparison to the delays in the re­ceive circuit. The rise and fall times of the prototypes I made were typically about 5-10µs which is acceptable considering that a single data bit at 31,250 baud is around 30µs long. These three photos show the assembled D15 plug although the connecting cable is yet to be fitted. Above left is the outside of the finished plug, with the three LEDs showing, while at centre is the topside of the PC board. At right is the under­side of the PC board, with four resistors mounted. 76  Silicon Chip TX LED1  1k TX (2) BACK OF SOCKET 330  ZD1 6.8V 1W 4 BACK OF PLUG 1 1 4 2 330  GND (7) 2 5 3 MIDI OUT 3 5 D1 RTS (4) 2x1N4148 D2 DTR (20) 2.2k 4.7k RX (3) Q1 BC549 C 4.7k B A E ON-LINE LED2 8  K GND (7)  7 A IDIOT LED4  2 3 A IC1 6N138 B E C VIEWED FROM BELOW BACK OF SOCKET 220   K 4 K BACK OF PLUG 1 1 4 2 K 2 5 RX LED3 3 MIDI IN 3 5 K D25 SERIAL TO MIDI ADAPTOR Fig.1: the D25 serial to MIDI adaptor employs an optocoupler to avoid the possibility of hum loops in the link-up. As tested with a loop cable, the maximum baud rate for reliable operation varied with each optocoupler. This was as low as 45,454 baud in one prototype and as high as 125000 baud in another. Around 50-60 kilobaud is typical for the maximum baud rate. The Tx and Rx LEDs are a bit faint during normal operation, (hence the preference for high-efficiency LEDs). All in all, they still gave useful indications that things are happening. Given that they are only used during setup and debugging of the MIDI cabling, any more complex LED driving circuitry is not warranted. Circuit operation The hardware required for MIDI is simple: a plain serial interface (along the lines of RS232) but with an optoisolator at the receiving end to prevent hum-loops in amplifiers and other musical equipment. The only thing you need apart from the opto­­­­-i­solator is the right baud rate of 31,250 baud. Most IBM-PC serial cards cannot support 31,250 baud because they have a 1.84MHz reference clock oscillator. Unfortunately, 1.84MHz cannot give a baud rate which is close enough to 31,250, because the UART (Universal Asynchronous Receiver-Transmitter) first divides the clock by 16. This gives us a base-baud rate of 115200 which can then be further divided by a software-controlled divisor to give 57600, 38400, 28800 and so on. The rate of 28800 is close but not close enough (and yes, I tried it). However, all is not lost, because some of the 16450 UARTs and all the newer 16550 UARTs can handle clocks of up to 8MHz. The NS16C552 (which is a dual UART version of the 16550) can handle clock rates of up to 24MHz. This means that all it takes to modify an existing serial I/O card to work with the MIDI baud rate is to replace the crystal oscillator. This is easier than it sounds, because the 16450 and 16550 have an internal oscillator circuit which only requires a crystal and a few discrete components to be added – see Fig.5 for the circuit details. Transmit & receive circuit The transmit circuit consists of a few resistors, a zener diode and an indicator LED, labelled Tx LED1 – see Fig.1. The zener diode is there to limit the effective driving voltage for the MIDI output. The driving voltage on Tx (pin 25 D25) could be anything from 5V to 15V. The desired driving voltage is 5V but the current must always flow through the Tx LED, which has a fairly constant voltage drop of about 2V. Hence the choice of a zener diode around 7V. The same effect could be achieved by putting the Tx LED before the zener diode and using a 5V zener but this would mean that the Tx LED may come on whenever there was a signal on pin 2 of the RS232 port, regardless of whether the cable was connected or not. By placing the Tx LED after the zener, it will only come on when the cable is actually connected and the circuit is complete (and when there is a signal, of course). This gives a good indication about the state of the cable which is the first thing to suspect when things don’t work. The only other noteworthy point is the inclusion of 330Ω resistors in both the ‘driver’ lead and the ‘ground’ lead of the MIDI-out cable. This measure may seem redundant but it adds another level of protection. Let me illustrate, by assuming that instead of two 330Ω resistors, we just have one 680Ω resistor on the ‘driver’ lead (pin 4 of MIDI out) and that the ‘ground’ lead (pin 5 MIDI out) is connected directly to the ground of the computer (via pin 7). If the MIDI-out is plugged into another MIDI-out, then the two driver July 1995  77 BACK OF SOCKET 330  +5V (9) 4 2.2k  8  4.7k GND (4,5) 3 5 IC1 6N138 4 IDIOT LED3  2 3 MIDI OUT BACK OF SOCKET 220  IN (15) 1 4 2 5 330  OUT (12) 6 1 2 TX LED1 +5V (9) BACK OF PLUG 3 5 BACK OF PLUG 1 1  2 5 RX LED2 A Receive circuit 4 2 3 MIDI IN 3 5 K D15 SOUNDBLASTER/GUS TO MIDI ADAPTOR Fig.2: the D15 Sound Blaster serial to MIDI adaptor is essentially the same as Fig.1 except that the +5V supply is directly avail­able at pin 9 of the socket. circuits are at least separated by the (fictitious) 680Ω resistor. If, however, the MIDI-out is plugged into, say, another MIDI-out, with an incorrectly wired cable (eg, reversed), what would happen? Not a problem, you may think, because the resistor on the driver side is still in series with the Tx cir­cuit on both sides. The only difference is that the maximum potential difference across the resistor is now 10V instead of 5V (when both drivers are ‘on’). But there is another connection you should be aware of: the signal ground of your computer is almost certainly connected to ground through the mains plug. Your keyboard or sound-module may also be connected to ground in the same fashion. This would mean that the driver on the other MIDI-out would be connected directly to ground, with the possible addition of hum-loop currents. Of course, the other MIDI-out should be able to survive a short-to-ground like PARTS LIST D25 MIDI Adaptor (preferably with through-hole mounted UARTs) 1 8MHz crystal 1 1MΩ 0.25W resistor 1 1.5kΩ 0.25W resistor 1 39pF ceramic capacitor 1 22pF ceramic capacitor Semiconductors 1 6N138 optocoupler (IC1) 1 BC549 NPN transistor (Q1) 1 6.8V 1W zener diode (ZD1) 2 1N4148 signal diodes (D1,D2) 2 3mm green LEDs (LED1, LED2) 1 3mm red LED (LED4) 1 3mm yellow LED (LED3) Sound Blaster MIDI Interface 1 25-pin female D25 socket 1 shell for D25 connector 1 PC board 2 5-pin 180° DIN plugs 1 3-metre length figure-8 shielded cable Resistors (1%, 0.25W) 2 4.7kΩ   2 330Ω 1 2.2kΩ   1 220Ω 1 1kΩ MIDI Serial Interface 1 high speed serial I/O card 78  Silicon Chip 1 PC board 1 15-pin male D socket 1 shell for D15 connector 2 5-pin DIN plugs 1 3-metre length figure-8 cable Semiconductors 1 6N138 optocoupler (IC1) 1 3mm green LED (LED1) 1 3mm yellow LED (LED3) 1 3mm green LED (LED2) Resistors (1%, 0.25W) 1 4.7kΩ   2 330Ω 1 2.2kΩ   1 220Ω this, but who’s to say what is on the other end? The 330Ω resistor on the ‘ground’ side of the Tx circuit limits the current which may flow through this ground circuit which may be formed by equipment earths and provides a degree of protection for ‘foreign’ equipment. I have used two LED indicators on the receiving side. One (the green LED) indicates that there is data on the line while the other (3mm LED) is an idiot LED to give an immediate indica­tion of a reversed MIDI cable. This LED should be off during normal operation. Power for the receive circuit is obtained by tapping into the CTS and DTR signals from the RS232 interface. The diodes are there to prevent current from flowing from one to the other if one is high and the other is low. I’ve tapped into both CTS and DTR to ensure that we are more likely to get power, since the Rx circuit is useless without it. I’ve also included a power indica­tor LED (labelled ‘OnLine’), so that it is immediately obvious when the receive circuit is getting power. CTS and DTR are ‘high’ during normal operation which is normally the same voltage that Tx is at when it is high. The actual voltage could be anything from 5-15V, but 9-10V seems to be typical. The receive circuit centres around the 6N138 optocoupler. The photo­ transistor has a maximum Vce of 5V, so it is not ac­ceptable to simply connect it in series with a pullup or pulldown resistor across the 5-15V power supply. Instead, the photo­transistor of the optocoupler is connected to a pullup resistor which is connected to the OnLine LED. Although the current through this LED may vary between 2-7mA, the voltage across it remains fairly constant, at around 2V. The resulting signal out of the optocoupler swings from 0V to 2V and is then fed into the transistor, which inverts the signal (again) and gives the cor­rect voltage levels of 0V and 5-15V. In fact, the correct voltages for RS232 are actually -5V to -15V for a low level (logical 1), and +5V to +15V for a high level (logical 0) (and yes, this is the reverse of the usual convention). So in fact, this adaptor does not give Fig.3: these diagrams show the PC pattern, component placement & drilling details for the D25 version of the circuit. the ‘correct’ voltages for RS232 but it works reliably anyway. Assembling the PC board The PC board is a very tight fit inside the D shell as can be seen from the photograph which shows a prototype assembled into a D15 shell. Two circular cutouts need to be filed in the corners to allow clearance for the internal pillars of the D-shell. The board is wedged between the two rows of pins of the D socket. You should make sure that the board and socket assembly will fit into the D shell before soldering any components on the board. Note that the components for the 25pin version are all mounted on the top side of the PC board while for the 15 pin Sound Blaster version, four resistors are mounted on the copper side. Insert and solder all the components, ensuring that the LEDs, IC and diodes and transistor (where applicable) are cor­rectly oriented. You will then need to drill the D-shell to take the LEDs and, to this end, templates are shown in Fig.3 for the 25-pin version and Fig.4 for the 15-pin version. Use a 2.5mm drill and drill from the inside of the D-shell. This means any ‘burrs’ made by the drill entering will not be visible on the outside. Gradu­ally ream out the holes until the LEDs just slide snugly in and out of their holes. I used 5-pin DIN male plugs on the end of the cables, rather than the more traditional MIDI 5-pin DIN female sockets. This meant that I did not need any additional MIDI cables at all; I just plug my MIDI-adaptor straight into my keyboard (1.5-2m for each cable is a sensible length). I also made up a special cable for loop-testing, consisting of two 5-pin DIN line sockets on a short piece of cable. Modifying the serial card The oscillator circuit shown in Fig.5 does not require a special PC board and can be made up on a piece of Veroboard, as shown in Fig.6. In most computer equipment I’ve seen, I noticed that the crystal case is normally connected to ground, so I followed suit. Keep the wires connecting the oscillator circuit to the main board as short as is reasonably possible. Since your serial card may be different to the one I used, you will have to use your own judgement on how to make the necessary modifications to the card. I’ll outline the basic steps: (1). Locate the XIN pin on each of the UARTs. These will probably be connected to each other and to a driver elsewhere on the board. The XOUT pins should be unconnected. (2). Cut the track which connects the XIN pins to the original clock driver. In my case, the driver was an 18.4MHz oscillator which was fed into a divide-by-10 circuit on an 82C11 IC. There should not be any other pins left connected to the isolated XIN pins. (3). Choose one of the two UARTs to drive the new oscillator circuit (I’ll call it the ‘driver UART’). If you have July 1995  79 Fig.4: these diagrams show the PC pattern, component placement & drilling details for the D15 version of the circuit. (b) In the file: “/etc/rc.d/rc.serial: a socketed UART, use it as the driver. (4). Isolate the XIN pin of the driver UART. If you are cutting the track, make the piece of track attached to the driver UART XIN as short as possible. Since I had a socketted IC, I removed the IC from the socket and bent up the XIN pin, so that it became free standing. If your IC is not socketted, it is easier to cut the track to the chosen pin, rather than try to desolder the pin and bend it up. (5). Connect the XOUT pin of the driver UART to the XIN of the other UART. (6). Connect the oscillator circuit to XIN, XOUT and ground of the driver UART. add the lines: Testing the MIDI adaptor echo “Setting cua2,3 baud_base = 500k and divsor = MIDI on EXTB ...” >&2 The MIDI D-shell adaptor can be tested separately by making up a cable with a MIDI socket on each end. This can then be used to connect the MIDI-out to the MIDI-input of the adaptor (assum­ing you’ve put MIDI-plugs on the end of your cables, of course). Do not be concerned if the OnLine LED does not come on when you first Setting Up The Serial Card For Linux (a) In the file: “/etc/rc.d/rc.S” replace the line: # /bin/sh /etc/rc.d/rc.serial with: sleep 20 & TIMEOUT_PID=$! ( /bin/sh /etc/rc.d/rc.serial ; kill $TIMEOUT_PID ) & wait $TIMEOUT_PID ${SETSERIAL} /dev/cua2 baud_base 500000 divisor 16 spd_cust ${SETSERIAL} /dev/cua3 baud_base 500000 divisor 16 spd_cust if [ “`${SETSERIAL} -bg /dev/cua3`” != “” ]; then echo “Setting baud rate EXTB (spd_cust) on /dev/cua3 ...” >&2 stty raw -icanon -echo 38400 < /dev/cua3 fi 80  Silicon Chip es 0x03e8 and 0x02e8). Consult the documentation on your serial card for how to do this. I used IRQs 5 and 7 for the second serial card, since the parallel ports do not need to use interrupts unless you are using them as a network connection. Linux uses polling drivers for the printer ports by default, so this is a safe choice of IRQs. Fig.5: this external oscillator will need to be added to the UART on the serial I/O card in order to achieve the required 31,250 baud rate. Testing the serial card Testing the modified serial card is largely a matter of either it works or it doesn’t. If the oscillator refuses to oscillate, this is evident in that commands like ‘setserial’ and ‘stty’ will hang on the first use. If it doesn’t work, check all your work thoroughly and try varying the value of the capacitors in the oscillator circuit. Try reducing the values first, since there may be some stray capacitance to account for. Also try shortening the wires going to the oscillator circuit, as you may have made these too long. As a last resort, try using a lower frequency crystal, such as 4MHz. Testing the Sound Blaster adaptor (Linux OS) Fig.6: the Veroboard layout of the external oscillator. This is coupled between the XIN and XOUT pins of the UART on the serial I/O card. plug the adaptor into the computer. The CTS and DTR lines are under software control, and are often kept ‘low’ until the software actually tries to use the serial port. Any ordinary modem driver software, such as ‘Kermit’, can be used to test that the adaptor is working properly. Local echo should be off (off by default anyway). What you type in terminal mode is what you should see on the screen. (Remember that you have to type a ^J to get the cursor to move down the screen). This should work at all speeds up to and including 38,400 (EXTB). It can be useful to use a lower baud rate, in order to give a better indication on the LEDs. Serial card configuration Set up your serial card for COM3 and COM4 operation (ie, base address- It is not possible to use ‘Kermit’ to loop-test this adap­tor as Kermit refuses to recognise the MIDI device file (/ dev/midi) as a tty line. I used ‘seyon’ (another terminal program) instead, which gave a lot of warning messages, but worked anyway. For Linux, on the IBM PC, the operating system supports the ‘customised’ serial port very well. However, there are no appli­cations which you can use off-the-shelf. Given that the source-code is always readily available, this is not necessarily a problem. The major hurdle is that most of the applications writ­ ten for Linux use the /dev/sequencer pseudo-device to generate timing. The obvious solution is to modify the /dev/ sequencer driver to redirect output to a nominated serial port. I have been writing my own application which reads and writes the serial port directly. It uses system-exclusive messag­ es to control my keyboard parameters and this has been quite successful. For the Amiga, using Amiga DOS, the adaptor works with the same hardware as any other interface, so all SC normal MIDI software works. July 1995  81