

























                     Pascal 3.23 Investigation Report

                             _O_c_t_o_b_e_r _1_9, _1_9_8_9

                             Jeff Hendershot

                             David P. Willis

                  Hewlett Packard; Colorado Language Lab


































       Pascal 3.23           October 19, 1989                     2



       1.  SSSSCCCCSSSSIIII IIIInnnnvvvveeeessssttttiiiiggggaaaattttiiiioooonnnn RRRReeeeppppoooorrrrtttt

       1.1  WWWWhhhhyyyy ddddoooo SSSSCCCCSSSSIIII

       SCSI (Small Computer Systems Interface,  pronounced  scuzzy)
       disk  drives  are  becoming more and more popular.  The SCSI
       disk market "is one of the highest growth product  lines  in
       the  industry  with  an  annual growth of 32% compounded per
       year." [1]

       In addition, SCSI as  a  whole  is  becoming  more  popular.
       "Marketing data predicts that by mid-1989, approximately one
       half of all UNIX workstations will have a  SCSI  interface."
       [2] Similar marketing data for PWS and RMB does  not  exist,
       but trends in S300 development should not be ignored.

       The Compass machine, a S300 50Mhz 68030 SPU  due  out  12/89
       [3], will  come  standard  with  a  LAN  interface,  but  an
       optional  interface  can  be  purchased  that will have LAN,
       RS422, Centronix, _a_n_d _S_C_S_I.  _H_P-_I_B _w_i_l_l _n_o_t _b_e _a_v_a_i_l_a_b_l_e.

       The Apex machines, the S300 68040 based SPUs  due  out  5/90
       [4], comes optionally with an internal 600Meg  optical  disk
       drive and/or up to 2 internal 3.5" 200M or 100M hard drives.
       _S_C_S_I _i_s _t_h_e _o_n_l_y  _i_n_t_e_r_f_a_c_e  _t_h_a_t  _s_u_p_p_o_r_t_s  _t_h_e_s_e  _i_n_t_e_r_n_a_l
       _d_i_s_k_s.

       Seeing an internal optical disk drive on the next generation
       S300  is  not to surprising.  There is a move afoot to place
       an optical disk drive on all S300 and S800 machines, and use
       it as a software distribution medium  [5].   Industry  wide,
       _S_C_S_I _i_s _t_h_e _d_r_i_v_e _o_f _c_h_o_i_c_e _f_o_r _o_p_t_i_c_a_l _d_i_s_k_s.

       Marketing  incentives  make  equivalent  SCSI   disks   more
       attractive  than HP-IB disks.  For example, the 7959S (SCSI)
       lists for $500.00 less  than  the  7959B  (HP-IB).   (7959S:
       $7225 vs. 7959B: $7725 [6]) The price gap between SCSI disks
       and HP-IB disks is expected to grow wider.

       Industry Standardization and an exceptional feature  set  is
       what  is  making  SCSI  so  popular today.  SCSI offers easy
       connectivity to many manufacturer's peripherals  because  of
       the ANSI standard [7] and the  complimentary  industry  SCSI
       Common Command Set (CCS) [8].

       1.2  WWWWhhhhaaaatttt SSSSCCCCSSSSIIII iiiissss

       SCSI is an I/O bus designed to "provide host computers  with
       device  independence  within  a  class  of  devices.   Thus,
       different disk  drives,  tape  drives,  printers,  and  even
       communication  devices  can  be  added to the host computers











       Pascal 3.23           October 19, 1989                     3



       without requiring modifications to generic  system  hardware
       or software." [7]

       SCSI is a "System Level"  interface,  using  standard,  high
       level  commands  that  are  transported  from  the host to a
       peripheral.  These commands form  the  origin  of  all  data
       transfer on the SCSI bus.

       SCSI allows up to 8 devices on its bus, in  any  combination
       of  hosts  and  targets  (a target, generally speaking, is a
       peripheral such as a disk).   All  devices  can  communicate
       directly with one another.

       A popular and prominent feature of the  SCSI  definition  is
       distributed arbitration [9].  That is, when a target  device
       anticipates  a  considerable  delay  before  being  able  to
       complete a command (perhaps due to a head seek), the  target
       device  can disconnect from the bus and reconnect when it is
       ready to continue.   During  the  disconnect  the  host  (or
       another host) can initiate commands with SCSI devices.

       Distributed   arbitration   increases    bus    utilization.
       Generally,  system  designers  regard  30%  bus  usage  as a
       maximum before system performance begins  to  degrade.   Bus
       usage  is  a  measure  of  the  time  the  bus  is  actually
       transmitting data. Tests using  the  SCSI  bus  system  have
       shown a maximum of 50% bus usage. [10]

       Finally, SCSI offers high data-transfer rates.  SCSI  offers
       two  bus  protocols  that  can  be  used  to  transfer data:
       Asynchronous data transfer and  Synchronous  data  transfer.
       Asynchronous   data  transfer  is  the  default  method  and
       provides a data transfer rate of 1.5 Mbytes/sec.

       Synchronous data transfer must be agreed  upon  between  the
       host  and  the  target device and certain boundaries must be
       set.  This method can transfer up to 4 Mbytes/sec.

       I have found that SCSI maps well onto the  Physical  through
       Transport layers defined in the Open Systems Interconnection
       Reference Model  (OSIRM).   For  review,  each  OSIRM  layer
       definition is shown in Figure 1.

       To provide a high degree of  device  independence,  SCSI  is
       defined  from the physical layer through the Transport Layer
       in one document, the ANSI SCSI standard [7].   In  addition,
       these  layers  are  purposely  interdependent;  requiring  a
       device driver which  interfaces  on  the  SCSI  I/O  bus  to
       support  all  layers.   For  example,  the  highest layer of
       functionality defined in SCSI would be the Transport  Layer.
       This  is  where  commands  are  defined that allow a Session











       Pascal 3.23           October 19, 1989                     4



       Layer to transport data to and from another  device  on  the
       bus.   However  at  the  data  link  layer  (just  above the
       physical), a command can  not  be  transmitted  on  the  bus
       unless the bus is in a 'Command Phase'.  In fact, one of the
       bus control lines  definition  is  Command/Data.   Thus  the
       lowest  layers are dependent on the highest layers and visa-
       versa.

       However, this is not necessarily bad.  "SCSI is very popular
       partly  because  all  levels  were  designed  and  specified
       together, resulting in an I/O system that is integrated in a
       consistent  and  homogeneous  style."  [2]  SCSI devices are
       grouped into classes.  A set of commands apply to  a  single
       class.   The  only thing that differentiates classes are the
       command sets.

       Commands are communicated to Logical Units that have Logical
       Blocks  and  Logical  Block  Addresses.   The  target device
       interprets and  translates  the  logical  addresses  to  the
       addressing  of  the  physical  medium.  For example, a disks
       physical address would be a  cylinder,  track,  and  sector.
       This separation of addressing duties further enhances device
       independence and the concept of device classes.

       So then, in theory from the Transport layer (command  level)
       on  down,  common  code  can be written that can service all
       device classes.  And the only unique code  need  be  in  the
       Session  Layer  where  an interface for each device class is
       developed.

       In reality, this is just what I am attempting  to  do,  with
       the  exception  that some device dependency is going to have
       to be passed down from the Session Layer  to  the  Transport
       and Data Link layers.

       __________________________________________________________________


       Application Layer     Serves   as   the    window    between
                           communicating application processes.

       Presentation Layer  Represents Information to  communicating
                           applications-entities   in  a  way  that
                           preserves meaning while resolving syntax
                           differences.

       Session Layer        Provides  services   to   establish   a
                           session-connection      between      two
                           presentation-entities,  and  to  support
                           their      orderly     data     exchange
                           interactions.











       Pascal 3.23           October 19, 1989                     5



       Transport Layer     Provides transparent  transfer  of  data
                           between session-entities.

       Network Layer        Provides  the   means   to   establish,
                           maintain,    and    terminate   network-
                           connections    between     communicating
                           systems.

       Data Link Layer     Provides functional and procedural means
                           to   establish,  maintain,  and  release
                           data-link-connections   among    network
                           entities.

       Physical Layer        Provides    mechanical,    electrical,
                           functional,        and        procedural
                           characteristics to  activate,  maintain,
                           and  deactivate physical connections for
                           bit  transmission  between  data-linked-
                           entries.


              FFFFiiiigggguuuurrrreeee 1111....  The OSI Reference Model layers [11]

       ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

       1.3  WWWWhhhhaaaatttt SSSSCCCCSSSSIIII iiiissss nnnnooootttt

       SCSI is not a simple  communication  medium  where  any  two
       devices  that can be physically connected can communicate on
       a byte by byte basis.  It does not  compare  well  to  other
       communication  media  of  this  sort  such  as  RS-232, HP's
       Datacomm, or HP's  GPIO.   Indeed,  even  HP's  HP-IB,  when
       considered at the lowest level, does not compare well.  SCSI
       is not a byte oriented communication medium, but is a  block
       oriented communication medium.

       SCSI  has  to  be  thought  of  as  a  physical  medium   of
       communication  that  works  in  concert  with  communication
       protocols at  higher  levels.   The  HP-IB/CS80  combination
       begins to compare with SCSI.

       SCSI is not a programmer's I/O medium.   To  communicate  on
       the SCSI bus, a programmer must implement the physical, data
       link, network, and transport layers.  A programmer may  then
       send/receive  commands  from other communication devices. If
       an application encompassing multiple  communication  devices
       choose  to  use  the  SCSI  bus  as  a  medium,  it could be
       accomplished by providing an algorithm that uses unique SCSI
       commands  (or  unique interpretations of such).  However, to
       be successful, the lower layers of SCSI protocol would  have
       to be adhered to.











       Pascal 3.23           October 19, 1989                     6



       For these reasons, SCSI is not a candidate  for  a  complete
       implementation  into  the  PWS/RMB  I/O subsystems.  For PWS
       this means that  the  I/O  procedures  defined  in  the  PWS
       Procedure  Library Manual will not be supported, and for RMB
       this means the INPUT, OUTPUT, and TRANSFER commands will not
       work for direct calls to the SCSI interface.

       A user's  interface  to  SCSI  can  be  greatly  simplified,
       however,  by  providing  a  programmable  interface  to  the
       Transport Level.  This is, in fact, what I propose to do.

       1.4  SSSSCCCCSSSSIIII----1111 vvvvssss.... SSSSCCCCSSSSIIII----2222

       The first ANSI standard for SCSI was published in 1986  [7].
       This definition has many extended and optional commands that
       can actually lead to mutually exclusive implementations.  To
       address this problem, an industry group has published a SCSI
       Common  Command  Set  (CCS)  [8].   Most  current   industry
       applications support the CCS.

       The next version of SCSI is  close  to  being  submitted  to
       ANSI.   This  version, SCSI-2, is greatly enhanced in device
       classes, commands, and also messages.  However,  great  care
       is  being  taken to ensure a SCSI-1 based host can work with
       SCSI-2 devices.

       The S300 HP-UX SCSI implementation is  based  on  the  SCSI-
       1/CCS  standard  and  has  already ran SCSI-2 based devices.
       There are no plans to upgrade the S300 HP-UX  implementation
       to SCSI-2.

       1.5  PPPPrrrrooooppppoooosssseeeedddd AAAArrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeee

       The following block diagram indicates the basic architecture
       I propose to implement:



























       Pascal 3.23           October 19, 1989                     7




       ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

               +-----+-----+-----+-----+-----+
               |     |     |     |     |     |
               |  D  |  T  |  P  |U  R |     |         PWS T.M.s or RMB device
               |  I  |  A  |  R  |S  O |     |         dependent drivers.
               |  S  |  P  |  I  |E  U | ... |
               |  K  |  E  |  N  |R  T |     |         In addition, a PWS user
               |     |     |  T  |   I |     |         can write his own
               |     |     |  E  |   N |     |         peripheral driver.
               |     |     |  R  |   E |     |
               +-----+-----+-----+-----+-----+

               +-----------------------------+
               |    SCSI Command Interface   |         Generic Interface to
               |      (Transport Layer)      |         SCSI Bus.  Published.
               +-----------------------------+

               +-----------------------------+
               |     SCSI Message Handler    |         SCSI specific.
               |       (Network Layer)       |         Not published.
               +-----------------------------+

               +-----------------------------+
               |      SCSI H/W Interface     |         SCSI specific.
               | (Physical/Data Link Layers) |         Not published.
               +-----------------------------+


                    FFFFiiiigggguuuurrrreeee 2222....  SCSI Block Architecture

       ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


       A  Generic  SCSI  Driver  will  comprise  the  SCSI  Command
       Interface  on  down  and will be common to both PWS and RMB.
       This driver will be implemented as an interrupt driven state
       machine.  Refer to the preliminary IRS for more details.

       To send a SCSI command to a target  device  and  get  status
       back,  a  program will interface to the Generic SCSI Driver.
       This interface, discussed in the Preliminary  ERS,  will  be
       published  in  the Procedure Library for PWS, but not in any
       RMB manuals.  On top of  this  interface  PWS/RMB  (and  PWS
       programmers) interface to SCSI peripherals, and lower layers
       of hidden software ensure proper access and error handling.















       Pascal 3.23           October 19, 1989                     8



       1.6  WWWWhhhhaaaatttt nnnneeeeeeeeddddssss ttttoooo bbbbeeee ddddoooonnnneeee

       To support SCSI on PWS and RMB  an  implementation  strategy
       should  be  devised  whereby the user will see no difference
       between the  operation  of  a  SCSI  device  and  any  other
       currently supported device.

       As much source code as possible should  be  common  to  both
       workstations.

       1.6.1  _F_o_r__b_o_t_h__P_W_S__a_n_d__R_M_B  a Generic SCSI Driver should be
       developed  that  implements  the  physical through transport
       layers.   This  driver  would  be  common  source  for  both
       workstations.   To  communicate with any SCSI peripheral (of
       any class) both workstations should interface only  to  this
       driver.

       1.6.2  _F_o_r__P_W_S  a TM for each supported device class  should
       be  developed  that  interfaces  to the Generic SCSI Driver.
       Currently, only a TM for  the  direct  access  device  class
       (disks) has been investigated.

       The TABLE  program  will  have  to  be  modified  and  auto-
       configuration, similar to CS80, should be implemented.

       The MEDIAINIT program will have to be modified  to  directly
       call  the  Generic SCSI Driver to format the SCSI disk (SCSI
       tape support is not currently planned).

       Named reboot needs to be extended to support reboot to a PWS
       UNIT that has a SCSI disk TM.

       A new chapter in the PWS Procedure Library manual will  have
       to  be  added  to  describe  the  Generic  Driver Interface,
       thereby allowing programmers to support unique SCSI devices.
       In  addition,  modifications  through  out the documentation
       will be required to describe what files need  to  be  loaded
       for SCSI support, and when and how to load them.

       1.6.3  _F_o_r__R_M_B  a set of device dependent drivers will  have
       to  be  written  to  interface each SCSI device class to the
       BASIC workstation and the Generic SCSI Driver.   For  disks,
       these drivers will be:

          o+ SCSI_dsize: get disk size parameters
          o+ SCSIinit: prepare for a series of reads and writes
          o+ SCSIread: read data from a SCSI disk
          o+ SCSIwrite: write data to a SCSI disk
          o+ SCSIterm: terminate series of reads and writes
          o+ SCSIinitialize: format a SCSI disk
          o+ SCSI_pwrup: perform power up initializations











       Pascal 3.23           October 19, 1989                     9



       RMB does not auto-configure so modifications to a TABLE like
       program  will  not  be necessary.  However, the proposed 6.0
       volume specifier will have to include SCSI volumes.

       The RMB documentation will have to be modified  to  describe
       SCSI usage and how to obtain it in RMB.

       1.7  HHHHaaaarrrrddddwwwwaaaarrrreeee RRRReeeessssoooouuuurrrrcccceeeessss RRRReeeeqqqquuuuiiiirrrreeeedddd

          o+ SCSI Hard Disk: 7957S, 7958S, or 7959S.  7958S on hand.
          o+ SCSI Optical Disk: 6300 Model 650/A.  Ordered.
          o+ S300 Piggy Back SCSI Interface: 98265A  (replaces  high
            speed HP-IB).  On hand.
          o+ S300 DIO-1 SCSI Interface: 98658A.  Ordered.
          o+ SCSI Bus Logic Analyzer (there is at least one in  Fort
            Collins).

       1.8  WWWWhhhhaaaatttt wwwwiiiillllllll nnnnooootttt bbbbeeee ddddoooonnnneeee

       Support  of  SCSI  tapes  and   printers   have   not   been
       investigated.   SCSI tapes and printers are not supported by
       S300 HP-UX.  (However SCSI tape  support  is  committed  for
       S300 HP-UX 8.0).

       The PWS I/O procedure defined in the PWS  Procedure  Library
       Manual will not be implemented.

       The RMB INPUT, OUTPUT, and TRANSFER commands will  not  work
       for  direct  calls to the SCSI interface (they will work for
       file access).

       RMB Programmers access to the Generic SCSI Driver  will  not
       be provided.





























       Pascal 3.23           October 19, 1989                    10



       1.9  EEEEssssttttiiiimmmmaaaatttteeeessss


       TASK                                    50%             90%

       Generic Driver Development              2 weeks         3 weeks
       Generic Driver Test Development         2 weeks         2 weeks
       Generic Driver Test                     2 weeks         2 weeks

       PWS TM Development                      1 week          1 week
       PWS TM Test                             1 week          2 weeks
       PWS CTABLE Modification                 3 days          1 week
       PWS CTABLE Test                         1 week          1 week
       PWS MEDIAINIT Modification              2 days          3 days
       PWS MEDIAINIT Test                      2 days          3 days
       PWS Named Reboot Mod & Test             1 day           2 days
       PWS Documentation                       2 weeks         3 weeks

       RMB Disk Driver Development             1 week          1 week
       RMB Disk Driver Test                    1 week          2 weeks
       RMB Documentation                       2 weeks         3 weeks


       From the above estimates, I extract  the  following  summary
       information:


       SCSI on PWS and RMB                     16.5 weeks      22.5 weeks
       SCSI on PWS                             12.5 weeks      16.5 weeks
       SCSI on RMB                             10 weeks        13 weeks


       NNNNOOOOTTTTEEEE:::: SCSI Tapes and Printers are not included.

       1.10  GGGGooooaaaallllssss

       Following is a list of development goals for supporting SCSI
       on PWS and RMB.

          o+ Operationally, the user  will  perceive  no  difference
            between  running  a  SCSI based disk or a disk based on
            another communication protocol.

          o+ All currently supported PWS and  RMB  Directory  Access
            Methods  (LIF, HFS, etc.) will work without change on a
            SCSI disk.

          o+ The RMB Mass Storage Volume Specifier will not change.

          o+ As much source as possible will be shared among the PWS
            and RMB workstations.











       Pascal 3.23           October 19, 1989                    11



          o+ Provide programmer's access to the SCSI bus on PWS.

          o+ Subset of SCSI-1 and CCS support.

          o+ If 3.22 CTABLE  can  be  compiled  and  run  on  a  PWS
            workstation  with  only  512K,  then  after SCSI CTABLE
            modifications should still be able to compile  and  run
            with only 512K.

            Question: given cheap  memory  available,  should  this
            still be a PWS requirement?

       1.11  NNNNoooonnnn GGGGooooaaaallllssss

       Following is a list of items that  are  _n_o_t  _g_o_a_l_s  _a_n_d  _n_o_t
       _p_l_a_n_n_e_d for SCSI development on PWS and RMB.

          o+ Support of the I/O procedures and driver hooks  defined
            in  the  PWS  Procedure  Library  Manual.   When  these
            procedures and hooks are used to communicate  with  the
            SCSI interface, an error will occur.

          o+ Support of the RMB INPUT, OUTPUT, and TRANSFER commands
            when  directed  to a SCSI interface (they will work for
            file access).  When these commands are  directed  to  a
            SCSI interface, an error will occur.

          o+ Provide programmer's access ot the SCSI bus on RMB.

          o+ SCSI-2 or HPCS 1.0 support.

          o+ SCSI Tape support.

          o+ SCSI Printer support.

       1.12  SSSSCCCCSSSSIIII VVVVeeeerrrrssssiiiioooonnnn oooonnnn PPPPWWWWSSSS aaaannnndddd RRRRMMMMBBBB

       The SCSI implementation for PWS/RMB will  be  SCSI-1  based.
       This implementation has been chosen for two reasons:

         1.   All   S300   platforms   will   have   a   consistent
             implementation.   (S300  HP-UX  SCSI version is SCSI-1
             and there are not any plans to  update  to  SCSI-2  or
             HPCS 1.0).

         2.  A full SCSI-2 implementation is beyond the current and
             forseeable  resources for PWS/RMB.  The attitude being
             if SCSI-2 devices will work with PWS/RMB workstations,
             with  the  caveat  that  all  of  the features or host
             offloading  provided  by  that  device  can   not   be
             harnessed,  then that is OK.  Marketing input would be











       Pascal 3.23           October 19, 1989                    12



             required to alter this philosophy.

       1.13  CCCCoooommmmmmmmoooonnnn CCCCooooddddeeee:::: GGGGeeeennnneeeerrrriiiicccc SSSSCCCCSSSSIIII DDDDrrrriiiivvvveeeerrrr

       Rocky  Mountain  Basic,  referred  to  herein  as  RMB,   is
       developed  on the Pascal Workstation.  Given this, then with
       care, a common core of code  can  be  developed  and  shared
       among the workstations.  Leveraging the development can lead
       to lower development and maintenance costs for both products
       and a consistent implementation across both workstations.

       NNNNOOOOTTTTEEEE:::: Common source for a SCSI driver precludes the  use  of
       the  PWS  I/O  subsystem.   Basic's  I/O  subsystem  is  not
       compatible with Pascal's.  However, SCSI is not suited as  a
       general I/O system and therefore this is not perceived as an
       issue.

       A _G_e_n_e_r_i_c _S_C_S_I _D_r_i_v_e_r that implements the  Physical  through
       Transport  layers  will  be  shared  among PWS and RMB.  All
       software that interfaces  to  the  Generic  SCSI  Driver  is
       considered _S_e_s_s_i_o_n _L_a_y_e_r software.

       Software interfacing to a SCSI device will do so through the
       Generic  SCSI  Driver.   The  interface  to  this  driver is
       discussed in the next section.

       PWS Session Layer programs using  the  Generic  SCSI  Driver
       are:

          o+ SCSI Disk Transfer Method
          o+ Table
          o+ Mediainit

       RMB Session Layer programs using the Generic SCSI Driver are
       the  device  dependent  drivers.   The  RMB device dependent
       drivers for SCSI are:

          o+ SCSI_dsize: get disk size parameters
          o+ SCSIinit: prepare for a series of reads and writes
          o+ SCSIread: read data from a SCSI disk
          o+ SCSIwrite: write data to a SCSI disk
          o+ SCSIterm: terminate series of reads and writes
          o+ SCSIinitialize: format a SCSI disk
          o+ SCSI_pwrup: perform power up initializations

       1.14  GGGGeeeennnneeeerrrriiiicccc SSSSCCCCSSSSIIII DDDDrrrriiiivvvveeeerrrr IIIInnnntttteeeerrrrffffaaaacccceeee

       The  Generic  SCSI  Driver  handles   SCSI   sessions.    To
       understand  the  interface  to  the Generic SCSI Driver, one
       must first understand what a SCSI session is.












       Pascal 3.23           October 19, 1989                    13



       1.14.1  _S_C_S_I__S_e_s_s_i_o_n

       A SCSI session is a term  used  to  represent  the  standard
       sequence  of  events  that  take  place  while  a  SCSI host
       communicates with a SCSI target device.  A session  consists
       of  arbitrating  for  the  bus,  selecting  a target device,
       sending a command to the device, optionally sending data  to
       or  getting  data  from  the  target  device (depends on the
       command), getting status back from  the  target  device  and
       finally releasing the bus.

       A session can be extended by linking commands  together.   A
       special bit set in the first command tells the target device
       that this command is linked to  following  commands.   After
       the  target  device  sends status back to the host, the host
       (providing the status was good) sends another command (which
       may or may not be linked) to the target device.

       It is convenient to consider SCSI operations only  from  the
       viewpoint  of  commands, and let the transportation of these
       commands and subsequent data be  left  to  lower  layers  of
       code.   Thus,  the  Session  Layer  would  format  commands,
       provide  buffers  for  data,  and  hand  these  off  to  the
       Transport Layer.  Upon command completion, the Session Layer
       would receive and interpret the status.

       The interface to the transport layer is the entry  point  to
       the Generic SCSI Driver.

       1.14.2  _O_S_I__L_a_y_e_r_i_n_g__R_e_s_p_o_n_s_i_b_i_l_i_t_i_e_s

       For the purposes of this document, it is inappropriate to go
       into  the  details of each layer's responsibility, however a
       summary follows.  For  those  who  are  familiar  with  SCSI
       concepts,  but  have  not  considered  OSIRM  layering  as a
       parallel, this may prove interesting.  Figure 2 indicates  a
       correspondence  between  SCSI  functionality and some of the
       OSI Reference Model layers.

       The transport layer ensures proper sequencing  of  commands,
       data, and status and passes information to the network layer
       for transportation.   The  network  layer  sets  up  a  path
       between  the  host and target device and maintains it during
       the communication  of  commands,  data,  and  status.   SCSI
       messages   are   used   for   this   purpose.    Note   that
       disconnect/reconnect is handled here.

       The transport layer  works  with  the  data  link  layer  to
       perform the path setup, data transfer, and path termination.
       For SCSI this means  bus  arbitration,  proper  bus  phases,
       communication    mode    (asynchronous    vs.    synchronous











       Pascal 3.23           October 19, 1989                    14



       transmission), and  memory  access  (DMA  or  programmatic).
       Communication  error  handling  occurs  at this interface as
       well.

       __________________________________________________________________


       OSIRM Layer                SCSI Functionality

       Transport Layer            SCSI Commands, Data, and Status

       Network Layer              SCSI Messages

       Data/Physical Layers        Bus  phases,  Bus  signals  that
                                  define     the     bus    phases,
                                  Arbitration             Protocol,
                                  Asynchronous and Synchronous Data
                                  Transfer Protocols,  DMA,  Parity
                                  Errors, Bus Resets, etc.


                        FFFFiiiigggguuuurrrreeee 3333....  OSIRM and SCSI
       ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________




       1.14.3  _I_n_t_e_r_f_a_c_e__D_e_t_a_i_l_s

       The primary access  to  the  Generic  SCSI  Driver  will  be
       through  a SessionBlock.  The caller will acquire memory for
       a SessionBlock, fill out the necessary parameters, and  call
       the  procedure  DoSession.   The  types  of  things  in  the
       SessionBlock are:

          o+ Select Code
          o+ Device Number (similar to HP-IB bus address)
          o+ Logical Unit Number
          o+ Sub Logical Unit Number
          o+ Pointer to SCSI Command
          o+ Command Length
          o+ Buffer In Block.  For input transfers.   Contains  such
            things as:

               o+ Pointer to Buffer
               o+ Transfer Length
               o+ Protocol Type (Sync, Async)
               o+ Transfer Type (DMA, Programmatic)
               o+ Overlap Boolean
               o+ Call Back Procedure (If Overlap and this  is  non-
                 zero,  when  transfer  is  done  this procedure is











       Pascal 3.23           October 19, 1989                    15



                 called).
               o+ DoNotDisconnect Boolean.  Allows  caller  to  tell
                 driver not to allow SCSI disconnect.
          o+ Buffer Out Block.  For output transfers.  Identical  in
            content to the Buffer In Block.
          o+ Command Status (placed here upon  session  completion).
            Comes from the Target Device.
          o+ Internal Status (placed here upon session  completion).
            Non zero if an error has occurred.
          o+ InternalBlock.  This is used  internally  by  the  SCSI
            driver.

       NNNNOOOOTTTTEEEE:::: This is not a definitive list.

       All of the user  provided  parameters  in  the  SessionBlock
       (everything but the Status parameters and the InternalBlock)
       will remain unchanged; allowing the caller to reuse it.   Of
       course,  the data buffers pointed to by the SessionBlock may
       be modified,  if  the  command  generates  a  data  transfer
       sequence.

       The SessionBlock merely contains a pointer to the command to
       be   sent   to  the  target  device.   It  is  the  caller's
       responsibility  to  acquire  memory  for  the  command   and
       properly  format  it  (Commands are of variable length).  To
       assist the caller, a procedure will be provided that,  given
       the correct information, will format commands.

       Extended session through linked commands will  be  supported
       by  the  SCSI  driver.  This is accomplished by means of the
       same  SessionBlock   described   previously,   however   the
       procedure DoLnSession is called with an additional parameter
       that contains the  address  of  a  procedure  to  call  back
       (LinkedCBProc)   when   the  next  linked  command  requires
       retrieval.

       Among the parameters given the  LinkedCBProc  procedure  one
       will be a pointer to the SessionBlock.  This procedure fills
       out  the  next  command  and  buffer  information   in   the
       SessionBlock    and    returns.    Before   returning,   the
       LinkedCBProc should  handle  any  data  pointed  to  in  the
       SessionBlock or it may be overwritten!

       For overlapped  sessions  that  do  not  have  a  call  back
       procedure,  a  function  will  be  provided  that  returns a
       BOOLEAN indicating if the session has completed or not.

       Other procedures provided will enable the  caller  to  abort
       the  current session, reset a SCSI device, or reset the SCSI
       bus.












       Pascal 3.23           October 19, 1989                    16



       The  primary  reason  for  the  SessionBlock  is  to   allow
       distributed  arbitration  within PWS/RMB.  This is necessary
       to support the OVERLAP Transfer required by the  RMB  device
       drivers  and widely implemented on other communication media
       on PWS.

       1.15  PPPPWWWWSSSS SSSSooooffffttttwwwwaaaarrrreeee RRRReeeeqqqquuuuiiiirrrreeeedddd

       To use a SCSI disk, the user will have to  add  the  Generic
       SCSI Driver and the SCSI Disk Transfer Method to the INITLIB
       module.  These will be separate files.  The file names are:

          o+ Generic SCSI Driver:  SCSILIB
          o+ SCSI Disk TM:  SCSIDISK

       1.16  PPPPWWWWSSSS DDDDiiiisssskkkk CCCChhhhaaaannnnggggeeeessss

       THE SCSILIB and SCSIDISK files will be placed on the CONFIG:
       disk  for  single  sided media (options 042 and 044), and on
       the ACCESS: disk for double sided media (options 045).

       NNNNOOOOTTTTEEEE:::: The single sided CONFIG disk may not have enough  room
       to  support these changes, and if so other arrangements will
       have to be made.

       1.17  PPPPWWWWSSSS DDDDooooccccuuuummmmeeeennnnttttaaaattttiiiioooonnnn CCCChhhhaaaannnnggggeeeessss

       The Procedure Library will receive a new chapter  describing
       the interface to the Generic SCSI Driver.

       Workstation System Volumes II will require modifications  to
       describe how to add SCSILIB and SCSIDISK to the INITLIB.

       1.18  RRRRMMMMBBBB SSSSooooffffttttwwwwaaaarrrreeee RRRReeeeqqqquuuuiiiirrrreeeedddd

       To use a SCSI device, two binaries will have to  be  loaded,
       one  for  the Generic SCSI Driver, and one for the SCSI disk
       drivers.  These files are:

          o+ SCSI: Generic SCSI Driver
          o+ SCSIDISK: SCSI disk drivers

       1.19  RRRRMMMMBBBB DDDDiiiisssskkkk CCCChhhhaaaannnnggggeeeessss

       THE SCSI and SCSIDISK files will be placed  on  the  DRIVERS
       disk  for  single  sided media (options 042 and 044), and on
       the  DRIVERS  &  EXTENSIONS  disk  for  double  sided  media
       (options 045).














       Pascal 3.23           October 19, 1989                    17



       1.20  RRRRMMMMBBBB DDDDooooccccuuuummmmeeeennnnttttaaaattttiiiioooonnnn CCCChhhhaaaannnnggggeeeessss

       The following BASIC Manuals will require modifications:

          o+ Programming Techniques; Volumes 1 & 2
          o+ Using the BASIC System
          o+ Language Reference; Volume 1
          o+ Installing and Maintaining the BASIC System

       1.21  SSSSCCCCSSSSIIII DDDDeeeevvvviiiicccceeee RRRReeeeqqqquuuuiiiirrrreeeemmmmeeeennnnttttssss

       Any SCSI device that is supported  using  the  Generic  SCSI
       Driver will have to support the following SCSI messages:

          o+ Identify
          o+ Restore Pointers
          o+ Message Reject
          o+ Abort
          o+ Message Parity Error
          o+ No Operation
          o+ Bus Device Reset
          o+ Command Complete

       These are the CCS required messages.  In addition, the  SCSI
       driver supports the following messages:

          o+ Disconnect
          o+ Save Data Pointer
          o+ Extended Identify
          o+ Extended Synchronous Data Transfer Request
          o+ Linked Command Complete
          o+ Linked Command Complete With Flag
          o+ Initiator Detected Error

       The SCSI features of disconnect  (distributed  arbitration),
       synchronous  transfer,  and linked commands are supported by
       the  Generic  SCSI  Driver.   To  allow  implementors   some
       freedom,  these  options  can be turned off via flags in the
       SessionBlock.  (The synchronous data transfer option in  the
       SessionBlock  may  be taken away; it may not be possible, or
       at least highly undesirable, to tell a target device not  to
       do this once it has been told it is OK).

       1.22  SSSSCCCCSSSSIIII DDDDiiiisssskkkk RRRReeeeqqqquuuuiiiirrrreeeemmmmeeeennnnttttssss &&&& IIIIssssssssuuuueeeessss

       Implementing the Session Level Interface to the Generic SCSI
       Driver  is a unique activity for both PWS and RMB.  However,
       the final implementation  on  both  workstations  should  be
       functionally  equivalent.  Therefore, both workstations will
       require that target SCSI disks support these SCSI commands:












       Pascal 3.23           October 19, 1989                    18



          o+ Test Unit Ready
          o+ Request Sense
          o+ Format Unit
          o+ Read
          o+ Write
          o+ Inquiry
          o+ Read Capacity
          o+ Read Extended
          o+ Write Extended

       This list is a subset of the CCS required commands,  so  any
       disk  that  claims  CCS  conformity  for  SCSI-1  should, in
       theory, work with PWS and RMB.

       NNNNOOOOTTTTEEEE:::: The S300 HP-UX implementation requires the Mode  Sense
       command,  which  is  not currently in RMB/PWS required list.
       Mode Sense is NOT a CCS required command.

       NNNNOOOOTTTTEEEE:::: The target device _m_u_s_t support linked commands for the
       Session Layer software to use them.  Because linked commands
       are not required  for  CCS  conformance,  the  PWS/RMB  disk
       drivers will not use this feature.

       1.22.1  _S_C_S_I__D_i_s_k__I_s_s_u_e_s  The PWS and RMB workstations force
       the  Session  Layer of software to acquire all needed memory
       when they are first loaded.   SCSI  devices,  on  the  other
       hand,  report  a Logical Block Size after initialization and
       this Block Size is reported in 32 bits.  Unlike CS80  disks,
       SCSI disks can have all sorts of different block size and it
       is  dependent  on  the  manufacturer.   Unix,  which  allows
       drivers  to  go  off and get memory, does not have a problem
       with this, but RMB and PWS must know before hand  what  size
       block  to  request.   The  issue  to be resolved is what the
       average block size of the many SCSI disks on the market is?

       Early feedback indicates a 4K buffer will be sufficient.

       1.23  SSSSCCCCSSSSIIII TTTTaaaappppeeeessss

       SCSI Tapes will not be supported in  the  first  release  of
       SCSI  on either PWS or RMB.  If they were, a separate PWS TM
       and  RMB  device  dependent  driver   would   have   to   be
       implemented.

       S300 HP-UX does not currently support  SCSI  tapes  although
       tape  support  is  committed for release 8.0.  HP SCSI based
       tape drives are being developed.















       Pascal 3.23           October 19, 1989                    19



       1.24  SSSSCCCCSSSSIIII PPPPrrrriiiinnnntttteeeerrrrssss

       SCSI Printers will not be supported in the first release  of
       SCSI  on either PWS or RMB.  If they were, a separate PWS TM
       and  RMB  device  dependent  driver   would   have   to   be
       implemented.

       S300 HP-UX does not support  SCSI  printers,  and  currently
       there  are no plans to do so.  Currently, HP does not make a
       SCSI printer.


       2.  CCCCeeeennnnttttrrrroooonnnniiiiccccssss IIIInnnnvvvveeeessssttttiiiiggggaaaattttiiiioooonnnn RRRReeeeppppoooorrrrtttt

       2.1  PPPPrrrroooottttooooccccoooollll HHHHiiiissssttttoooorrrryyyy

       The Centronics Parallel interface  was  first  developed  by
       Centronics Inc. in the late 1970s for use with its printers.
       With the advent of the PC, the centronics parallel interface
       became an industry standard.

       As originally designed,  the  centronics  interface  was  an
       output  only  interface,  that is, data could only flow from
       the host to the peripheral.  When HP introduced the ScanJet,
       it  extended  the  Centronics interface to be bidirectional,
       that is data could flow from the host to the peripheral  and
       from  the peripheral to the host.  The ScanJet bidirectional
       centronics interface has become  an  industry  standard  for
       scanner products.

       When IBM introduced the PS/2 line that  came  with  the  new
       micro-channel   bus,  it  also  introduced  a  bidirectional
       centronics interface.  As can be expected from IBM, this new
       protocol was not compatible with the ScanJet protocol.

       To keep up with the PS/2 centronics interface products,  the
       XT/AT PC centronics interface was expanded to use an almost,
       but not quite, PS/2 interface.

       NNNNOOOOTTTTEEEE:::: In  all  of  the  bidirectional  implementations,  the
       output  protocol  (host to peripheral) has _n_o_t been changed.
       It is the input protocols that vary with each version.

       HP, recognizing the expanding products that use the PS/2 and
       XT/AT   centronics  interfaces,  has  started  defining  the
       interface  of  HP  PCs  and  peripherals,  called   Advanced
       Functionality  Parallel Port (AFPP).  Although released in a
       preliminary state, this definition has not  been  completed,
       nor  has it been accepted (nor is it guaranteed to be).  The
       AFPP document defines in detail how  HP  product  developers
       are to implement the PS/2 and XT/AT centronics interface.











       Pascal 3.23           October 19, 1989                    20



       2.2  SSSS333300000000

       Because of the growth in the number of peripherals using the
       centronics  interface  (in  one form or another), the SUMMIT
       project is planning on including  a  centronics  port  as  a
       standard  feature  on  the Human Interface card.  (SUMMIT is
       the new internal name for what used to be APEX-30).

       For the SUMMIT, a chip is being developed that will allow  a
       driver   to   use   all  of  the  aforementioned  centronics
       protocols.  However, their is  some  prejudice.   For  input
       operations,  the  chip  is  intelligent  about  the  ScanJet
       protocol and thus DMA can be used.  However, for  the  XT/AT
       and  PS/2 protocols, the centronics bus lines must be driven
       by the driver.   Therefore,  the  implementation  for  these
       protocols will be slower and without DMA.  Output operations
       for all protocols can use DMA.

       There are currently no plans to provide  centronics  support
       with a separate DIO or DIO-II card.

       2.3  CCCCeeeennnnttttrrrroooonnnniiiiccccssss CCCCoooommmmppppaaaannnnyyyy HHHHiiiissssttttoooorrrryyyy

       I find it interesting that the  company  that  invented  the
       centronics  interface is now selling "baking pans, spatulas,
       can and bottle openers and many other  household  products."
       ('New  England  Business',  1/4/88,  p. 33, 34).  During the
       economic squeeze of the early 1980s, (also the Japanese  are
       blamed),  Centronics  Inc.  lost  $80 million.  Due to these
       loses and high debt, the  centronics  printer  business  was
       sold  to  Genicom in 1987.  Centronics Inc. has since become
       "a basic houseware maker and marketer".


       3.  CCCCeeeennnnttttrrrroooonnnniiiiccccssss oooonnnn PPPPWWWWSSSS

       The centronics parallel interface is a natural for  the  PWS
       I/O  subsystem.  The only real difficulty will be in dealing
       with the multiple methods  of  inputing  data.   Incremental
       estimates   will   be   provided  (next  section)  for  each
       interface.

       Because the chip has  so  much  built  in  support  for  the
       ScanJet,  it  is  little  extra  effort  to  support ScanJet
       communications in the driver.  This does  not  mean  that  a
       ScanJet  application  is  going  to be provided.  That is an
       entirely different matter and is not addressed here.

       Because adding the XT/AT-PS/2 communication protocols to the
       driver  will  require a great effort in both development and
       QA, it may be necessary to eliminate that from the  release.











       Pascal 3.23           October 19, 1989                    21



       If this turns out to be the case, the PWS user would have to
       be able to take over the hardware in order to write his  own
       driver.

       If the  XT/AT-PS/2  communication  protocols  are  supported
       within  the  driver,  it  does  not  mean that an XT/AT-PS/2
       application is going to be provided.  That  is  an  entirely
       different matter and is not addressed here.

       3.1  IIII////OOOO SSSSuuuubbbbssssyyyysssstttteeeemmmm

       3.1.1  _C_o_m_m_u_n_i_c_a_t_i_o_n__M_o_d_e_s

       The centronics driver will have to  be  in  a  communication
       mode  which  determines the protocol currently being used on
       the centronics bus.  This can be determined  empirically  or
       an  application  can  place  the  driver  in  a desired mode
       through the IOCONTROL procedure.

       If  the  driver  supports  the  XT/AT-PS/2  protocols,   the
       following modes are required:

        1.  Output_Only
        2.  ScanJet (determined when device is reset).
        3.  XT/AT
        4.  PS/2
        5.   Possible_XT/AT_PS/2  (don't  know   until   peripheral
            attempts to input).
        6.  Other

       If  the  driver  only  supports  the  ScanJet  bidirectional
       protocol, the following modes are required:

        1.  Output_Only
        2.  ScanJet (determined when device is reset).
        3.  Other

       The Other mode tells the driver to not do anything,  instead
       an  outside  application  has  taken  over  the  hardware to
       implement   an    unsupported    mode.     Because    output
       communications  are identical for all modes, a driver writer
       could use the Output_Only mode for output and then switch to
       Other for input.

       3.1.2  _I_/_O__H_o_o_k_s

       The centronics interface  will  require  the  following  I/O
       hooks be implemented:

       iod_init        Initialize   the   interface.    Reset   the
                      peripheral. Set communication mode.











       Pascal 3.23           October 19, 1989                    22



                      If the driver does not support the XT/AT_PS/2
                      communications  modes,  iod_init will set the
                      communication mode to ScanJet or Output_Only,
                      otherwise    it    will    be    ScanJet   or
                      Possible_XT/AT_PS/2.

       iod_isr        Centronics driver interrupt service  routine.
                      Handles   system  interrupts  for  peripheral
                      errors, bus turn arounds, DMA complete,  FIFO
                      full/empty,   or  line  transitions  for  the
                      XT/AT_PS/2 interfaces.

                      If XT/AT_PS/2 protocols  are  not  supported,
                      then   a   way   must  be  provided  for  the
                      application writer to insert his own ISR.

       iod_rdb        Read a single  byte  off  of  the  centronics
                      interface  using  the  current  communication
                      mode.

       iod_wdb         Write  a  single  byte  to  the   centronics
                      interface.   (All  output  on  the centronics
                      interface  is  the  same,   no   matter   the
                      communication mode).

       iod_rdw        Read a word from  the  centronics  interface.
                      The  centronics  interface is a byte wide, so
                      this  routine  would  simply  interface  with
                      iod_rdb.

       iod_wtw        Write a word  to  the  centronics  interface.
                      The  centronics  interface is a byte wide, so
                      this  routine  would  simply  interface  with
                      iod_wtb.

       iod_rds        Read a  centronics  driver  status  register.
                      The  contents of the various status registers
                      requires a full  definition.   Currently,  at
                      least the communication mode would have to be
                      present.

       iod_wtc        Write a centronics driver  control  register.
                      The contents of the various control registers
                      requires a full  definition.   Currently,  at
                      least the communication mode would have to be
                      present.

       iod_tfr        Read/write a buffer  from/to  the  centronics
                      interface.   For  output in any communication
                      mode, Programmatic, DMA, and Overlap would be
                      provided.   For  input, the ScanJet mode will











       Pascal 3.23           October 19, 1989                    23



                      provide Programmatic, DMA, and Overlap.   The
                      XT/AT_PS/2  modes  could  not  provide DMA or
                      Overlap.

                      The  TRANSFER_END   routine   will   not   be
                      supported.

       3.2  PPPPrrrriiiinnnntttteeeerrrr TTTTMMMM

       The PWS Printer TM  will  require  slight  modifications  to
       ensure  the driver is in Output_Only mode.  In addition, the
       printer application's channel initialization code will  have
       to be closely examined.

       3.3  TTTTeeeessssttttssss

       Centronics tests will have to be written and  added  to  the
       I/O   test   subsystem.    In   addition   to  standard  I/O
       communications,  a  battery  of  printer  tests  should   be
       developed.

       3.4  DDDDooooccccuuuummmmeeeennnnttttaaaattttiiiioooonnnn

       A new chapter  will  have  to  be  added  to  the  Procedure
       Library.   Following  the  lead  of  current  chapters,  the
       centronics chapter  will  have  to  explain  in  detail  the
       centronics protocols and interface registers.


       4.  EEEEssssttttiiiimmmmaaaatttteeeessss
































       Pascal 3.23           October 19, 1989                    24




                                               (Man Weeks)
               _D_e_s_c_r_i_p_t_i_o_n                     _5_0%     _9_0%

               Output & ScanJet Input
                  Development                  2       3
                  QA (incl Test Plan           2       3
                      and development)

               XT/AT-PS/2 Input (in addition
               to above)
                  Development                  1       2
                  QA (incl Test Plan           2       3
                      and development)

               Documentation                   2       3

               Printer TM                      1day    .5


       From above, the following is extrapolated:

               Centronics, w/out XT/AT-PS/2    7       11.5
               Centronics, with XT/AT-PS/2     9       14.5


       5.  66668888000044440000 IIIInnnnvvvveeeessssttttiiiiggggaaaattttiiiioooonnnn RRRReeeeppppoooorrrrtttt

       This document will describe major features possessed by  the
       68040  processor  and the changes needed within the PaWS O/S
       to  support  Hewlett  Packard  68040   based   workstations.
       Estimates  will  be made for the effort required to complete
       the investigation and design (I/D)  and  the  implementation
       and  test (I/T) phases of this project.  This description is
       based upon everything known as of  August,  1989.   As  such
       this  document  will  be  modified,  if  necessary,  as more
       information becomes available.

       5.1  IIIInnnntttteeeerrrrnnnnaaaallll UUUUsssseeee OOOOnnnnllllyyyy

       This   document  contains   Hewlett-Packard   and   MOTOROLA
       proprietary  information,  and  is for use within the Pascal
       Workstation group only. PLEASE DO NOT COPY THIS DOCUMENT.

       5.2  66668888000044440000 FFFFeeeeaaaattttuuuurrrreeeessss

       5.2.1  _G_e_n_e_r_a_l__R_e_m_a_r_k_s    The  MC68040  processor   may   be
       available  in-house  around the middle of October. Prototype
       Summit-40  workstations  might  be  available  as  early  as
       December.  Our  goal  is  to have a version of PaWS ready to
       come up on the  first  Summit  prototype  as  early  as  the











       Pascal 3.23           October 19, 1989                    25



       prototype is available.

       5.2.2  _S_t_a_c_k__F_r_a_m_e_s  The format for some of the stack frames
       will  change  for  the  68040. This will cause the bus error
       handling within the  debugger  to  change.  Changes  may  be
       required  elsewhere,  but an investigation is required to be
       sure about this.

       5.2.3  _F_l_o_a_t_i_n_g__P_o_i_n_t__P_r_o_c_e_s_s_i_n_g     The   most   noticeable
       difference  of  the 68040 relative to 68020/68030 processors
       is the lack of support for a floating point co-processor. It
       is  Motorola's  intention,  however,  to  provide  full user
       compatibility with the  68881/68882  instruction  set.  This
       will be accomplished by way of the following scheme.

       Some of the 68881/68882 instructions will be supported  with
       all  the  previously supported data types in H/W directly on
       the 68040 processor.  Other  68881/68882  instructions  will
       generate  an F-line trap with special stack frames. Motorola
       will  provide  special  emulation  S/W  for  each  of  these
       instructions  that  can  be  branched  to from the exception
       vector table and executed to simulate the effect of the  co-
       processor instruction causing the exception.

       Some of the instructions will be supported in  H/W  but  not
       for   all   of  the  previously  supported  data  types.  In
       particular, the packed decimal real data type when used with
       some  instructions  will  cause  an  unimplemented data type
       exception. Again, Motorola will provide emulation S/W  which
       can   be   branched  to  to  carry  out  a  conversion.  The
       instruction will resume with the converted data upon  return
       from exception.

       5.2.4  _N_e_w__I_n_s_t_r_u_c_t_i_o_n_s     Three   new   instructions   are
       available  on the 68040. The instruction MOVE16 will move 16
       consecutive bytes of data in memory. Privileged instructions
       CINV  and  CPUSH  invalidate cache lines. Our assembler will
       have to be enhanced to support these.

       In  addition,  new  versions  of  some  of  the  68881/68882
       instructions  are  available that explicitly force single or
       double precision rounding. The assembler  will  have  to  be
       modified   to  support  these  new  versions  of  the  those
       instructions as well.

       5.2.5  _D_r_o_p_p_e_d__I_n_s_t_r_u_c_t_i_o_n_s  A good many of the generic  co-
       processor  instructions  were  dropped (with no co-processor
       they don't make any  sense).   PLOAD  and  PMOVE  are  being
       replaced  by  PTEST  and  MOVEC.   The  assembler won't need
       enhancing, but we need to  make  sure  that  none  of  these
       instructions  being dropped were used in the PaWS O/S. Since











       Pascal 3.23           October 19, 1989                    26



       they are privileged instructions  these  changes  should  be
       invisible from the user point of view.

       5.3  OOOOuuuuttttlllliiiinnnneeee ooooffff TTTTaaaasssskkkkssss

       As of August, 1989 I have identified the following  specific
       tasks which need to be performed to carry out this project :

             1.) Modify the exception vector table to include the
                 unimplemented floating point operation and data
                 type traps

             2.) Receive the emulation code from Motorola for the
                 unimplemented floating point operations and data
                 types, and

                 a.) Modify (port) this code so it is suitable for
                     input to the PaWS assembler
                 b.) Make sure that the error handling this code
                     employs is compatible with PaWS
                 c.) Figure where and when this code will be loaded
                     by PaWS
                 d.) Develop a testing scheme for each of these
                     opcode and data type emulations

             3.) Enhance the assembler to handle the new instructions
                 and the new versions of some of the floating point
                 instructions

             4.) Compare the new stack frame format with the old
                 to see if PaWS is impacted (Note - we can be sure
                 that the Debugger is impacted. This investigation
                 will examine PaWS as a whole)

             5.) Make sure our current cache control conventions
                 will work on the 68040 - modify where needed

             6.) Turn the system


       5.4  EEEEssssttttiiiimmmmaaaatttteeee ooooffff TTTTaaaasssskkkkssss

       This section will attempt to generate 50%  and  90%  numbers
       for each of the tasks identified in the previous section.

       5.4.1  _W_a_r_n_i_n_g_,__D_i_s_c_l_a_i_m_e_r__E_t_c_.  These estimates  are  based
       on  what  was  known  as  of  August,  1989.  This  document
       ,especially the  estimates,  may  have  to  change  as  more
       detailed information becomes available.













       Pascal 3.23           October 19, 1989                    27



       All times given refer to 1 MTS, e.g.  a  time  of  '5  days'
       refers to '5 MTS days'.

       5.4.2  _E_x_c_e_p_t_i_o_n__V_e_c_t_o_r__T_a_b_l_e__M_o_d_i_f_i_c_a_t_i_o_n

            Estimate :

            Modify exception vector table

            I/D : 1 days ( 50% ),  2 days ( 90% )
            I/T : 1 days ( 50% ),  2 days ( 90% )


       5.4.3  _M_o_t_o_r_o_l_a__E_m_u_l_a_t_i_o_n__C_o_d_e__I_n_c_o_r_p_o_r_a_t_i_o_n

       This is broken down by sub-task.

       5.4.3.1  _P_o_r_t__t_h_e__E_m_u_l_a_t_i_o_n__C_o_d_e

       As of August, 1989 the emulation code is known to consist of
       some  5200  lines  of  assembly  code.  This  code  has been
       received from Motorola and is  available  for  incorporation
       into PaWS.
            Estimate :

            Port the emulation code to PaWS

            I/D : 4 days ( 50% ),  7 days ( 90% )
            I/T : 5 days ( 50% ),  8 days ( 90% )


       5.4.3.2  _V_e_r_i_f_y__E_r_r_o_r__H_a_n_d_l_i_n_g_,__O_t_h_e_r__C_o_n_v_e_n_t_i_o_n_s

       I don't think this amounts to much, but it has to be done.

            Estimate :

            Verify Error Handling, Etc.

            I/D : 1 days ( 50% ),  1 days ( 90% )
            I/T : 1 days ( 50% ),  1 days ( 90% )


       5.4.3.3  _E_m_u_l_a_t_i_o_n__C_o_d_e__M_a_n_a_g_e_m_e_n_t

       Same comments as previous task.

            Estimate :

            Load and Manage the Emulation Code












       Pascal 3.23           October 19, 1989                    28



            I/D : 1 days ( 50% ),  2 days ( 90% )
            I/T : 1 days ( 50% ),  2 days ( 90% )

       5.4.3.4  _E_m_u_l_a_t_i_o_n__C_o_d_e__T_e_s_t_i_n_g

       A testing scheme will have to be  devised  and  carried  out
       that will exercise all the emulation code.

            Estimate :

            Test the Emulation Code

            I/D : 4 days ( 50% ),  8 days ( 90% )
            I/T : 4 days ( 50% ),  8 days ( 90% )

       5.4.4  _E_n_h_a_n_c_e__t_h_e__A_s_s_e_m_b_l_e_r

       This shouldn't be too bad (only 3 new opcodes  to  support),
       but  it does involve re-turning the assembler and running it
       against the assembler test suite.

       The task of discovering the modifications to be made is  now
       complete,  they  only  have  to  be  incorporated  into  the
       assembler.

            Estimate :

            Modify and Test the Assembler

            I/D : 1 days ( 50% ),  2 days ( 90% )
            I/T : 3 days ( 50% ),  5 days ( 90% )

       5.4.5  _S_t_a_c_k__F_r_a_m_e__I_n_v_e_s_t_i_g_a_t_i_o_n

       This involves finding the current usage of the stack frames,
       and,  for  those  frames that have changed, making sure that
       information used within those frames has not changed  either
       in terms of offset or format.

       Any changes found  will  require  corresponding  changes  in
       PaWS.

       The numbers here are a bit conservative as I've  really  not
       much idea what this actually entails.

            Estimate :

            Check Out the Stack Frames

            I/D : 2 days ( 50% ),  4 days ( 90% )
            I/T : 2 days ( 50% ),  4 days ( 90% )











       Pascal 3.23           October 19, 1989                    29



       5.4.6  _C_a_c_h_e__C_o_n_t_r_o_l

       I don't think this is too bad.

            Estimate :

            Cache Control Compatibility

            I/D : 1 days ( 50% ),  1 days ( 90% )
            I/T : 1 days ( 50% ),  1 days ( 90% )

       5.5  SSSSuuuummmmmmmmaaaarrrryyyy ---- EEEEssssttttiiiimmmmaaaatttteeee ooooffff EEEEffffffffoooorrrrtttt ---- PPPPaaaaWWWWSSSS oooonnnn 66668888000044440000

       This section sums all the previous sections.

            Estimate :

            Total Effort Required - PaWS onto 68040

            I/D : 15 days ( 50% ),  27 days ( 90% )
            I/T : 18 days ( 50% ),  31 days ( 90% )
                 ----------------------------------
                  33 days ( 50% ),  58 days ( 90% )

       5.6  CCCCoooonnnncccclllluuuuddddiiiinnnngggg RRRReeeemmmmaaaarrrrkkkkssss

       I believe the 50% numbers are realistic, and  that  the  90%
       numbers would be accurate only if there turns out to be undo
       difficulty in porting the Motorola emulation code.


       6.  DDDDGGGGLLLL PPPPllllooootttttttteeeerrrrssss////PPPPrrrriiiinnnntttteeeerrrrssss IIIInnnnvvvveeeessssttttiiiiggggaaaattttiiiioooonnnn

       6.1  IIIInnnnffffoooorrrrmmmmaaaattttiiiioooonnnn SSSSoooouuuurrrrcccceeee

       The SDD (San Diego Division) contact for  internal  partners
       supporting plotters is now Donna Ogilvie, TN: 592-8012.  She
       has  been  the  source  of  my  information  concerning  new
       plotters and new plotter languages.

       6.2  NNNNeeeewwww PPPPllllooootttttttteeeerrrrssss

       There are 6 new HPGL-2 devices that will be available  2/90.
       This  includes  3 new Draft Master products, 2 Electrostatic
       products and 1 Paint Jet product.  All of the  new  plotters
       coming  out  of  SDD will use the HPGL-2 command set.  The 3
       new Draft Master products has an HPGL compatibility mode.















       Pascal 3.23           October 19, 1989                    30



       6.3  HHHHPPPPGGGGLLLL----2222

       HPGL-2 is niether a subset nor a superset of HPGL; therefore
       it  is  not  necessarily backwards compatible with HPGL.  As
       explained to me, HPGL-2 used HPGL as a basis from  which  it
       was  created.   There  is a kernel of HPGL commands.  I have
       asked for technical details concerning HPGL-2 to be sent  to
       me.

       At this point, if the DGL usage of HPGL is  fully  contained
       in  the  HPGL-2  command  set, then continued support of new
       plotters from SDD will be easy and desirable.   However,  if
       DGL  has  to  be  modified to support HPGL-2, I question the
       ROI.

       The DGL source has been fully searched  for  HPGL  commands.
       The  total  number of unique commands is 29.  This number is
       far greater than expected.  Following is the  list  of  HPGL
       commands used by DGL:

       AF AH AP AS BP DC DF DP EC FS IM IN IP LT
       OA OD OE OH OI OP OS OT PA PD PG PU SG SP VS

       Here is where those commands are used:

       Command         File            Line Number
       -------         ----------      -----------

       AF              DGL_HPGL        141
       AH              DGL_HPGL        140
       AP              DGL_HPGL        126
       AS              DGL_HPGL        164
       BP              GLE_HPGLI       361
       DC              GLE_HPGLI       349
       DC              GLE_HPGLI       394
       DF              GLE_HPGL        659
       DP              GLE_HPGLI       325
       EC              DGL_HPGL        132
       FS              DGL_HPGL        155
       IM              GLE_HPGL        659
       IM              GLE_HPGLI       394
       IN              GLE_HPGL        362
       IN              GLE_HPGLI       246
       IP              GLE_HPGL        366
       IP              GLE_HPGLI       249
       LT              GLE_HPGL        490
       OA              GLE_HPGLI       293
       OD              GLE_HPGLI       339
       OE              GLE_HPGL        616
       OE              GLE_HPGLI       386
       OH              GLE_HPGL        288











       Pascal 3.23           October 19, 1989                    31



       OH              GLE_HPGLI       186
       OI              GLE_HPGL        624
       OI              GLE_HPGLI       394
       OP              GLE_HPGL        224
       OP              GLE_HPGLI       141
       OS              GLE_HPGLI       303
       OT              DGL_HPGL        90
       PA              GLE_HPGL        158
       PA              GLE_HPGL        159
       PA              GLE_HPGL        541
       PD              GLE_HPGL        159
       PG              GLE_HPGL        523
       PU              GLE_HPGL        158
       PU              GLE_HPGL        458
       PU              GLE_HPGL        541
       PU              GLE_HPGLI       325
       SG              GLE_HPGLI       325
       SP              GLE_HPGL        458
       SP              GLE_HPGL        659
       VS              DGL_HPGL        147


       6.4  EEEEqqqquuuuiiiippppmmmmeeeennnntttt nnnneeeeeeeeddddeeeedddd

       At least one of the new Draft Masters will have to  be  used
       for devlepment and test.  I believe one can be borrowed from
       SDD.

       6.5  EEEEssssttttiiiimmmmaaaatttteeeessss

                       50%     90%
       Development     4       8       (in days)
       Documentation   1       1
       QA              2       3




























       Pascal 3.23           October 19, 1989                    32



                                _R_e_f_e_r_e_n_c_e_s



        1. "HP 9000 Series  300  Small  Computer  Interface  (SCSI)
           Sales Training Manual"; 4/88

        2.  Perlmutter, Paul Q; "Small Computer Systems Interface";
           Hewlett-Packard Journal; October 1988

        3. Febvre, Paul; "Compass Product Data Sheet"; 2/89

        4. Schubert, Mike; "Apex Product Data Sheet"; 1/89

        5.  Niland,  Bob;  "Install  and  update  media,  the  next
           generation"; HP Internal Memo; 4/89

        6. "HP 9000 Computing Systems - Price Guide"; 5/89

        7.  "small  computer system interface (SCSI)"; ANSI X3.131-
           1986

        8.  "Common  Command Set (CCS) of the Small Computer System
           Interface (SCSI)"; X3T9.2/85-52; Rev 4.B

        9.  Harrison,  Brad;  "Mushrooming  SCSI Interface Provides
           Variety of Implementation"; HARDCOPY; 1/87

       10.  Lohmeyer,  John;  "Use SCSI devices for multiprocessor,
           smart I/O systems"; EDN; 1/85

       11. Padlipsky M. A.; "The  Elements  of  Networking  Style";
           Prentice Hall,Inc.; 1985

































                                 CONTENTS


       1.  SCSI Investigation Report...........................   2

           1.1   Why do SCSI...................................   2

           1.2   What SCSI is..................................   2

           1.3   What SCSI is not..............................   5

           1.4   SCSI-1 vs. SCSI-2.............................   6

           1.5   Proposed Architecture.........................   6

           1.6   What needs to be done.........................   8

           1.7   Hardware Resources Required...................   9

           1.8   What will not be done.........................   9

           1.9   Estimates.....................................  10

           1.10  Goals.........................................  10

           1.11  Non Goals.....................................  11

           1.12  SCSI Version on PWS and RMB...................  11

           1.13  Common Code: Generic SCSI Driver..............  12

           1.14  Generic SCSI Driver Interface.................  12

           1.15  PWS Software Required.........................  16

           1.16  PWS Disk Changes..............................  16

           1.17  PWS Documentation Changes.....................  16

           1.18  RMB Software Required.........................  16

           1.19  RMB Disk Changes..............................  16

           1.20  RMB Documentation Changes.....................  17

           1.21  SCSI Device Requirements......................  17

           1.22  SCSI Disk Requirements & Issues...............  17

           1.23  SCSI Tapes....................................  18




                                  - i -











           1.24  SCSI Printers.................................  19

       2.  Centronics Investigation Report.....................  19

           2.1   Protocol History..............................  19

           2.2   S300..........................................  20

           2.3   Centronics Company History....................  20

       3.  Centronics on PWS...................................  20

           3.1   I/O Subsystem.................................  21

           3.2   Printer TM....................................  23

           3.3   Tests.........................................  23

           3.4   Documentation.................................  23

       4.  Estimates...........................................  23

       5.  68040 Investigation Report..........................  24

           5.1   Internal Use Only.............................  24

           5.2   68040 Features................................  24

           5.3   Outline of Tasks..............................  26

           5.4   Estimate of Tasks.............................  26

           5.5   Summary - Estimate of Effort - PaWS on
                 68040.........................................  29

           5.6   Concluding Remarks............................  29

       6.  DGL Plotters/Printers Investigation.................  29

           6.1   Information Source............................  29

           6.2   New Plotters..................................  29

           6.3   HPGL-2........................................  30

           6.4   Equipment needed..............................  31

           6.5   Estimates.....................................  31

           References..........................................  32




                                  - ii -














                             LIST OF FIGURES


       Figure 1.  The OSI Reference Model layers [11]..........   5

       Figure 2.  SCSI Block Architecture......................   7

       Figure 3.  OSIRM and SCSI...............................  14











































                                 - iii -




