home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 508.lha / IO_Expansion_Board / Docs / Software.man.pp / Software.man
Encoding:
Text File  |  1991-05-06  |  10.6 KB  |  237 lines
  1. 16 March 1991
  2.  
  3.                        Software Installation Manual
  4.  
  5.                      For the Amiga I/O Expansion Board
  6.  
  7.                    Copyright ©1990,91 The Puzzle Factory
  8.  
  9.  
  10. Hardware is next to useless without  software  to  drive  it.   This  section
  11. describes  the  software  available for the I/O Expansion Board.  Please note
  12. that  although  every  effort  has  been  made  to  ensure  completeness  and
  13. compatibility,  this  is a Public Domain project.  All of the people who have
  14. created hardware or software for this project have done  so  in  their  spare
  15. time  without remuneration other than glory.  If you experience problems with
  16. the software, try to smile a lot and consider helping  to  write  an  updated
  17. version.   In  any  case,  please  contact  us  if   you   find   any   major
  18. incompatibilities or bugs.
  19.  
  20. *****************************************************************************
  21. * Note well that all of this material, although freely  redistributable, is *
  22. * copyrighted.  All rights are  reserved, and none of these programs may be *
  23. * used commercially without prior written permission from the author(s).    *
  24. *****************************************************************************
  25.  
  26. In the following sections, "###" in the leftmost columns is used to  indicate
  27. some  action  that  must  be  taken  to  achieve  a  particular goal.  Unless
  28. otherwise noted, all programs herein MUST be run from the CLI!   Do  not  use
  29. with Workbench, or attempt to create icons!
  30.  
  31. All mention of units in this document refer to  physical  units.   The  first
  32. physical  ACIA is Unit 1, for example.  This corresponds to logical Unit 0 of
  33. the newser.device.
  34.  
  35.  
  36. THE SERIAL DRIVER
  37. =================
  38. Almost all programs written for the Amiga that use the serial port (with  the
  39. notable  exception of some MIDI software) access it indirectly via a standard
  40. software module called "serial.device".  As a result, most existing  software
  41. will work fine with the I/O Board given a suitable driver, and we supply one,
  42. named  "newser.device".
  43.  
  44. The newser.device supports 15 standard baud rates, from 50  to  38,400  baud,
  45. plus  MIDI (31,250 baud).  It also supports full hardware handshaking.  Up to
  46. four units may be open at one time, although the cpu may not be able to  keep
  47. up with all four units running above 2400 baud.
  48.  
  49. ### Copy newser.device to your "DEVS:" directory and you're in business.
  50.  
  51. NOTES:
  52. 1. In order to use the MIDI baud rate, all three of the following things must
  53.    be done for MIDI to function properly.:
  54.  
  55.    a) The MIDI clock on the I/O Expansion Board must be installed.
  56.    b) The jumper, either J1 or J2 depending on the unit, must be in the MIDI
  57.       position.
  58.    c) The baud rate must be set to MIDI, corresponding to %xxxx1111 in the
  59.       appropriate control register.
  60.  
  61. 2. In order to use the serial ports in 3-wire mode, one of two things must be
  62.    done:
  63.  
  64.    a) Install R1 and R2, 1K 1/4W resistors on the Serial Interface Board.
  65.    b) Connect CTS to RTS.
  66.  
  67.    Either fix is used to pull up CTS, and is only necessary if  you  will  be
  68.    connecting  the  serial  port  to  a device that does not assert CTS.  The
  69.    65C52 will not transmit if CTS is not asserted.  This  is  implemented  in
  70.    hardware and must be addressed in hardware.
  71.  
  72. THE PARALLEL DRIVER
  73. ===================
  74. The four parallel ports on the I/O Expansion  Board  are  controlled  by  the
  75. eightbit.device.   There are no known differences between this device and the
  76. V1.3  parallel.device.   Applications  should  not  experience  any  problems
  77. communicating with the eightbit.device on the device level.
  78.  
  79. ### Copy eightbit.device to your "DEVS:" directory and you're ready to go.
  80.  
  81.  
  82. DOS-LEVEL SUPPORT
  83. =================
  84. "DOS-level support" refers to the ability to get and send data via the serial
  85. and parallel ports with standard AmigaDOS commands, such as TYPE or LIST,  or
  86. with  any  program that does serial or parallel I/O via AmigaDOS, rather than
  87. directly via the Exec-level "newser.device"  or  "eightbit.device".  Although
  88. this  sort  of  capability  is not frequently used, it is useful from time to
  89. time.
  90.  
  91. In a perfect world,  DOS-level  support  would  mean  nothing  more  than  an
  92. appropriate  MountList  entry, specifying a driver name of "newser.device" or
  93. "eightbit.device", and some unit number of your choosing, corresponding to  a
  94. DOS  name  such  as  "SER1:" or "PAR2:".  Unfortunately, Commodore supplied a
  95. version of the Port-Handler and Aux-Handler with Workbench V1.3 that  doesn't
  96. permit  this;  rather,  they're  hard-coded  to use either "serial.device" or
  97. "parallel.device".  The printer.device suffers from a similar limitation.  At
  98. the time of this writing, we don't have a solution to the  problem  with  the
  99. printer  driver,  other  than  using  IOpatch.
  100.  
  101. We do have a port handler, however.  It's named "ioexp-handler".
  102.  
  103. ### Copy ioexp-handler to your "L:"  directory.
  104. ### Copy the supplied mountlist to "DEVS:".
  105.  
  106. Now you can do things like:
  107.  
  108.   1> Type <MyFile> to SER1:
  109.   1> Copy <MyFile> to PAR2:
  110.  
  111. The handlers in Workbench V2.0 have the capability  to  use  any  device  and
  112. unit, so this whole problem becomes non-existent under V2.0 of the OS.
  113.  
  114. NOTES:
  115. 1. The  names  in  the  current  port  handler  are  hardcoded  (sorry).  The
  116.    MountList entries must be named "SER1:", "SER2", "PAR3:",  etc.   We  will
  117.    release an update for this when and if this problem is resolved.
  118.  
  119.  
  120. SUPPORT PROGRAMS
  121. ================
  122. Several programs are available for use with the I/O Expansion Board.
  123.  
  124. SERprefs
  125. --------
  126. SERprefs  functions  much  the same as the serial section of Preferences, but
  127. allows  you   to   set  and  save  parameters  for  all  four  units  of  the
  128. newser.device.  These are saved in "S:Serial-Preferences".
  129.  
  130. ### Copy SERprefs to C: or somewhere in your execution path.
  131.  
  132. IOpatch
  133. -------
  134. Many programs allow you to specify the device name and unit number,  so  that
  135. using  an alternate device driver is no problem.  For those applications that
  136. insist on using a particular device, we  have  written  a  nice  little  hack
  137. called  IOpatch.   This program SetFunction()s the exec OpenDevice call.  The
  138. user puts this program in his  startup-sequence,  or  otherwise  invokes  it,
  139. before  he runs his application program.  This patch will make a small window
  140. appear, whenever OpenDevice() is called, with a choice of units; 0-4.  Unit 0
  141. will select the internal serial or parallel port, and units 1-4  will  select
  142. one  of  the  newser.device  or  eightbit.device units.  Please note that the
  143. names of both drivers have been selected to be the same length as  the  names
  144. of  the original devices.  This has been done to facilitate file-zapping as a
  145. last resort.  Of course, software may be written that names the newser.device
  146. or eightbit.device specifically.
  147.  
  148. ### Copy IOpatch to C: or somewhere in your execution path.
  149.  
  150. From the command line, simply type:
  151.  
  152.   1> IOpatch
  153.  
  154. There is no need to RUN, because IOpatch copies itself  to  ram;  no  seglist
  155. splitting either!  Once installed, IOpatch will check all calls to OpenDevice
  156. to  see  if  the  device is the serial or parallel device.  IOpatch takes the
  157. following command line arguments:
  158.  
  159.   1> IOpatch       ;Check OpenDevice() calls for serial & parallel device
  160.   1> IOpatch -a    ;Check OpenDevice() calls for serial & parallel device
  161.   1> IOpatch -s    ;Check OpenDevice() calls for serial device only
  162.   1> IOpatch -p    ;Check OpenDevice() calls for parallel device only
  163.   1> IOpatch -q    ;Replaces previous vector for OpenDevice() calls.
  164.   1> IOpatch ?     ;Prints these instructions
  165.  
  166. Now, every time a program wants to use the serial  or  parallel  device,  you
  167. will  be presented with a little window to select which unit you wish to use.
  168. IOpatch will always open on the application's screen.  Select Unit 0  to  use
  169. the  internal  serial  or  parallel  device.   Select  Unit  1-4  to  use the
  170. newser.device or eightbit.device.  Now you can do things like:
  171.  
  172.   1> Copy <MyFile> to SER:   ;Click on Unit 1 selects newser.device Unit 1.
  173.   1> Type <MyFile> to PAR:   ;Click on Unit 2 selects eightbit.device Unit 2.
  174.   1> List >PRT: <MyDir>      ;Click on Unit 3 selects eightbit.device Unit 3.
  175.  
  176. These examples assume that you select other than Unit 0.
  177.  
  178. NOTES:
  179.  
  180. 1. IOpatch and the eightbit.device have been verified using Deluxe Paint III.
  181.    under V1.3 of the OS.  A 640x768 file was printed to a Panasonic KX-P1092i
  182.    with good results.
  183.  
  184.  
  185. Test
  186. ----
  187. A suite of simple test programs to check the I/O Expansion Board Hardware can
  188. save you hours of hardware debugging time.
  189.  
  190. IOSetup writes recognizable bit patterns into the registers so that  you  may
  191.         verify that they are, in fact, addressable and  working.   The  chips
  192.         are set up as follows:
  193.  
  194.         VIA0:  Both ports=outputs, ORB=$12, ORA=$34
  195.         VIA1:  Both ports=outputs, ORB=$56, ORA=$78
  196.         ACIA1: 2400 baud, 8 bit word, 1 stop bit, no parity, DTR hi, TDR=$0D
  197.  
  198. IOPrint prints the contents of the registers for all 8 units on the  console.
  199.         If you are not planning to add Unit 3-4, it would be a good  idea  to
  200.         reassemble the program to print registers for Unit 1-2 only.
  201.  
  202. IOTest is actually 9 tests in 1 program.  Selected by command line  argument,
  203.         tests 1-8 generate chip selects and read/write signals as follows:
  204.  
  205.         1 = Read  VIA0   3 = Read  VIA1   5 = Read  ACIA0   7 = Read  ACIA1
  206.         2 = Write VIA0   4 = Write VIA1   6 = Write ACIA0   8 = Write ACIA1
  207.  
  208.         Test 9 simulates a very simple  character-oriented  terminal  program
  209.         for checking the operation of ACIA0.
  210.  
  211. PARtest tests the 65C22.  This program takes a filespec as its only argument,
  212.         and stuffs the file out parallel  Port  3  (VIA  #1,  Port  A)  to  a
  213.         printer.   No  devices are involved; this goes right to the hardware.
  214.         Also, in this version, interrupts  are  not  used  -  handshaking  is
  215.         accomplished by hardware polling.
  216.  
  217. Time  is  a  nice  little  program to drive a real-time clock-calendar.  Time
  218.         takes one command line argument:
  219.  
  220.         1> Time S=SET     ;Sets clock from system date.
  221.         1> Time R=READ    ;Sets system date from clock.
  222.  
  223. ### Copy Time to C: or somewhere in your execution path.
  224.  
  225.        The clock hardware, based on the  OKI  MSM5832,  is  also  capable  of
  226.        generating interrupts at 1024 hz, once per second, once per minute, or
  227.        hourly.   This feature can be very useful, as no software counters are
  228.        required to generate  long  delays.   A  must  for  real-time  control
  229.        programs.
  230.  
  231.        If the clock does not physically exist, you will likely get a  message
  232.        from  the program: "Can't convert to DateStamp".  This generally means
  233.        that the date string  returned  from  the  non-existant  hardware  was
  234.        garbage.
  235.  
  236. =eof=
  237.