| I could make a case for a TT here, but the used Sun is likely to be
cheaper, and I'm not 100% sure of the status of Unix for the TT. I will
know soon and let you know.
Absolutely the best way to do the Serial ot Midi connection on the ST
is to hang at IPL 7 and poll the hardware. The interrupt latency at
these speeds is too large, and the midi port is unbuffered, and the
keyboard service routine takes more than a Midi character time to run.
If you want to accept full speed Midi, this is clearly the best way.
If you don't believe me, ask Mr. Miskinis, who also has a lot of
experience with this. It's possible to do this with interrupts, but you
have to take over the keyboard/Midi vector, and make sure the system's
keyboard routine never runs, because the keyboard service hangs at IPL7
for longer than a Midi character time. This results in overrun errors.
(I'm thinking of a scheme to get around this, but I haven't tried it yet.)
In any case, your biggest problem here will be flow control. It would
be best if you could set up link between the Atari and the Sun such that
you transmit to the Atari at 19,200, and receive at 38,400, since then
you wouldn't have to buffer anything. Since the ST can't do split speed
on the serial port, you will have to use 38,400 for both directions, and
rate limit the transmission from the Sun to Midi rate of 31,200. Also,
you should keep a buffer in the Atari in case the rate limiting has
occasional glitches that cause the data to come in bursts of a few bytes
each back to back.
If the Sun doesn't do 38,400, then use 19,200, and keep a large buffer
on the ST for incoming data, and hope it doesn't overrun. (It shouldn't
on real data, but it could in the "lab".)
|
| Oh, it's software buffered, but the Atari has trouble reading from the
midi port without data overruns, beacuse there is no hardware buffering.
When processing events from the keyboard, the keyboard service stays at
high IPL long enough to prevent getting back to the midi port.
The easy way is to write a small assembly program that goes to IPL 7,
and polls the MC6850 hardare directly for data, as well as the 68901
serial port.
|
|
The ACIA that handles input from MIDI/KEYBOARD only has a one byte
buffer, and that's what causes all these "problems"...
You'd be best to place your own routine at address (hex) 118, which
is called whenever a level interrupt is encountered. You could read
the byte out of the ACIA, and if it's a MIDI byte, send it out
the RS232 port...
The downside of this is that normal keyboard/mouse/joystick bytes
(as well as MIDI) would not get to their "normal" place. This
then would prevent other applications from being run concurently...
_John_
P.S. Has anyone ever got LINEAE (raster copy) to work? I'm frustrated!
|
| Well I have some progress to report. I have the program written that
passes data between the midi and serial ports. Initial tests (me
playing quickly on a midi keyboard and small sysex messages) showed no
loss of data.
I did find one problem:
When I implemented a "midi-echo" program on the Sun, I got 2 notes out for
every note sent in. As it turns out, the atari implements a midi-thru
by tying 2 unused pins (1 & 3??) to the real midi pins (4 & 5). For
whatever reason, my roland d-110 recognized the signals on the renegade
pins as well as the signals on the correct pins. So of the 2 notes that
I got back, 1 was from the atari hardwired pins, and the other was
echoed from the sun. This was a problem. The solution (one of several)
is to run midi out from the atari to my pocket merge. The pocket merge
seems to not propagate the renegade pins.
Can anyone verify that the atari is supposed to implement a midi-thru
in hardware? Does anyone know why a roland d-110 recognizes data on
non-standard pins? Does anyone know what's inside a pocket merge?
thanks,
Jim
|