Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!decwrl!labrea!polya!kaufman
From: kaufman@polya.Stanford.EDU (Marc T. Kaufman)
Newsgroups: comp.periphs
Subject: Re: SCSI interfaces
Message-ID: <6486@polya.Stanford.EDU>
Date: 31 Jan 89 16:29:00 GMT
References: <1138@naucse.UUCP> <5340003@hpfcdc.HP.COM> <317@entec.Wichita.NCR.COM>
Reply-To: kaufman@polya.Stanford.EDU (Marc T. Kaufman)
Organization: Stanford University
Lines: 28

In article <317@entec.Wichita.NCR.COM> jlohmeye@entec.UUCP (John Lohmeyer) writes:

>There are several ways that the MAC deviates from "typical" SCSI (I didn't
>say "standard"). A few that I can think of off the top of my head are:

- 1. It doesn't terminate the bus at the MAC end of the cable.
     If the MAC has an internal disk, the bus is terminated at the disk,
     which is one end of the cable.

- 2. It doesn't handshake bytes properly (this may have been fixed).
     Fixed in later (+, II) hardware.  However the software does not handle
     abnormal terminations of "blind" read/write properly, and may lose the
     last character if the count doesn't match.

- 3. It won't boot from a SCSI disk that reports unit attention after
-    power-up (required by the SCSI standard).
     Neither will it boot from a disk that doesn't have an Apple driver on it.
     This is a software problem, though, and should be fixable.

>(Actually, all of the above are violations of the SCSI standard.)  In addition
>to these problems, Apple didn't go out of its way to make it easy to add on
>third-party SCSI devices. (Nor did they really try to block add ons.)

     True on both counts.  I have added an output-only device... but I had to
     implement a "Read" instruction that returned with no-error in order for
     the Mac to boot with the device on the bus.

Marc Kaufman (kaufman@polya.stanford.edu)