Re: DOS 3.3 versions

[mjmahon@aol.com (MJMahon)]

>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.

and nparker@cie-2.uoregon.edu (Neil Parker) replies:

>I don't have a copy of Pronto-DOS to play with, but if it's anything like
>normal DOS 3.3, location 47102 contains the high byte of RWTS motor-on
time
>count.  The normal value in this location is 216 ($D8).
>
>The motor-on time count is used by RWTS when it first turns on the disk
>drive.  It controls how long RWTS waits for the drive to come up to full
>speed.  The larger the contents of location 47102, the less time DOS
waits
>for the disk to spin up.
>
>So yes, I guess this POKE really would cause a slight speed-up.  But
>resorting to methods like this strikes me as riding the ragged edge:  DOS
>has that start-up delay built in because it NEEDS the delay--you really
>don't want to access the drive before the motor is spinning at full
speed,
>for exactly the same reason that you don't want to calibrate your disk
>drive so that it perpetually runs slow.
>
>In summary, I wouldn't trust this POKE--it's trying to gain a slight
>performance improvement at the expense of reliability.  Besides, any
>improvement you get from it will probably be insignificant beside the
>improvement that comes from using a speed-patched DOS like Pronto-DOS.
>(Pronto-DOS and other packages like it gain their extra speed by
techniques
>completely unrelated to this POKE.)

Yes, but...  Disk drives have changed a lot since the original SA390
mechanism,
and any half-height drive will get up to speed _much_ faster than the
rather
conservative delay used in DOS 3.3.  Another place you can cut delays is
in
the seek delay routine.  (I forget which byte to patch to scale all the
seek step
delays--I'll bet someone remembers!)  The seek patch is remarkable, since
you can hear the head moving faster--like it's had too much coffee!   ;-)

I agree that these delay patches don't speed things up as much as avoiding
the
copy (like Pronto-DOS, et al.), but the perception of faster operation and
lower
latency is quite satisfying!

Cheers,

-michael