From: ralph@falcon.SLAC.Stanford.EDU (Ralph Becker-Szendy)
Newsgroups: comp.periphs.scsi
Subject: Re: WANTED: tips and driver code for 33C93A SCSI chip
Date: 1 Sep 92 22:43:08 GMT
Organization: Stanford Linear Accelerator Center

In article <BtpJ5r.Iqq@world.std.com> sja@world.std.com (Stuart J Adams) 
writes:
>We are in the process of writing a SCSI driver for a WD/Am33C93A
>chip. I am looking for any tips as well as example code if anyone
>has some. Our host processor is an 68HC11 but we will most likely
>be using C.
>
>Thanks,
>Stuart Adams
>sja@world.std.com

1. Get the bug sheet from WD. There are about five pages full of bugs,
   some of which you have to know about. If WD refuses to give it to
   you, I could send you a copy.
2. Try to squeeze any sort of application note or sample code out of
   WD. I failed at that. Maybe they don't exist. WDs customer support
   and technical information is atrociously bad. I didn't try to get
   documentation for the Am part (when having the problems with the 
   western digital chip, I was not aware that AMD has second-sourced
   it). Maybe AMD is more helpful than WD. Furthermore, Hewlett-Packard
   second-sources the 33C93, but when I last checked not the 33C93A.
   If they do now, their part may also be better behaved (see below).
3. Based on rumours, not first-hand experimence: If at all possible, 
   don't use the WD part. Use the Am instead. The WD supposedly is very 
   sensitive to glitches on the status lines, and will get confused all
   the time due to them. The Am part is supposedly much safer to use in
   that respect. In my case, the part would frequently interrupt select-
   and-transfer commands due to "unexpected phase change", but when 
   looking at the phase, it was perfectly correct. I felt that changing
   the design to use another SCSI controller would be less pain than 
   writing the handlers to manually deal with all possible phases.
4. In talking to a major WD33C93A user (a company in the rocky mountains
   which makes helical-scan video tape drives), I found that they are
   so unhappy with the 33C93A that they will be moving to other chips
   with the next major revision of their product. So the problems with
   it are not just my imagination.
5. If at all possible, don't use the 33C93A. Instead I suggest the NCR
   53C90 (which I think is second-sourced by Motorola). Reason: It works,
   the 33C93A doesn't. Let me explain that statement. The 33C93A has many
   quirks and bugs you have to work around. It takes more commands and
   and generates more interrupts for the same task. It is relatively slow. 
   Support for it ranges from "sucks" to non-existing. The NCR 53C90 is 
   quite the opposite. It seems to work as advertised (at least as far as 
   I have used it). It has more complex commands, and generates much fewer
   interrupts for each SCSI transfer. The DMA is not quite as flexible, but
   should be good enough. It is faster. Support is very good, and you get a
   lot of documentation and sample source. The biggest catch in my book: It
   is a 68-pin PLCC (instead of 44-pin), because the SCSI lines are doubled
   into transmit and receive lines (which is a waste for the standard single-
   ended inteface). I'd love to have a part with the same specs in a smaller
   package. 
   Note: The 53C90 is not the 5380. The 53C80 is a glorified parallel port,
   and you have to handle most of the SCSI protocol yourself. The 53C90 is
   much smarter.

Another note: You may be boycotting AT&T (I am, due to the X-window
patent and the BSDI/Berkeley suit nonsense they are trying to pull). I
make it a point to extend that boycott to NCR, which after all is
owned by AT&T now. You may ask where I got my NCR 53C90 from while
boycotting them: free sample (so they have lost money on me). That's
why I am so interested in the fact that Motorola seems to second-
source the 53C90 (they have a part with that number which is billed as
a SCSI-interface, but so far I have not managed to tickle a data sheet
for it out of Motorola).

Last: I have no relation with either WD, AMD or NCR, other than as an
unhappy customer (in the case of WD), or a happy non-customer (in the
case of NCR).  My employer wouldn't know a SCSI controller if
he/she/it found it floating in the soup bowl, and is unlikely to have
an opinion on their relative merits. I am boycotting AT&T and their
subsidiaries as a private individual, not as an employee of the
federal government, the DoE, or Stanford University (although I'll do
my best to steer official purchases away from them, as far as I can
within laws and regulations).

-- 
Ralph Becker-Szendy                          RALPH@SLACVM.SLAC.STANFORD.EDU
Stanford Linear Accelerator Center                      RALPH@SLACVM.BITNET
M.S. 95, P.O. Box 4349, Stanford, CA 94309                    (415)926-2701
My opinion. This is not SLAC, Stanford U, or the US DoE speaking. Just me.