Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!hollie.rdg.dec.com!ryn.mro4.dec.com!aisg.enet.dec.com!miskinis
From: miskinis@aisg.enet.dec.com (John Miskinis)
Newsgroups: comp.sys.atari.st.tech
Subject: MIDI (continued)
Message-ID: <3979@ryn.mro4.dec.com>
Date: 15 Feb 91 17:43:15 GMT
Sender: guest@ryn.mro4.dec.com
Organization: Digital Equipment Corporation
Lines: 67


Hello,

	I've received numerous replies from people on the USENET who I
wish to thank for their time and effort...

	Perhaps I should have stated up front exactly what I have done
in the past 2 years leading up to my recent postings, the documentation I
have purchased, etc..

	I've been an Atari customer for several years, beginning with their
8-bit line, and then "blowb away" with the capabilities of the ST, which
I had to have right away, for it's graphics and MIDI architecture.

	I began developing a sequencer shell, orginally in Pascal, and
later ported to C.  All coding was done in "C", and MIDI I/O was performed
exclusively via the BIOS and XBIOS functions.   The exclusion was a timer
routine that ran in the backgound, thus providing me with a timestamping
metric.  Each byte had a time stamp as to when it came in relative to the
beginning of the sequence.  And you know what?  It worked perfectly (so
I thought).  I had musician friends over now and then, who were amazed
at the accuracy of a "home grown" application, and were frustrated that
they could not crash the program by wiggling the bender, stepping on the
pedals, and placing their entire forearm on the keys.

	I had a 5-octave keyboard on the screen, lighting a rectangle in
each key when it was "on", and unlighting it when it was "off".   Once
or twice a month I then noticed that a key would remain on, when it's
midi note value was specifically turned off.   I then questioned the validity
of my earilier recordings, and proved a few of them invalid by using a non
decaying synth sound.  I had earilier used piano sounds, which would decay
ANYWAY, whether or not a not off message was ever received!

	SO, then I started experimenting, and removed  ALL code except what
was need to record a byte from the MIDI port each time it came in.  I even
eliminated the background timer to be sure that it was not interferring.

	I wrote routine that would scan my data, looking for corruption.
I noticed that when a byte was WRONG, it was a copy of the last on, and
one was missing (the interrupt fired, but the previuos byte was still in
the ACIA buffer.

	I then learned 6800 assembler, and wrote a routine that emulated the
BIOS MIDI functions, and had the EXACT SAME PROBLEM.  I then added code to
check the ACIA status, and found that there were overruns.  I had been using
the KBD vector MIDISYS to point to my interrupt routine, which is really
only as good as the routine that IT is called from, being the standard
level 6 interrupt handler, which handles keyboard, mouse, and MIDI I/O.

	I currently have "The Tackle Box" (~900 pages containing the
full docs for the 68000, 6850, etc.), Mark Williams C, The Abacaus
Atari ST Internals book, the Sybex Programmer's guide to GEM, and various
magazines.

	I want to overcome the problems with the current interrupt structure
of the ST, and if I have to write my own code to handle the mouse and keyboard
as well as MIDI, I don't mind doing that.   That way I can control the priority
of the devices, and not spend time handling the mouse or keyboard when it
would effect MIDI I/O that I deem the most important task in recording.

	I ask that you Post instead of replying by mail, so everyone can
benefit from this invaluable discussion.  There is little or no other source
of public information that I cam aware of.  If there is, LET ME KNOW!

Thanks, and Atari Forever!

_John_ (sick with the flu, pardon my rambling in some spots)