home *** CD-ROM | disk | FTP | other *** search
/ Frozen Fish 1: Amiga / FrozenFish-Apr94.iso / bbs / alib / d1xx / d138 / amigaline.lha / AmigaLine / AmigaLine1 < prev    next >
Text File  |  1988-03-20  |  3KB  |  89 lines
  1.             Technical Note #1
  2.       serial.device, warnings on multiple ports & future changes
  3.  
  4. SUMMARY
  5.  
  6. $ 1/0 serial.device, warnings on multiple ports & future changes
  7. $ RFC (request for comment)
  8. $ 19-Dec-87 Bryce Nesbitt / Infinity Software
  9. $ devices, multiple ports, serial.device, PICs, interrupts, cards
  10.  
  11.     In the very near future extra serial port boards will be available for
  12.     the Amiga.    For the benefit of everyone, the software should be ready
  13.     in advance.  This note was prepared by the developers of the first
  14.     (one of the first?) multi-port boards.
  15.  
  16.  
  17. ----------------------------------------------------------------------------
  18.  
  19.     We have taken great care to make the conversion to multiple ports
  20.     nearly painless for everyone involved.
  21.  
  22.  
  23. USERS
  24.  
  25.     The user will, at worst, need to drop an icon for the serial board into
  26.     the "Expansion" directory.  At best the serial card will have
  27.     AutoConfigure ROMs.
  28.  
  29. PROGRAMMERS
  30.  
  31.     Programmers must give the user the capability to select the unit number
  32.     to open the serial.device with.  The built-in serial port will be unit
  33.     0.    Additional serial ports will be numbered from 1 onward.  There is a
  34.     hard limit of no more than 536,870,912 serial ports.
  35.  
  36.     Your OpenDevice() call will look something like this:
  37.  
  38.     error=OpenDevice("serial.device",unit,ioReqest,flags);
  39.  
  40.     That's really all there is to it.  Not too tough, eh?
  41.  
  42.  
  43. HARDWARE DEVELOPERS
  44.  
  45.     Any manufacturer may add as many serial ports as they wish.  The drivers
  46.     will register with a public port named "serial.port".  Your vectors
  47.     will be placed in a newly-expanded table.  When a request is made to a
  48.     function like BeginIO(), the IO_UNIT will be indexed off of a jump
  49.     vector table.  From that point onward you have control.  Software latency
  50.     does not get worse with additional ports.
  51.  
  52.     Form a hardware standpoint, all I need to say is "Interrupt Latency".
  53.     Perhaps we can come up with support for direct user-interrupt vectors.
  54.     For boards with lots of ports, a dedicated co-processor would be
  55.     appropriate.
  56.  
  57.  
  58. NOTES
  59.  
  60.     In the case were the user decides to switch units you must re-open the
  61.     serial.device with the new unit information.  Don't forget to close the
  62.     old unit.
  63.  
  64.  
  65.     Some extra services will be available for the programmer.  This will
  66.     probably include:
  67.  
  68.     * A Query to determine the number of serial ports.
  69.     * A Query to determine the maxium baud rate of a unit.
  70.     * A Query to determine the manufactuer and product number of a unit.
  71.     * Timestamping for MIDI events.
  72.  
  73.  
  74.     If the return from OpenDevice() is non-zero then the open failed.  This
  75.     could be due to any number of causes:
  76.  
  77.     * The unit you specified does not exist.
  78.     * The unit is set to exclusive access and is busy.
  79.     * The serial.device could not be loaded.
  80.     * The system is out of memory.
  81.  
  82.     Some of these errors will have new return codes.  This will be fleshed
  83.     out fully in a future version of this tech note.  For now just inform
  84.     the user of the failure to open the requested unit.
  85.  
  86. SEE ALSO
  87.  
  88.  
  89.