Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!aero-c!gumby.dsd.trw.com!trwind!venice!press
From: press@venice.SEDD.TRW.COM (Barry Press)
Newsgroups: comp.periphs.scsi
Subject: Re: <12788@xstor.com>
Message-ID: <1123@venice.SEDD.TRW.COM>
Date: 12 Jun 91 20:16:38 GMT
References: <12788@xstor.com> <283400137@adaptx1>
Reply-To: press@venice.sedd.trw.com (Barry Press)
Organization: TRW Systems Engineering & Development Division, Redondo Beach, CA
Lines: 25

In article <283400137@adaptx1> neese@adaptx1.UUCP writes:
>I wrote SETSCSI just for this purpose.  I put it in a batch file before
>calling FASTBACK and then call SETSCSI with no arguments afterwards to reset

Roy, can you check me on some empirical observations re SETSCSI?

1.  It looks like (I disassembled it) it uses spin loops to check for timeout
when talking to the adapter.  This seems to be a problem on a 25MHz 486,
although there may be an interaction with the next issues.

2.  It looks like SETSCSI conflicts with ASPI4DOS.SYS -- it simply wouldn't
run reliably unless I removed the device driver.  I suspect that the driver
was fielding an interrupt that SETSCSI wanted.

Between the two, I can't find a way to make SETSCSI run in my configuration.
Even if I slow the CPU down and patch the timeout loop to run longer, the
lack of the device driver is a problem for running Windows, Smartdrive loaded
high under DOS 5, etc.

Is there another way to solve these problems I've overlooked?

Thanks.

-- 
Barry Press                                 Internet: press@venice.sedd.trw.com