NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/ibm/pc/hardware/37161

Text File | 1993-01-25 | 24.6 KB | 561 lines

Newsgroups: comp.sys.ibm.pc.hardware
Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!col.hp.com!news.dtc.hp.com!srgenprp!darrylo
From: [e-mail] (Darryl Okahata)
Subject: Adaptec hints & tricks
Sender: [e-mail] (placeholder for future)
Message-ID: <[e-mail]>
Date: Tue, 26 Jan 1993 03:02:16 GMT
Reply-To: [e-mail]
Organization: Hewlett-Packard / Center for Primal Scream Therapy
X-Newsreader: TIN [version 1.1 PL8.5]
Lines: 548

     A few months back, I asked for help getting my Adaptec 1542 card
working with Windows 3.1.  Here's a summary of what I discovered, as
well as other interesting information pertaining to the Adaptec 1542.

     -- Darryl Okahata
    Internet: [e-mail]

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion or policy of Hewlett-Packard or of the
little green men that have been following him all day.

===============================================================================
$Id: adaptec.txt 1.8 1993/01/25 00:55:08 darrylo Rel darrylo $
          Hints and Tips for the Adaptec 1540/1542 SCSI adapter


     This document contains hints and tips for getting the Adaptec
1540/1542 SCSI adapter to work with various hardware and software
packages.  They are based upon my experiences with an Adaptec 1542A
controller, and will, hopefully, help others.  However, note that I
cannot guarantee that the following will really help you (it works for
me), and the information in this document could possibly cause you to
lose some or all of your files on your hard disk.

     IMPORTANT!  BACK UP THE ENTIRE CONTENTS OF YOUR HARD DISK BEFORE
TRYING ANYTHING BASED UPON INFORMATION IN THIS DOCUMENT.

     Copyright 1993, by Darryl Okahata.  This document may be freely
copied for personal use only, and may not be reprinted in a for-profit
publication without the consent of the author.  Please note that I have
no connection with Adaptec other than as a customer.

Topics covered in this document:

    * Windows 3.1 enhanced mode
    * Floppy-controller-based tape backup devices
    * Sound cards
    * Miscellaneous info

     Please note that parts of this document contain technical, and
sometimes terse, descriptions of problems.

For reference:

    Adaptec technical support:    [phone]
    Adaptec BBS (2400/9600):    [phone]

Please send comments, corrections, etc. via email to me:

    CompuServe:    75206,3074
    Internet:    [e-mail]


***** Windows 3.1 enhanced mode:

     The Windows 3.1 install program should automatically configure DOS
and Windows for use with the Adaptec 1542.  However, just in case
something went wrong, I'm going to describe some of the changes needed
to get Windows 3.1 working with the 1542.  Also, you may have noticed
that installing Windows 3.1 makes your PC run much slower, even when
you're not running Windows; methods of speeding it up are discussed in
the section called, "Windows 3.1 runs slowly".


* MSDOS configuration:

     The Windows install program adds the SmartDrive disk cache to your
CONFIG.SYS and AUTOEXEC.BAT files.  If you follow the instructions,
you'll notice that you'll need to use double-buffering with SmartDrive
(this is the default setup).  You'll also notice that your system runs
much, much slower -- in both Windows *AND* MSDOS.  See the section
called, "Windows 3.1 runs slowly", for some ways of speeding your system
up.


* Windows configuration:

     To get the Adaptec 1542 to work with Windows, make sure that the
"[388Enh]" section of the SYSTEM.INI file contains the entry:

    VirtualHDIRQ=Off

I believe that the Windows install program automatically adds this entry
to SYSTEM.INI, but I'm not sure.  If this doesn't work for you, you
might want to try adding some more lines:

    VirtualHDIRQ=Off
    SystemROMBreakPoint=false
    EMMExclude=A000-CFFF

