DOS ain't dead

Johnson Lam has posted a new DRIVERS.ZIP file, dated 19-May-2010,
and containing a slightly faster UIDE driver, on his website at:

<http://johnson.tmfc.net/dos/driver.html>

The XMGR, RDISK, and UIDEJR drivers are unchanged and have merely
been re-dated 19-May-2010 to "match" the new UIDE driver.

In UIDE, doing both a "get" and "put" while updating cache least-
recently-used (LRU) indexes was not needed! Only one 2-byte LRU
index changes in such updates, and the driver need not handle the
full 12-byte entry. UIDE now computes where an LRU index is, in
XMS memory, then issues only a 2-byte "put" (at label "LRUPut" in
UIDE.ASM). This AVOIDS also doing two "gets" from XMS memory of
the two LRU indexes in every cache block, making UIDE run faster.
My apologies to all -- I should have realized this idea long ago!

Also, for a "hair" more speed in protected-mode, the /K switch is
again available in UIDE. /K causes a direct "call" to the logic
in JEMM386 that does an XMS move, which is slightly faster than a
regular "Int 15h" that needs full protected-mode "trap handling".
However, as noted in the driver README file, /K is NOT for use on
Win95/98/3.11 systems and will demand TESTING if other protected-
mode or VCPI/DPMI handlers besides JEMM386 or EMM386 are present!

I did complete a "memory only" version of UIDE, but it needed TOO
MUCH memory, up to 119K for a 511-MB cache! Thus, I decided to
keep the current UIDE, but include the above minor speed changes.
Not a large speed increase, but such small changes do add-up over
time! I will continue trying to find faster UIDE "schemes".

---
(Account disabled on user's request.)

Some comments in the form of a "White Paper" on the use
of the UIDE driver --

UIDE /P is limited to 1900-MB if loading in main memory
or from 170 to about 500-MB if loading in the HMA. As
its cache blocks are limited by memory, it shall always
use 64K-byte blocks, which hold more total data and run
faster but are only about 70% "efficient". 64K blocks
lose up to 30% of XMS cache space, as the last block of
a cached file usually does not get "filled up" and will
WASTE on-average 32K bytes.

When not using /P, UIDE now defaults to having 16K-byte
blocks for caches up to 1-GB, 32K blocks for up to 2-GB
and 64K blocks for over 2-GB. This improves capacity,
as 32K blocks lose only about 20%, and 16K blocks about
10%, of cache capacity -- the cache blocks are "filled"
more completely by data, and wasted space is minimized.

But, the smaller blocks DO require a bit more I-O time.
Any I-O driver is more efficient if it can write LARGER
blocks at a time, instead of LOSING time to "rotational
latencies" in-between smaller blocks.

I have retested UIDE without /P but with its /F switch,
which sets "fast" 64K blocks for every cache size. If
/F is used with the "XMS memory" UIDE (i.e. no /P) most
of the lost speed is restored. Not all of it, and /P
still does "win the race", but only by a "hair", not by
a more visible margin.

So my "latest advice" about using UIDE is as follows --

On all systems, either real- or protected-mode, UIDE /P
is still fastest but is limited in total cache capacity
especially if loading in the HMA. If a small-size HMA
cache tests O.K. and "does the job", use UIDE /P either
with /H for minimum upper-memory or /HL for more cache.

With V7.10 MS-DOS or other systems which are limited in
HMA space, if a slightly larger cache is necessary, use
UIDE /P but load it in upper-memory, i.e. no /H nor /HL
switch. With UIDE /P, a 250-MB cache in memory takes
only 12K and 500-MB takes 20K, "not too bad"! However
do NOTE that most systems excepting ROM-DOS (no HMA) or
V7.10 MS-DOS can set a 425-MB+ HMA cache with /HL, even
FreeDOS when it loads UIDE from AUTOEXEC.BAT using Eric
Auer's DEVLOAD program.

For a 500-MB+ cache, UIDE without /P is normally needed
[excepting "lucky" systems like V6.22 MS-DOS, which has
21K+ free HMA!]. One must then decide between maximum
cache efficiency, i.e. letting UIDE have 16K/32K blocks
for caches up to 2-GB, or slightly better speed with /F
and 64K blocks (not as efficient) for every cache size.
The speed loss without /F is tiny, likely less than 5%,
and so /F is usually only for medium-cache systems that
need absolute-maximum speed. Otherwise, just omit /F
and "Be Happy!", since UIDE without /P loads all cache-
tables in XMS and thus handles up to 4-Gigabyte caches!

---
(Account disabled on user's request.)