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

[rubywand@aol.com]

In article <5dbv42$mje@crl4.crl.com>, dastar@crl.com (Sam Ismail) writes:

>Neil Parker (nparker@cie-2.uoregon.edu) wrote:
>....
>: 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.
>
>Like I said, absolute worst case would be a recalibration, in which case
>you lose 2 seconds instead of the 1/2 second gain, but again I can't see
>this happening.
>
>: 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.
>
>I agree.


     Certainly, by sticking with the standard spin-up delay you do gain
something. At the least, there is a feeling of confidence that any
screw-ups are not the result of reducing the spin-up delay. This was
illustrated in some additional testing with the "speeded" DOS.

     A diskette was INITed for the reduced delay (= a POKE 47102,246). The
content of the 1980 DOS 3.3 Master diskette was file-copied to the new
diskette using Copy II+. The idea was to check out the delay change by
running ANIMALS, a program which does a lot of TEXT file I/O.

     The new diskette was booted (on our II+). When it began to load
Integer BASIC, the process bombed and reported an I/O error!

     My first reaction, of course, was: "The speed-up has messed up". A
check via Copy II+ showed the Integer BASIC file to have a bad sector.
Exactly how this could relate to a change in spin-up delay was unclear;
but, it did not matter-- the delay change was suspect.

     The diskette was re-INITed using standard-delay DOS. The files were
copied from the Master again using Copy II+ launched under normal DOS. The
new normal-DOS diskette was booted. It started to load Integer BASIC ...
and, it bombed, too!

     The problem was a marginally bad diskette.

     The whole INIT-with-speeded-DOS and copy process was repeated using
another diskette. It booted fine and loaded Integer BASIC without a hitch.
ANIMALS was started and several animals were added with no problem.
Similarly, Screenwriter ][ was moved to a speeded DOS diskette and booted.
Some TEXT files were created, saved, and loaded. Screenwriter' seems to
work fine, too.

     One interesting result of the first bunch of tests on this
modification is the difference in gains on the II+ and IIc+. Yes; the 4MHz
IIc+ should do things faster; but, why, if the IIc+ slows down for Disk][
operations, should the _difference_ be different? It looks like the IIc+
does not do a full slow-down. If this is so; the IIc+ may be using a
shorter, 'non-standard' spin-up delay all the time.   


     When one user publishes some DOS mod which he/she claims has some
benefit and another user publishes a claim that the mod causes problems,
the safest course is to avoid the mod. Testing the mod takes time and, no
matter what, _any_ change will imediately be suspect the moment a problem
crops up.

     On the other hand, one may miss out on some nice improvements. When
ProntoDOS was first released, I used it sparsely and kept 'real' DOS 3.3
diskette backups of programs moved to ProntoDOS for months. This turned
out to be a waste of time.

     In fact, ProntoDOS and variants like ESDOS][ are not 100% DOS 3.3
compatible. For even a minor tweak to Standard DOS, you can be sure that
there is some program somewhere which will bomb due to the change. Just
adding a "Free Sectors" display to CATALOG ruined compatibility with some
fancy HELLO program-launchers.

     You hardly ever get something for nothing.

     The mod unearthed and reported by Edhel does, so far, seem to be
safe. Yet, the speed gain is small and the mod may, eventually, prove out
as a bad idea.
    


      



Rubywand