** 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. .