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

[nparker@cie-2.uoregon.edu (Neil Parker)]

In article <19970204162900.LAA11610@ladder01.news.aol.com>
rubywand@aol.com writes:
>In article <32f3c9f7.1063491@167.152.149.11>, drsmooth@relex.com (Edhel
>Iaur, Esq.) writes:
>>
>>That reminds me: I have a disk called "RANDY'S FAVORITE COPY PROGRAMS
>>VOLUME  # 2".  The first line in the HELLO program is:
>>
>>1 POKE 47102,236: REM  SPEED DOS UP
>>
>>Anybody know if this actually does anything, and how?
>>
>>The DOS that comes on this disk, interestingly enough, is PRONTO-DOS.
>>It could have been transplanted, tho.
>[...]
>     So, while the speed-up is not, usually, very great; it _is_ a
>speed-up. If a bit more testing indicates that there are no bad side
>effects, DOS 3.3, ProntoDOS, ... users might as well install the patch as
>a permanent improvement.

Yes, the speed-up *does* work, and my examination of the RWTS code supports
your measurements (which I omitted above to save bandwidth).  A
quick-and-dirty calculation suggests that the original value of 216 ($D8)
produces a start-up delay of about 1 second.  The modified value (236, $EC)
seems to produce a 1/2-second delay, which nicely accounts for the
1/2-second savings that you noticed.

But I *don't* recommending installing this patch permanently.

The original 1-second delay is the amount of time recommended by Shugart,
which manufactured the innards of the original Disk II.  Though we can
probably assume that 1 second is a somewhat conservative figure, we must
also assume that Shugart chose that figure for a good reason--namely, that
that's about how long it takes to guarantee that the disk is spinning at
full speed.

You *really* don't want to try accessing the disk drive when the disk is
spinning at significantly less than full speed, as it will be if you cut
too much time off the start-up delay.  Apple's disk controller is somewhat
fussy about data timing:  bits are expected to come in at 4-microsecond
intervals.  If the disk is spinning too slowly, then the bits will appear to
be more than four microseconds apart, and the controller will insert extra
bits that aren't really there, thereby corrupting the data stream.

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.

DOS does contain some protection against these problems...it won't start
doing any sector reads or writes until it recognizes the correct sector
header, which becomes increasingly difficult as the speed decreases.  If it
can't find a valid sector header, it keeps trying for a while, giving the
disk more time to spin up (this is probably why you reached your point of
diminishing returns at 246, which corresponds to a 1/4-second delay).

But still, by making this patch, you're gaining the speed improvement at
the expense of reliability.  The more you try to push it, the more likely
you are to run into problems.

You're much better off just using ProntoDOS or some other fast DOS, and
not trying to squeeze additional miniscule speed increases out of
less-than-totally-reliable techniques.

               - Neil Parker
-- 
Neil Parker, nparker@{cie-2,cie}.uoregon.edu, http://cie-2.uoregon.edu/~nparker
                     "Bad move, Neil!"  -- The Tick

Unsolicited commercial e-mail to my address will be discarded unread.