DOS ain't dead

Need User Comment Re: Possible UIDE /P Changes! (Announce)

posted by Jack , Fresno, California USA, 05.05.2010, 21:34

I am seeking DOS users' comments about a possible change to UIDE.

I am still NOT happy with UIDE's speed on protected-mode systems.
Its current /P option helps reduce XMS use by setting its binary-
search table in upper or DOS memory and gains back 10% or more of
the speed lost to protected-mode XMS calls. But, the current /P
option is "complex" and is still inadequate -- There is a visible
speed loss when UIDE must run in protected-mode v.s. its speed in
real-mode, e.g. using UIDE and JEMMEX/JEMM386 is slower than when
using UIDE with UMBPCI.

The only way to minimize XMS calls is to put ALL of UIDE's tables
BACK in upper or DOS memory. This will give UIDE the same speed
as LBAcache in any cache size, since UIDE will again use XMS only
for cached disk/CD/DVD data or "misaligned" UltraDMA I-O (it sets
a 128K XMS buffer for this). This is equal to the original 2006
QCACHE, a "memory only" caching driver that had more speed.

If UIDE /P is "arranged" in memory with its 944 bytes of variable
data first, binary-search table 2nd, LRU indexes third, and cache
data table (8 bytes per cache block) last, that data table can be
given its own 80x86 "segment". This lets UIDE handle 8176 cache
blocks and set up to 511-MB caches with any DOS system -- NO more
V7.10 MS-DOS "restrictions" (UIDE's binary-search tables will NOT
be in the HMA!), when /P is specified.

A 511-MB cache will require a total of 105KB of upper/DOS memory,
a LOT as I do realize! Smaller caches will not use as much, 53K
memory for a 255-MB cache, etc. Note that most DOS systems with
"linear" upper-memory, i.e. no "embedded" addresses or "ROM BIOS"
logic, have over 132KB between the video-BIOS at C7FFFh and their
"system BIOS" at F0000h. Few DOS systems need ALL that area for
drivers, so the extra goes to waste, especially as JEMMEX/JEMM386
normally maps the B000h-B7FFFh monochrome video area (few use it)
for drivers, as well. For a system WITH "embedded" upper-memory
logic, UIDE will allow loading in "low" 640K DOS memory as before
so users needing large /P caches can decide to sacrifice some DOS
memory for speed, where necessary.

NOTE that for real-mode (UMBPCI) users, or users "not so worried"
by a minor UIDE speed loss in protected-mode, UIDE shall continue
to permit up to 4-GB caches using XMS memory, when /P is omitted.
I shall NOT be changing the "standard" 4-GB UIDE at all!

I believe such a "scheme" for UIDE /P is "The BEST of all Worlds"
as it permits FULL-speed caches up to 511-MB with all DOS systems
that need protected-mode. The only cost is the driver size, but
I believe most DOS systems would support a "memory only" cache up
to 255-MB (53K driver), and many would also support a cache up to
511-MB (105K driver).

What do all of YOU think?? Please post your comments here, so I
can be positive this is the best-possible UIDE /P upgrade, before
beginning my driver changes.

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

Complete thread:

• Need User Comment Re: Possible UIDE /P Changes! - Jack, 05.05.2010, 21:34 (Announce)
  • Need User Comment Re: Possible UIDE /P Changes! - Arjay, 05.05.2010, 23:12
    • My Thanks, Arjay! - Jack, 06.05.2010, 01:00
      • My Thanks, Arjay! - Arjay, 06.05.2010, 01:50
  • Need User Comment Re: Possible UIDE /P Changes! - Zyzzle, 05.05.2010, 23:17
    • My Thanks, Zyzzle! - Jack, 06.05.2010, 01:09
  • With Regret, Shall Not Update UIDE /P! - Jack, 07.05.2010, 04:55
    • With Regret, Shall Not Update UIDE /P! - Arjay, 07.05.2010, 21:38
      • Separate UIDE-M Driver Might Be Better! - Jack, 07.05.2010, 22:02
        • Separate UIDE-M Driver Might Be Better! - Arjay, 07.05.2010, 22:31
        • See also private message - Arjay, 07.05.2010, 23:07