simple MIDI?

Magnus Danielson magnus at
Tue Jan 20 21:25:38 CET 1998

>>>>> "S" == Stopp,Gene  <gene.stopp at> writes:

 S> I've scribbled many such circuits on paper, just kicking around
 S> ideas....

 S> I thought I had a drawer full of 6402's in the garage, but no such luck.
 S> Those chips are so old that it's even hard to find a datasheet. The 6402
 S> (as mentioned in another post lately) would be great for such
 S> applications - all the signals needed for async send/receive come out to
 S> pins, no programming registers. Perfect for "dumb" projects.

The old 6402 seems to kick out whenever a really dumb UART is needed.

Even if it is not directly comparable I think that the 6850 is a good
little thing to consider for many projects. Feed it with a 1 MHz clock
and it will happly make an MIDI IN/OUT UART with setting some fix
values once.

 S> For lack of a 6402, I once programmed an Altera EPLD to act as a UART to
 S> receive MIDI sync bytes and output start/stop/continue pulses as well as
 S> a bunch of divided clock outputs. I created the UART out of a shift
 S> register for serial-to-parallel conversion (using some way of assuring
 S> proper byte framing, I can't remember the exact approach), and a bunch
 S> of gate logic to detect different bit patterns and do the appropriate
 S> thing. Also included was a pre-scaler to get 31.25 kbps out of an
 S> external crystal. The whole mess would have consumed a huge amount of
 S> vectorboard real estate, something I would never have done to achieve
 S> such a simple task, but in an EPLD you just draw schematics on the PC
 S> and burn it into the chip so chip count isn't an issue.

 S> I still have the chip somewhere, on a little circuit board, but I've
 S> never actually tried it in a MIDI setup. I know I did test it on the
 S> bench when I created it, however, and it seemed to work.

One kind of sick way of doing it in CMOS and analogue would be to make
a cursuit that builds up around a 4067, a 4040, some capacitors (for
S/H) and a HC373 or similar. But then again, you could probably come
up with something better, cheaper and more reliable than that ;)

 S> It's farily easy to envision an simple transmitter - just a
 S> parallel-to-serial shift register clocked by a counter running at 31.25
 S> k, which scans once through the count when triggered and sits at rest
 S> when not triggered. You can set up the parallel pins for the bits in the
 S> byte, adding a start bit to the front and one or more stop bits at the
 S> back. I've seriously considered making a simple Note-On/Note-Off
 S> generator for a drum interface, but I just never get around to it. It's
 S> getting to the point in my life where I'd almost rather pop for the $325
 S> and get an Alesis DM5 - external drum triggers to MIDI plus a lot of
 S> sounds as well. But that's no fun, right?

No. Doing an Note-On/Note-Off should be simple enougth for non-CPU
solutions to deal with. I just wonder how many MIDI messages that one
could force into hardware without a CPU... wait - stop me before I do
them all! As it happends will the decoding of MIDI dealing with
running status correctly and everything become a fairly simple
statemachine, so it is more a matter of implementing it into something.

 S> Receiving is more difficult - it's not much harder to make a UART
 S> receiver, but once you frame a byte you need to decide whether it's one
 S> you want to act on or discard. Plus you get running status and clocks in
 S> the middle of messages.... it can get real ugly without a CPU in there
 S> somewhere. Some years ago I wrote a decent MIDI protocol stack, and I've
 S> decided that as long as I have that, I might as well stick to code when
 S> it comes to receiving MIDI and acting on it.

It's a bit hairy, but it is certainly solveable. I think that we have
touched the subject before. Maybe a EPROM to look-up the action and
use feedback so that the state-machine table sits in the EPROM?

 S> So - without a CPU, I think that transmitting is easier than receiving,
 S> and a hard-wired UART chip is easier than a discrete transmitter, so
 S> little message-senders like percussion controllers are probably fairly
 S> do-able. Anything more complicated than that and I'd go with some
 S> number-cruncher.

The number chrunchers certainly has their advantages in this case.
I would probablly consider an PIC for their relative cheapness and for
their lack of many external components. I have a friend that would go
for the Z8 with BASIC for it's simplicity of interfaceing (6 pins and
you have it hooked to a serial port up an running... and a tiny BASIC
sitting there.... ). The 8742 or similar isn't bad either, it takes
quite some studying of the databooks to find out all the peculiar
details, but I have done the excerise and found it not too repulsive.
Also, if you want to use it as a tone generator/sample player with
fairly good precison (max +/- 0.025 cent of over all 128 MIDI notes
with all 0 to 99 cent pitchings considered) I can recommend some
tricks and can dig up some example code that I did....

The worst things about CPUs is that they often aid bad programmers in
being just bad programmers... it is allways so easy to fix broken
programs rather than make a deep thougth on how to make them work the
first time instead... ah well...


More information about the Synth-diy mailing list