Path: utzoo!attcan!uunet!crdgw1!rpi!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga
Subject: Re: Come on PEOPLE...
Message-ID: <9725@batcomputer.tn.cornell.edu>
Date: 14 Feb 90 17:31:57 GMT
References: <1990Feb12.223912.7167@ug.cs.dal.ca> <13570019@hpspdra.HP.COM>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 37

In article <13570019@hpspdra.HP.COM> ric@hpspdra.HP.COM (Ric Peregrino) writes:
>Concerning the serial port. I have an Amiga 2000 and more importantly I have
>the hardware manual. In the manual you'll find the information needed to
>interface to the serial port.
>
>Personally, I was able to write code to read from the serial port and output
>to the screen- string to tell if data "ok" or if "overrun" occured;
>               number of bytes received before timeout (if no overrun);
>               data received;
>
>I used this to get MIDI data from a sampler. It entailed:

[goes on to describe a lot banging on custom chip registers and interrupt
disabling]

For 99% of all applications, this is completely the wrong way to access
the serial port.  There are system routines for managing the serial
device in a multi-tasking friendly manner, which should be used *whenever*
possible.  Reading MIDI sysex and MIDI sample dumps is just about the only 
exception I know of, since the Amiga will otherwise drop bytes on large
transfers with the current software and hardware.

Even then, commercial software (or quality PD) should allocate the serial 
port interrupt before banging away at the hardware, and should give the 
user the option of going through the system software in case she's using a 
third party serial board or a later rev of the system software which does 
keep up with MIDI data rates without dropping bytes on large transfers.

[mini-flame coming up]
If you want to be quick and dirty, you can write 0x7fff to INTENA in the
privacy of your own home;  I've been known to do kluges like this from 
time to time.  But *don't* release software like that, and don't encourage 
other people to do it.  It's the wrong way to do things on a multi-tasking
system, and it ties you completely to the current system hardware.

-Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley)
-Wilson Lab, Cornell University