bryce@hoser.berkeley.edu (Bryce Nesbitt) (12/20/87)
********************************************************
*** AmigaLine, technical notes for Amiga programmers ***
*** ***
*** Currently unofficial, but I hope the Commodore ***
*** picks up on the idea. ***
*** ***
*** You are encouraged to anthologize and distribute ***
*** these notes anywhere and everywhere. ***
********************************************************
----------------------------------------------------------------------------
Technical Note #1
serial.device, warnings on multiple ports & future changes
SUMMARY
$ 1/0 serial.device, warnings on multiple ports & future changes
$ RFC (request for comment)
$ 19-Dec-87 Bryce Nesbitt / Infinity Software
$ devices, multiple ports, serial.device, PICs, interrupts, cards
In the very near future extra serial port boards will be available for
the Amiga. For the benefit of everyone, the software should be ready
in advance. This note was prepared by the developers of the first
(one of the first?) multi-port boards.
----------------------------------------------------------------------------
We have taken great care to make the conversion to multiple ports
nearly painless for everyone involved.
USERS
The user will, at worst, need to drop an icon for the serial board into
the "Expansion" directory. At best the serial card will have
AutoConfigure ROMs.
PROGRAMMERS
Programmers must give the user the capability to select the unit number
to open the serial.device with. The built-in serial port will be unit
0. Additional serial ports will be numbered from 1 onward. There is a
hard limit of no more than 536,870,912 serial ports.
Your OpenDevice() call will look something like this:
error=OpenDevice("serial.device",unit,ioReqest,flags);
That's really all there is to it. Not too tough, eh?
HARDWARE DEVELOPERS
Any manufacturer may add as many serial ports as they wish. The drivers
will register with a public port named "serial.port". Your vectors
will be placed in a newly-expanded table. When a request is made to a
function like BeginIO(), the IO_UNIT will be indexed off of a jump
vector table. From that point onward you have control. Software latency
does not get worse with additional ports.
Form a hardware standpoint, all I need to say is "Interrupt Latency".
Perhaps we can come up with support for direct user-interrupt vectors.
For boards with lots of ports, a dedicated co-processor would be
appropriate.
NOTES
In the case were the user decides to switch units you must re-open the
serial.device with the new unit information. Don't forget to close the
old unit.
Some extra services will be available for the programmer. This will
probably include:
* A Query to determine the number of serial ports.
* A Query to determine the maxium baud rate of a unit.
* A Query to determine the manufactuer and product number of a unit.
* Timestamping for MIDI events.
If the return from OpenDevice() is non-zero then the open failed. This
could be due to any number of causes:
* The unit you specified does not exist.
* The unit is set to exclusive access and is busy.
* The serial.device could not be loaded.
* The system is out of memory.
Some of these errors will have new return codes. This will be fleshed
out fully in a future version of this tech note. For now just inform
the user of the failure to open the requested unit.
SEE ALSO
|\ /| . Ack! (NAK, SOH, EOT)
{o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci")
(")
U "Your theory is crazy... but not crazy enought to be true." -Niels Bohr