Re: Edhel finds DOS 3.3 speed-up (was DOS 3.3 versions)

[kentd@cup.hp.com (Kent Dickey)]

In article <5dbv42$mje@crl4.crl.com>, Sam Ismail <spam@spam.org> wrote:
>Neil Parker (nparker@cie-2.uoregon.edu) wrote:
>: You *really* don't want to try accessing the disk drive when the disk is
>: spinning at significantly less than full speed, ....
[snip]
>: Writing to the disk under these circumstances can be especially dangerous:
>: if DOS somehow manages to decode what looks like the right sector header when
>: the disk is spinning too slowly, then the data will be written at that slow
>: speed, possibly producing a sector which is completely unreadable at full
>: speed.
>
>While your technical explanation is perfectly accurate, your dire warnings
>of impending doom are highly over-stated, as the worst that could happen
>is DOS will not find a good prologue in time and will, worst case, attempt
>a recalibration.  And I can't even see this as happening since DOS allows
>more than enough time to identify a correct prologue before it recalibrates
>the drive (at least 6-8 spins).

The unlikely happens very fast, and the impossible happens a little less often.

Neil Parker is correct: Setting the delay too low could be dangerous.
How low is dangerous would need to be measured.

Scenario:  Disk running too slow, about 5us per bit or so.  It seems
very likely you could READ a valid address prolog at this point since the
IWM state machine has enough slop to tolerat pretty significant bit
arrival mistimings.  (It's been a while since I calculed this, but
it's like 6us or so).  A valid addr field is $d5 aa 96 ff fe aa aa ae ab fb ff de aa.
If we get "lucky" and read that, then when RWTS tries to write, it will
try to send bits every 4us.  This could cause bits to be too close, which
could cause 0 bits to be missed when the disk is read at full speed.
Why: We're writing every 4us, but the disk is spinning at 5us.  That means
when the disk spins faster (4us), the bits will be just 3.2us apart.
This could be low enough that the drive could read two 0 bits as just
one 0 bit--corruption.  Chances are, this will still work with a given
drive, but moving the disk to another drive may fail.  A drive spinning
fast aggravates the problem.  It could get really bad if the loss of
bits occurs during the sync field before the data header--the data
header would be "lost" and unreadable from then on.  (This is critical
since 5 bytes in a row have 2 zero's in them, and if any of them are
missed, you may not sync with the data stream, and miss the d5 aa ad.)

So data corruption could definitely happen since reads allow sloppier
timing than writes.  A clever routine (bit copier-like) that attempted
to gauge disk spin speed could prevent this case (by delaying until
it read sync bytes in a minumum amount of cycles), but I doubt anyone
will write this...

If you don't care about your data, or you only run pirated games,
go for the speed!  If you write to your disks a lot, it's probably
best to not mess around here too much.  But, if you've already
raised your clock frequency above spec, you have nothing to lose...
I used to cut notches in disks to store data on the back, but I
can at least admit that it made things less reliable.

Apple II hardware is getting old--I already have several unreadable
disks.  I don't want to do anything to make the system less reliable
now.

Kent Dickey
kentd@cup.hp.com
HP has nothing to do with Apple IIs...