(You probably don't need the above lines, though.)  The
"SystemROMBreakPoint" entry is used to enable support for memory
managers like QEMM/386MAX (only needed if you use such programs).


* Windows 3.1 runs slowly:

     Once you do get Windows 3.1 running with the 1542, chances are that
your system is running much slower than before.  If it's not, it's
probably because:

     1. You happen to be using ASPI4DOS.SYS version 3.1 in your
    CONFIG.SYS file.  Congratulations -- this appears to be a
    winning solution.

     2. You are very lucky.  Whether your luck will hold out remains to
    be seen ....

If your system is running much slower than before, this is almost
definitely caused by Smartdrive with double-buffering.  According to the
Windows documentation, and the Microsoft technical note #Q81808
("SMARTDrive Double Buffering Required with ASPI4DOS.SYS"), you must use
Smartdrive with double-buffering enabled.  While this works, it really
slows down your PC; I once estimated that this slowed my PC down by a
factor of 5 (FIVE).  As I consider this unacceptable, I looked for other
solutions.

     Unfortunately, you cannot just disable double-buffering.  If you
do, Windows 3.1 in enhanced mode will not work, and you might even
destroy the contents of your hard disk by trying to run Windows 3.1.
What you can do is one of the following:

     1. Use other drivers that provide double-buffering.  It is my
    opinion that the unbelievable slowness in Smartdrive is caused
    either by horribly inefficient double-buffering, or by a bug in
    Smartdrive.

     2. Use a driver that provides "VDS" services ("VDS" stands for
    "Virtual DMA Services").  This is a standard, which is supported
    by Windows 3.1, that allows bus-mastering disk controllers (like
    the 1542) to work with Windows.

     After trashing my hard disk countless times, I found the following
solutions, none of which require using Smartdrive (note, however, that I
am now getting occasional parity errors, which are probably *NOT* caused
by these solutions, but might be -- see below).  While the following
does not require Smartdrive, using some kind of disk cache utility is
strongly recommended, as this makes Windows run much, much faster:

1. If you do not have the ASPI4DOS.SYS driver, or you do not need ASPI
   functions (for controlling a CDROM, tape drive, more than two
   physical hard disks, etc.), you can add the SCSIHA.SYS driver to your
   CONFIG.SYS file, e.g.:

    DRIVER=c:\SCSIHA.SYS /V386

   (Windows needs the "/V386" option.)  This driver MUST be loaded into
   LOW memory (it cannot be loaded into high memory), and it occupies
   about 16-20K.  As of November 1992, the SCSIHA.SYS driver could be
   obtained from the Adaptec BBS at (408)-945-7727 (hopefully, it's
   still there).

2. If you need ASPI functions and have the ASPI4DOS.SYS driver, version
   3.0 or 3.0a, you can use both the ASPI4DOS.SYS and SCSIHA.SYS drivers
   in your CONFIG.SYS file, e.g.:

    DRIVER=c:\ASPI4DOS.SYS
    DRIVER=c:\SCSIHA.SYS /V386

   Amazingly enough, the SCSIHA.SYS driver can also be loaded high
   (assuming you have DOS 5.0); I would have thought that this would
   crash my system, but it doesn't.  I asked Adaptec's technical support
   about this, and they said that loading SCSIHA.SYS high should be fine
   as long as ASPI4DOS.SYS is loaded LOW.

   On my system, NOT using SCSIHA.SYS with ASPI4DOS 3.0a would
   occasionally cause Windows 3.1 to crash upon restarting or exiting
   Windows, with the additional result of a corrupted disk (some of my
   C:\WINDOWS\*.GRP files would be corrupted).  For me, these crashes
   usually occurred while making a different program from PROGMAN.EXE
   the default Windows shell, and vice-versa.  This is the reason
   SCSIHA.SYS may be necessary.

   I have absolutely no idea if SCSIHA.SYS is necessary with versions of
   ASPI4DOS earlier than 3.0.

   Note that many people can use ASPI4DOS 3.0 or 3.0a without
   SCSIHA.SYS; they do not seem to have any problems at all.  I consider
   these people lucky.  Others, like me, have had all sorts of problems.

3. In my opinion, the best, but not necessarily the easiest, solution is
   to upgrade to ASPI4DOS 3.1.  The SCSIHA.SYS driver is no longer
   needed.  Unfortunately, while you could get previous ASPI4DOS
   upgrades from the Adaptec BBS, the ASPI4DOS 3.1 driver is not
   available from the Adaptec BBS.  As far as I know, there are only
   three ways to get a copy:

      * You can buy the new (as of November 1992) Adaptec EZ SCSI driver
    kit, which supposedly includes ASPI4DOS 3.1 as well as other
    drivers, such as CDROM drivers.  I believe the list price is
    around $75.

      * If you already have a copy of an older version of ASPI4DOS, you
    can supposedly contact Adaptec to upgrade it to EZ SCSI for
    around $30.

      * A copy of ASPI4DOS 3.1 is included in Central Point PC Tools 8.0
    for MSDOS.  Note that the documentation and driver are stored in
    different directories.  Note further that only ASPI4DOS is
    included; the CDROM drivers and drivers to support more than two
    hard disks are not included.  This is where I obtained my copy
    of ASPI4DOS 3.1.

Note, however, that I am now getting occasional parity errors with
Windows.  In all probability, defective hardware in my PC is causing
this, as I upgraded my motherboard just after I found the above
solutions.  However, because these parity errors occur only during disk
accesses, there is a very small, but definite, possibility that the
parity errors are driver-related (for example, changing the bus on/off
timing for certain disk transfers might cause this).  I've run various
memory tests for hours at a time, and these tests have found no
problems.  This problem is probably caused by memory with marginal
timing requirements, which cause parity errors during disk transfers
(this is why the memory tests didn't find any problems -- the problems
show up only under disk I/O).  However, I'm mentioning this just in case
it isn't a hardware problem.


***** Floppy-controller-based tape backup devices:

     There are two possible problems with using the Adaptec 1542 with a
floppy-controller-based tape backup device, such as the Colorado Memory
Systems Jumbo 250:

1. Tape backups/restores can take a very long time.  The tape drive
   constantly starts, stops, starts, stops, etc.

2. Tape operations may be erratic, or encounter too many tape errors.
   (This problem might be caused by defective hardware on my 1542.
   However, I've heard of other people having similar problems, and so
   I'm mentioning this just in case it is not a hardware problem on my
   1542.)


* Tape backups/restores take a long time:

     If you have a floppy-controller-based tape backup device, you may
have to adjust the Adaptec 1540/1542 "bus on/off timing" for best
results when using the tape drive.  Normally, while doing a tape backup
or restore, the tape drive motor should be continuously running, with
only an occasional pause.  However, the default bus timing on the
Adaptec 1540/1542 may cause the tape drive motor to start and stop,
start and stop, every few seconds.  This causes needless wear to the
tape and tape drive (however, note that a dirty tape head or a defective
tape drive can also cause this -- make sure your tape heads are clean).
This also causes the tape backup or restore to take much, much longer
than necessary.

     The problem here is that these tape backups use the floppy DMA to
transfer data in memory to/from the tape drive, and the Adaptec uses DMA
to transfer data in memory to/from the hard disk.  The floppy DMA needs
to feed data to the tape drive at a certain rate; if the tape drive is
not fed data quickly enough by the floppy DMA, the tape drive stops,
rewinds a bit, and restarts (once enough data is eventually fed to it).
The default bus timing on the Adaptec (which is really DMA timing) is
"too large".  For example, when a backup is done, data has to be
transferred from a hard disk to memory, and then from memory to the
tape.  Because the default timing on the Adaptec "hogs" the memory too
much (too much time is spent transferring data from a hard disk to
memory), not enough time is spent transferring data from memory to the
tape drive.  As a result, the tape drive constantly starts and stops,
because data is not fed to it quickly enough.

     The solution is to change the Adaptec's bus on/off timing.  The
default factory setting is 11 microseconds on, and 5 microseconds off.
The "bus on" timing needs to be lowered to 2-4 microseconds.  This can
be done in one of two ways:

* If you have ASPI4DOS, you can use the "/n" option.  For example, I use
  a "bus on" timing of 4 microseconds, which means that I use the
  following line in my CONFIG.SYS file:

    DEVICE=c:\aspi4dos.sys /n4

  Note that there is NO space between the "/n" and the "4".

* If you don't have ASPI4DOS, your only recourse is to try to find a
  program called "SETSCSI.EXE", which is very difficult to find.  The
  reason is that Adaptec, for reasons of their own, does not seem to
  want this widely distributed.  I once asked someone who worked for
  Adaptec, and they asked me to not upload it anywhere.  If you have
  anonymous ftp access to the Internet, you could try using archie to
  hunt down a copy; I believe that there are a couple of sites that have
  it.  If you do find a copy, you run it like so:

    setscsi -n:4

  This adjusts the "bus on" timing to 4 microseconds.  Running
  SETSCSI.EXE without any arguments resets the bus timing back to the
  factory defaults.

  Note that it seems that you cannot use SETSCSI.EXE if you use
  ASPI4DOS; SETSCSI.EXE crashed my system if ASPI4DOS was loaded.  I
  could use SETSCSI.EXE with SCSIHA.SYS, however.

Do not lower the "bus on" timing below 2 microseconds, or increase it
above 11 microseconds.  If you lower it too low, the hard disk
throughput will suddenly drop; your system will feel slower.  For me, 4
microseconds works fine.  This value may work fine for you, or you may
have to adjust it downwards a little.

     Once you've lowered the "bus on" timing, tape backups and restores
should run faster.

     Also, do not experiment with the bus on/off times (with the other
options that I have intentionally not described), unless you know what
you are doing.  Bad combinations can cause parity errors and worse, by
starving memory refresh.

     A program called BUSTIFIX.EXE exists on the Adaptec BBS.  Unless
this has been upgraded since I last checked (which has been a while),
this is a self-extracting archive containing a batch file and a couple
of other files.  This batch file was supposed to allow one to set the
bus on/off times for the 1540/1542 and others.  However, when I tried
running this program with my 1542A, my system crashed.  At the time, I
was running SCSIHA.SYS, and I didn't check to see if there was a
conflict with it.  Maybe this old program works only with the 1542B,
although the docs say that it works with the 1542A?


* Erratic tape operations or too many tape errors:

     This "problem" may or may not exist.  Although it existed on my
system, a hardware problem just on my particular 1542 could cause it.
However, I've heard of other people having similar problems, and so I'm
mentioning this just in case it isn't a hardware problem just on my
1542.

     Symptoms of this "problem", which persists even after cleaning the
tape head:

1. Backing up to tape encounters "unusable sector detected" errors,
   resulting in an aborted tape backup.

2. Tape backup works, but the tape compare fails.

3. The tape drive starts, stops, starts, stops, etc. much too often.
   Unlike the above-mentioned problem ("Tape backups/restores take a
   long time"), where the tape drive starts and stops every few seconds,
   this kind of starting/stopping occurs every few 10-20 seconds or so.

4. Fastback Plus 3.1 does not find/see any tape backup devices.  Other
   programs, like Central Point Backup and the CMS Jumbo software
   (assuming that you have a CMS Jumbo 250 tape drive) can find/see the
   tape drive, but Fastback Plus 3.1 cannot.

5. Too many tape read errors.

     Although I do not know what is causing this problem, I discovered
that using a different floppy controller solves it.  A few months ago, I
upgraded my motherboard, which contained an integrated floppy
controller.  As I already had a floppy controller on the 1542, I
initially disabled the motherboard floppy controller.  After a while, I
decided to try disabling the 1542 floppy controller and using the one on
the motherboard.  When I did this, the tape drive (a CMS Jumbo 250)
reliability increased dramatically, and Fastback Plus 3.1 was suddenly
able to find and use the tape drive.

     I don't know if this was caused by a hardware problem on my 1542.
On the one hand, the floppy drives worked great when they were attached
to the 1542, which seems to say that there was nothing wrong with the
1542.  On the other hand, the tape drive didn't work well attached to
the 1542 floppy controller, but it did work when attached to a different
controller; this could be an indication of a hardware problem on my
1542.  I did change floppy drive cables, and so it is conceivable that
the problem was in the cables.  I don't know what the cause really is;
however, if you're having similar problems, you might want to consider
trying a new floppy controller.


***** Sound cards:

     Many popular sound cards can play or record digitized sound, and
this is typically done using DMA.  Like the tape drive DMA, the
Adaptec's DMA can conflict with the sound card DMA.  Unlike that of the
tape DMA, this "conflict" usually manifests itself as a parity error
(your system crashes with a parity error message).  What happens is
that, data is being transferred so quickly by the sound card and the
Adaptec, memory refresh cannot occur quickly enough, which causes a
parity error.  Usually, getting a parity error means that there is a
hardware problem with your system; in this case, however, the parity
error is not a symptom of bad hardware.

     I've found that such parity errors typically occur while recording
digitized sound, and the chances of such errors increase as you increase
the recording fidelity (e.g., higher sampling rate, recording in stereo,
recording using 16-bits instead of 8, etc.).

     Like the tape drive solution, the solution here is to lower the
Adaptec's "bus on" timing.  See the section on tape drives for
information on how this is done.  Note, however, that this may or may
not solve the problem; it may only reduce the probability of a parity
error.  The software used to record digitized sound can greatly affect
this problem (i.e., some software is inefficient).  Disk caches, the
speed of your hard disk, and the amount of disk fragmentation can also
affect this.


***** Miscellaneous info:

     This section contains miscellaneous hints, tips, and rumors.  Much
of it is merely information that I've heard or read about, and have not
verified.  I believe that the following information is correct, but I'm
not sure.  Use it at your own risk.

* With QEMM 6.00, 6.01, and 6.02, you need to specify the "DB="
  parameter (e.g., "DB=2"), unless you are using the ASPI4DOS driver.
  If you don't, QEMM will crash/hang at bootup.  Although the QEMM
  manual mentions this, the install program does not seem to detect that
  a 1542 is present and automatically add this option to the QEMM
  command line (at least, this occurred with the QEMM 6.00 install
  program -- I haven't tested any other version).  Earlier versions of
  QEMM probably need this parameter, but I'm not sure (I've never used a
  version earlier than 6.00).

  If you use ASPI4DOS, you do not need to give QEMM the "DB=" parameter.

* Some or all versions of the 1542 do not support hard disks over one
  gigabyte in size.  To support hard disks with capacities over 1GB, you
  need to get a new ROM BIOS from Adaptec.  I'm not sure if this is
  still true of the latest 1542Bs being sold by Adaptec.

* To connect a CDROM drive to the 1542, you need a SCSI CDROM drive and
  some drivers.  Note that some CDROM drives have proprietary interfaces
  (non-SCSI); these drives cannot be used with the 1542.  You have three
  choices for CDROM drivers (I have no idea how well the following
  solutions work, or even if they work -- the following is secondhand
  information):

     1. You can buy Adaptec's EZ SCSI driver package, which lists for
    something like $75.  If you already have older Adaptec drivers,
    you can supposedly upgrade to EZ SCSI for around $30.  Contact
    Adaptec for details.  The EZ SCSI package supposedly contains
    everything that you need.

     2. You can buy the CorelSCSI! driver package, which is made by the
    same people that make CorelDRAW!  This package contains CDROM
    drivers, SCSI tape drivers, WORM drivers, etc.  I do not know
    the list price, but I've seen this package sold for around
    $80-$90.  Note that CorelSCSI! does not come with the ASPI4DOS
    driver, which is needed.  If you do not already have ASPI4DOS,
    you may be better off getting Adaptec's EZ SCSI instead.

     3. [This method is obsolete, as the following drivers have been
    obsoleted by Adaptec's EZ SCSI kit, but I'm mentioning it in
    case someone already has these drivers.]  You can use the
    drivers in the Adaptec ASW-1410 kit (ASPI4DOS) and the ASW-410
    kit (ASPI CDROM drivers).  You will have to get a copy of
    MSCDEX.EXE (a high-level CDROM driver), if it is not included in
    the ASW-410 kit, but this is available from several bulletin
    boards.

* To use a SCSI tape drive with the 1542, you need software that knows
  how to talk to a SCSI tape drive.  Software that I've heard about are
  (again, like the above section on CDROM drives, I have no idea how
  well the following solutions work, or even if they work -- the
  following is secondhand information):

     1. Central Point PC Tools 8.0 for MSDOS supposedly supports a large
    number of SCSI tape drives.  It comes with SCSI drivers
    (ASPI4DOS 3.1) as well as Central Point Backup.

     2. The CorelSCSI! driver package contains a SCSI tape backup
    program (see the above section on CDROM drives for more
    details).  However, note that CorelSCSI! does not come with, but
    requires, ASPI4DOS.

* I've seen advertisements that sell the 1542 in three configurations:

     1. 1542 SCSI controller with hard disk ROM BIOS.
     2. 1542 SCSI controller w/BIOS and Adaptec ASPI drivers.
     3. 1542 SCSI controller w/BIOS, Adaptec ASPI drivers, and
    CorelSCSI! drivers/programs.

  I imagine that Adaptec now sells the 1542 in a fourth configuration:

     4. 1542 SCSI controller w/BIOS and EZ SCSI drivers (including ASPI
    drivers).

* Those people who use Unix might be interested in a version of GNU tar
  for MSDOS that talks to a SCSI tape drive via the ASPI4DOS driver (you
  need this driver before you can use this program).  I've never used
  this version of GNU tar, but I've heard that it works (I don't know
  how well, though).  If you have anonymous ftp access to the Internet,
  a copy can be found on wsmr-simtel20.army.mil and mirror sites:

    PD1:<MSDOS.DSKUTL>
    ASPIBIN.ZIP  67841 920131 Gnu Tar for SCSI tape drives, Adaptec 154xx
    ASPIPAT.ZIP  21206 920131 Patches for ASPIBIN relative to Gnu Tar 1.10
    ASPISRC.ZIP 221370 920131 Src for Gnu Tar for SCSI tape, Adaptec ctrlr

  I have no idea if a copy can be found on Compuserve; UNIXFORUM might
  have it, if any forum does.

* As far as MSDOS is concerned, the 1542A and the 1542B controllers are
  the same; with MSDOS, the 1542A should work as well as the 1542B.
  However, the hardware for these two boards is not 100% identical, and
  there is at least one (NON-MSDOS) program that initially did not work
  with a 1542A, but did work with a 1542B (BSD386 -- a 386 version of
  BSD Unix).

* In case anyone's curious, here's an edited copy of my CONFIG.SYS file:

    FILES=40
    BUFFERS=40
    BREAK=ON
    STACKS=10,256
    DEVICE=c:\sys\dev\aspi4dos.sys /d /n4
    DEVICE=C:\QEMM\QEMM386.SYS on RAM ROM DMA=32 ST:M X=F800-FFFF
    DOS=HIGH,UMB
    DEVICEHIGH=c:\sys\dev\nnansi.sys
    DEVICEHIGH=C:\DOS\SETVER.EXE
    shell = c:\dos\command.com /p

  Note that I'm using QEMM and ASPI4DOS 3.1.  If I were using ASPI4DOS
  3.0 or 3.0a, I'd probably have to use a CONFIG.SYS that looked like:

    FILES=40
    BUFFERS=40
    BREAK=ON
    STACKS=10,256
    DEVICE=c:\sys\dev\aspi4dos.sys /d /n4
    DEVICE=C:\QEMM\QEMM386.SYS on RAM ROM DMA=32 ST:M X=F800-FFFF
    DOS=HIGH,UMB
    DEVICEHIGH=c:\sys\dev\scsiha.sys /V386
    DEVICEHIGH=c:\sys\dev\nnansi.sys
    DEVICEHIGH=C:\DOS\SETVER.EXE
    shell = c:\dos\command.com /p

  If I weren't using ASPI4DOS, I'd probably use something that looked
  like:

    FILES=40
    BUFFERS=40
    BREAK=ON
    STACKS=10,256
    DEVICE=c:\sys\dev\scsiha.sys /V386
    DEVICE=C:\QEMM\QEMM386.SYS on RAM ROM DB=32 DMA=32 ST:M X=F800-FFFF
    DOS=HIGH,UMB
    DEVICEHIGH=c:\sys\dev\nnansi.sys
    DEVICEHIGH=C:\DOS\SETVER.EXE
    shell = c:\dos\command.com /p

  However, if I used a floppy-controller-based tape drive, or if I
  planned to record high-quality sound from a sound card, I would still
  need some way of changing the Adaptec's bus on/off times.  The first
  two versions of CONFIG.SYS take care of this, but this last version
  doesn't.