** The following file was uploaded by Eric Horwitz from Alpha Microsystems **
** ERIC/AM **


   After hanging my butt (too far) out the window with my previous
   posting regarding SCSI, I decided my biggest mistake was trying to
   not get too technical as to why not all SCSI implementations are
   created equal.  The following is extracted from an internal
   memorandum to me from Rod Hewitt, the engineer who is currently
   responsible on our SCSI software and hardware.  I hope it all
   makes sense!


   SCSI SUPPORT ISSUES:

   Various comments have been exchanged recently regarding the SCSI
   bus on the Alpha Micro and why certain drives do and do not work.
   This message is designed to clear up many of the myths of SCSI
   when used on an Alpha Micro.

   HARDWARE ISSUES:

   The Alpha Micro implementation is a true implementation of the
   SCSI-1 protocol.  However, like many standards, the organization
   setting the standard allows vendors many options in configuring
   their implementation of the standard.  In this respect, the Alpha
   Micro does not support the following aspects of SCSI-1:

   Disconnect and re-connect:  As the A/M is a simple host
       adaptor it does not have an ID assigned on the bus.  Therefore
       SCSI peripherals must complete their transaction prior to
       returning the bus to a bus-free phase.  When a target is
       selected by the A/M, only one ID bit is placed on the data
       bus, informing the target that the system does not support
       this part of the SCSI specification.

   Multiple host:  Fully implemented SCSI-1 allows multiple host
       adaptors to be present on the SCSI bus.  The A/M does not
       allow this as the host adaptor has no bus ID and therefore
       cannot arbitrate for the bus.  The lack of multiple host
       support circumvents usage of the SCSI COPY command (which is
       really only useful when performing image backups; something
       AMOS hasn't done in years).

   Parity:  Some devices require that parity be present on the
       SCSI bus in order for them to communicate correctly with the
       host.  A/M's implementation does not connect anything to pin
       18 (DBP* signal).

   Synchronous communications:  the transfer protocol used
       between the A/M and the target SCSI device is asynchronous in
       so much as the REQ signal must be presented to the host prior
       to host latching them data in form the data bus.

   While it may look depressing that the above features are not
   supported, in reality this doesn't matter so much as the design of
   the SCSI bus on the A/M is very fast and the cache system used by
   AMOS compensates for the lack of disconnect/re-connect.  Testing
   has shown that using tape peripherals on the A/M SCSI bus driven
   by a 25MHz 68020 CPU, speeds of around 15 Mbytes per minute can be
   achieved.

   As far as AM-1000 systems go, there is an Engineering Notice ("EN")
   to bring the SCSI implementation to the same standard as other A/M
   computers.  This EN (also available for the AM-405 controller)
   fixes a REQ/ACK handshake problem that occurs when anything faster
   than a Xebec 1410A controller is attached to the system.

   SOFTWARE ISSUES:

   Just as with hardware, the SCSI standard allows flexibility in
   software commands.  Drive vendors are allowed to implement vendor
   unique commands to control certain aspects of their drives.  This
   is very apparent with the mode select command.  The 625DVR.DVR
   parameters on Tandberg streaming tape drives.  If you attempted to
   use an Archive Viper in place of the Tandberg, DEVTBL will fail
   with a device initialization error as the mode select command is
   different between the two drives.

   As far as the FMTSCZ program goes, it may have problems
   communicating with unsupported disk drives for a whole variety of
   reasons.  Firstly, FMTSCZ issues an inquiry command to the drive
   to see if the drive manufacturer and model number are known to
   A/M - if not, the drive is listed as unknown and unsupported.
   Unknown and unsupported simply means we have either evaluated the
   drive (and we evaluate a LOT of disk drives) and decided not to
   use it (speed, reliability, cost, compatibility, MTBF, etc. are
   factors why we don't support certain drives) or that we've never
   seen this particular drive before.

   After the inquiry command, FMTSCZ sends mode sense and read
   capacity commands to the drive to calculate both its real size
   and its usable size from the operating system's point of view.
   For example, 50mb drives will get formatted down to 40mb as that
   is a size that A/M supports from a marketing point of view, and
   allows A/M to sell 40mb drives from various vendors despite the
   fact that each drive may have a slightly different size.  The head
   count, cylinder size, number of cylinders, etc. are read from the
   drive in order to calculate the size of the diagnostic cylinder
   and to configure the hidden sector (used by BITMAP to
   automatically calculate the bitmap size).

   In addition to the above SCSI commands, the drive must perform a
   multitude of other SCSI commands correctly, or it won't format
   correctly with FMTSCZ.  A case in point is the Quantum drives A/M
   sells.  When they spin up, if you send continuous "test unit
   ready" commands to the drive, it will lock up as only one CPU is
   used for both the SCSI bus and drive control.  We had to modify
   the system boot PROMs and FMTSCZ to insert delays between test
   unit ready commands in order for these drives to work with A/M
   computers.  This problem is unique to Quantum and we were able to
   fix it, but a "Drives-R-Us" drive may have some other quirk that
   you'll run into if you don't use drives supported by A/M.

   As far as the SCZDVR is concerned, no special modifications are
   required.  If a drive passes through FMTSCZ correctly, chances are
   it'll work with SCZDVR, but unless you use a supported drive with
   _exactly_ the same firmware version that we ship, there are not
   guarantees.  An example of "exactly the same firmware" is the
   Maxtor LXT-200 drive currently being sold by A/M.  The drive we
   supply has a special version of firmware that stops the drive from
   crashing when powered up on an A/M at the same time as the CPU.
   When A/M computers power up they will pulse the SCSI reset signal
   to ensure all drives are at a known state (there is no SCSI
   definition on what to do with reset upon system power up).  The
   firmware used on A/M supplied drives ignores the SCSI reset signal
   during power up and will therefore boot; the same drive out of
   distribution will not have this special firmware and hence will
   not work unless the drive is powered up after the CPU is turned on
   (which is a pain to do).

   You don't have to have the drive defined with a DEVTBL command in
   order to format it.  FMTSCZ "searches" through the SCSI bus to
   find SCSI disk drives.

You are viewing proxied material from gopher.floodgap.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.