
   UPDATE NEWS:

   - version 1.21 has been tested with 1.2.13pl9 and 1.3.86.
     It includes many changes and enhancements, including:
     + A new user-friendly command-line interface has replaced the
       old method, so you'll want to read the comments for
       'setup_strings' near the top of wd33c93.c. Lots of people
       do something like "wd33c93=255" or whatever to turn off
       sync negotiation; relax - this still works.
     + The driver defaults to something I'm calling "adaptive
       disconnect" - meaning that each command is evaluated
       individually as to whether or not it should be run with the
       option to disconnect/reselect (if the device chooses), or
       as a 'SCSI-bus-hog'. When several devices are operating
       simultaneously, disconnects are usually an advantage. In a
       single device system, or if only 1 device is being accessed,
       transfers usually go faster if disconnects are not allowed.
     + The clock speed of the WD33c93 chip can be specified on the
       command-line if you have a faster card.
     Also incorporated into this version are improvements by:
     + Matthias Welwarsky - fixed a bug in command-line handling
     + FEF (who's this?) - GVP cards can use CHIP ram for DMA buffers
     + Roman Hodek - sync negotiation OFF by default

   - version 1.17 should be much more stable under heavy SCSI
     activity (ie, with more than 2 devices on the bus at the
     same time). I found a couple of bugs that would show
     themselves in those circumstances once in a while. The
     sync-transfer stuff is better now, and should conform
     more closely to the SCSI-2 spec. Added some more
     comments and some experimental code for higher
     "LEVEL2" settings (doesn't work yet).

   - version 1.16 should fix the audio CDROM headaches
     people have reported! The WD chip doesn't know
     how to handle Group 2 commands on it's own (needs
     to be told the length of the CDB), and I wasn't
     taking that into account.

This is a rewrite of the wd33c93.[ch] files for Linux-68k.They
are drop-in replacements for the originals in linux/drivers/scsi
- just copy them over the old ones. I've tested the new driver
with a2091 and gvp11 cards, and others have tried it on A3000's
with good results. There are apparently some GVP '040 accelerator
cards that identify themselves as gvp-11 compatible, but don't
work properly - I don't have one so someone else will have to help
get these going. I haven't attempted to load this driver as a module
because the module code in the kernel isn't working 100% yet.

You might try 'ENABLE_CLUSTERING' in the multi-line #define in
a2091.h/gvp11.h/a3000.h - Hamish is concerned that computers with
more than one chunk of RAM will choke when this is enabled, but
I'm not so sure. I've tried to use his "fall-back-to-pio-if-buffer-
spans-chunks" technique, and if I got it right, it seems to me that
enabling clustering should be safe on any machine. Maybe not, but on
mine it gives me about a 20% boost in speed, on the average, so it's
certainly worth trying!
There's also a define called 'DEFAULT_SX_PER'; this sets the data
transfer speed for the asynchronous mode. I've put it at 500 ns
despite the fact that the cards could handle settings of 376 or
252, because I'm not really sure if certain devices or maybe bad
cables might have trouble at higher speeds. You can change this
from the command-line if you suspect trouble. I couldn't find any
info in my various SCSI references that talk about this in language
I could understand, so decided to compromise with 500. This is still
faster than the old driver was set at (I think). Can someone explain
the significance of the bus transfer speed setting? Do devices on
the bus ever care what it is? Is cable quality a factor here?

  <ANSWER> - Devices don't usually care, but yes; the faster the
  transfer speed (async OR sync), the more likely that you'll get
  errors due to noise on the bus. Low quality cables, cables that are
  too long, improper termination - these all bring about marginal
  electrical conditions that are exacerbated by higher speeds.

Anyway.
I have run a LOT of tests on this driver, and it seems very solid,
including with up to 3 simultaneous large copy or tar commands
running between 6 devices at once. Synchronous transfers seem to
work fine with most devices. Tape drives work well, and I don't
have any trouble with CD-ROM drives, either.

Please try the driver out. Test it, beat on it. And PLEASE get back
to me - I really need to hear about bugs, stupid or bad code,
and any ideas for enhancements.
Thanks very much...

      John Shifflett    jshiffle@netcom.com

