[comp.sys.atari.st] ATTENTION SPECTRE 128 OWNERS with fast SCSI drives

Z4648252@SFAUSTIN.BITNET (Z4648252) (09/27/89)

    As David Small said, some fast SCSI drives will require the slow
SCSI option to be selected.  Otherwise, one is liable to get read/write
errors, etc.  With the slow SCSI option, the problems are cleared and
the performance is not that much slower but it is slower than an ATari SH 204!.
    However, if a Spectre 128er is in a university environment where
other systems abound and the 128er is constantly under examination by
real MACers, then SLOW becomes the S word.  He will want to push his
emulator 'to the envelope' without crashes and errors.
    I'm using the SeaGate 296n.  Yeah, I've been reading all the talk
about interweave problems and ROM bugs, but even at 2:1 interweave,
the mechanism is still fast.  It is so fast, that slow SCSI option has
to be selected.  For my system, that slows things down so much, across
the board, that my hard drive I/O results in access slower than my
creaking SH 204 hard drive!!!
    Ok, there is a solution.  Very easy, in fact.
    Note that I don't have the GCR....
    By getting rid of SoundMaster and Magic Beep, one can have a toggle
that will slow down the emulator.  Yep, it is the sound toggle, the
ESCape key.  Select 11 for the sample rate, as David says.  You get
rid of SoundMaster and Magic Beep because they hang and give uncontrollable
results when the sound option is selected.
    What happens now is that we get David's 'OOGAH' beep.  Fortunately,
there is NOTHING in the system now that will cause the system to remain
slow once a beep occurs, as it would if we left SoundMaster on.
    Also, and fortunately, via the aforementioned ESCape key toggling,
we can now slow the emulator down.  This means that large files, which are
a minority anyway, will transfer and boot up.
    For a test, I attempted to transfer FullWrite (awesome program [!!])
to another partition while in fast SCSI.  Nope, it choked.  No problem,
press the ESCape key.  Yep, it transferred just fine.  In fact, one
can tap the ESCape key a second after the transfer occurs and return to
fast SCSI mode for a faster transfer.
    Excel caused crashes in fast SCSI.  Tap the ESCape key.  Yep, it
boots up just fine.  After it loads, just tap the ESCape key again to
return to fast SCSI.  No problem.
    Just experiment with your large files and you too can keep your
fast SCSI option across the board.  No more of this creaking-running-
slower-than-an-SH 204 while using a 296n.

Larry Rymal:  |East Texas Atari 68NNNers| <Z4648252@SFAUSTIN.BITNET>

dlm@druwy.ATT.COM (Dan Moore) (09/29/89)

in article <890926.11092003.048625@SFA.CP6>,
Z4648252@SFAUSTIN.BITNET (Z4648252) says:
>     As David Small said, some fast SCSI drives will require the slow
> SCSI option to be selected.  Otherwise, one is liable to get read/write
> errors, etc.  With the slow SCSI option, the problems are cleared and
> [ ... ]
>     I'm using the SeaGate 296n.  Yeah, I've been reading all the talk
> about interweave problems and ROM bugs, but even at 2:1 interweave,
	^^^^^^^^^^ should be interleave
> the mechanism is still fast.  It is so fast, that slow SCSI option has
> to be selected.  For my system, that slows things down so much, across
> the board, that my hard drive I/O results in access slower than my
> creaking SH 204 hard drive!!!

	You have the problem backwards.  Some SCSI drives (mostly
Seagate SCSI drives) are too slow, not too fast.  These drives do not
correctly respond to a new SCSI command if it is received "too soon"
after the completion of a previous command.  (eg. issue a read command
for 10 sectors and as soon as that read completes issue another for 8
sectors, the second read command will fail on drives that have this
bug.)

	There are two different "speed" issues involved.  One is the
data transfer rate which is set by the drive interleave.  The second is
the speed at which the drive can accept SCSI commands.  A "fast" drive
that transfers data quickly may or may not have problems with accepting
SCSI commands quickly.




				Dan Moore
				AT&T Bell Labs
				Denver
				dlm@druwy.ATT.COM