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

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

In article <19970207001900.TAA27430@ladder01.news.aol.com> rubywand@aol.com
writes:
>[...]
>     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.

Both of these statements are true.

But the reasoning behind the second one is slightly misleading.  ProntoDOS
and the motor-on delay patch differ in one fundemental respect--ProntoDOS
works by bypassing a software delay, which has nothing whatsoever to do
with hardware, but the motor-on patch directly affects how RWTS interacts
with the hardware...it forces the disk drive to operate outside of its
published specs.

Of course, "How far outside of the published specs can I go?" is a
legitimate, if somewhat undercautious, question.  I suspect the answer
depends heavily on your disk drive.  The "published specs" I'm referring to
are for the original Disk II mechanism...newer Apple drives, and
Apple-compatible third-party drives, may very well have shorter startup
times.  On some drives you may be able to get away with reducing the
motor-on delay by a considerable amount.

But if you intend for your disks to be bootable on any drive other than
your own, I recommend leaving the motor-on delay alone.  Any DOS intended
for mass consumption should be prepared for the lowest common denominator,
which means the old Disk II with its 1-second delay (there are still lots
of Disk II's out there...I have two of them plugged into my IIGS).

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

Indeed.  I have first-hand experience with this.  A few years ago I wrote
my own DOS speed-up patch (it works like ProntoDOS, bypassing the file
manager bottleneck), which I still use frequently.  It's been quite
reliable so far, but I have had one problem--it's not compatible with the
language-card version of GPLE.  It seems GPLE wants to put its language-
card-switching code in the same free space that I took over for my speed
patch.  Fortunately I discovered the incompatibility before it had a chance
to corrupt any files.

            - Neil Parker
-- 
Neil Parker                       | Unsolicited commercial e-mail to my
nparker@cie-2.uoregon.edu         | address is not welcome, and will be
nparker@cie.uoregon.edu           | discarded unread.
http://cie-2.uoregon.edu/~nparker |