My experience with this company has been distinctly unpleasant. They are unwilling to share the kind of technical data that one needs to program this device without their own software. Seeing as they only write software for Windoze and Macintosh, this is an irritating situation. Their technical support people I found to be rude and unhelpful, when they would even answer the phone (I usually got a busy signal when I tried to call). I had to argue a while with them before they would even talk to me because somehow my registration card was "lost", and apparently customers who aren't "registered" aren't important to them. I finally did get a name of some higher up person, somebody that I could argue with some more, but the person was always "unavailable", "on the phone", etc. and never did return any of my calls. Their whole attitude is silly, because you can learn all of this information with a couple of hours and an oscilloscope.

One thing that I did get from them with relatively little pain is the documentation of their System Exclusive messages. This packet is about twenty pages long, and it looks like it might be a section of a larger manual. It isn't bound or anything. It looks like somebody just printed this small section and sent it to me. This documentation is very useful, if not required, for programming the device. My driver doesn't know very much about the actual bytes going back and forth, it just knows the hardware protocol.

The only Mark of the Unicorn product that I own is a Midi Express XT, for which this data is valid. It works for me, anyway. I don't know how their other products work. If you do, please let me know so I can update this information.

The Midi Express XT attaches to a PC through a standard parallel port. The parallel port runs in "compatible" or "SPP" mode. New features found in most parallel ports these days (EPP and ECP) are not used. As a matter of fact, sometimes problems occur when those modes are enabled in the parallel port hardware. Most reliable performance happens for me when the EPP and ECP modes are disabled in the BIOS, leaving only a SPP port. MOTU engineers decided to use a completely unstandard pinout convention for some reason. The following table shows the pinout, as determined experimentally by me. The left column shows the register name and bit (control register and status register). Bits not shown in the table are unused by the parallel hardware itself. C0 and C1 are used by most hardware that connects to the parallel port, but are unused by the Midi Express XT. The names is my own invention; I don't have any idea what MOTU engineers use. (pin numbering & data port added 10/23/99 prefect)

Write Timing

The timing diagram shows a sequence of three bytes (a note on message, for example) being written from the host to the Midi Express XT. The signals are shown as they appear at the connector. Notice that the parallel port hardware inverts S7, C0, C1, and C3, which include signals READ and RFD in my naming scheme. So, your driver code will actually read and write the inversion of those particular signals. It is unfortunate that MOTU didn't keep with the convention of using C0 as the strobe. This makes it impossible to come out of the PC dark ages and use the newer EPP capability of most modern parallel ports. Notice that the WRITE strobe is active low, even though the parallel port hardware does not explicitly invert C2.

I never discovered any minimum timing requirements in my experiments. The pulses from MOTU's own software are about 5us long and 5us apart. My driver just pulses them as fast as possible, so they are about 2us wide on my Pentium-233. This seems to work just as well. Please let me know if you try this and encounter timing errors.

The write logic of my driver is as follows:

1. Poll RFD until it is asserted (with a timeout condition, of course).
2. Read control register, so later on a single bit can be toggled without disturbing anything else.
3. For each byte in a multibyte message (a message could be a note on, a properly framed system exclusive, etc.):
   1. Write byte to data port.
   2. Clear WRITE bit. (C2)
   3. Set Write bit. (C2) (No explicit delay required.)
4. Wait for RFD before sending the next multibyte message. I don't think that RFD will ever unassert in the middle of a message, but it might in between messages.

Read Timing

The next timing diagram shows a single byte being read by the host from the Midi Express XT. The tricky part about the read is that the byte comes two bits at a time through the status port. This protocol is extremely unconventional. All modern parallel ports have bidirectional data lines, and it would have been a lot easier and more efficient to use those instead. Luckily, most MIDI applications won't consume much bandwidth, so this kludge is tolerable.

The read logic of my is driver is in the interrupt handler as follows:

1. Interrupt on IRQ (S6). Don't forget to enable interrupts first (INTEN, or C4).
2. Read the status register and check for BYTE (S3) to be asserted. The Midi Express XT interrupts quite often (every 256 microseconds?) and it isn't always a data byte. These other interrupts may be timing information; I haven't figured it out yet. If BYTE is asserted, however, you can proceed with the read operation. If not, just exit the interrupt handler.
3. Read the control register, so later on a single bit can be toggled without disturbing anything else.
4. For each 2 bit "word" in a byte (for a total of four times):
   1. Assert READ (C3). The Midi Express XT will respond by asserting a status byte.
   2. Read the status register, and record bits IN0 and IN1 (S4, S5).
   3. Unassert READ.
5. Assemble the four sets of two bits into an eight bit byte.
6. Read the status register. If BYTE (S3) is still asserted, go to step 4. Otherwise, store/use the byte and exit the interrupt handler.