"Maybeway36" and Geraldo --
I am the writer of UIDE. To answer your "confusion" about
the UIDE driver, the following may be of help --
UIDE is meant to be a "Universal IDE" driver for hard-disk
and CD/DVD drives. It enables UltraDMA logic for SATA or
IDE disks and CDs/DVDs, which some older BIOS programs may
not do.
When UIDE loads, it asks the PCI BIOS if any "Legacy Mode"
(address 3F0h, 370h, 3E8h, and 368h) and "Native PCI Mode"
(addresses set thru the PCI BIOS) SATA and IDE controllers
are present. If so, UIDE then issues "EDD BIOS" calls to
"match" the posted I-0 addresses for each hard-disk to the
controller addresses. Disks which match are run directly
by UIDE with normal UltraDMA I-O logic -- UltraDMA is part
of the design for both SATA and IDE controllers.
CD/DVD drives were not part of the original IBM BIOS spec,
so they cannot be detected by PCI/"EDD" BIOS calls. UIDE
thus does its own examination of every SATA/IDE controller
detected above, and it then runs the first 8 CD/DVD drives
found. Unlike hard-disks, which MUST be on a SATA or IDE
controller for UIDE to run them, UIDE will handle a CD/DVD
drive on non-PCI "legacy" controllers, needed by some very
old PC systems. CD/DVD drives are enabled to do UltraDMA
I-O by UIDE. If a (very old) CD drive cannot do UltraDMA
it is run by UIDE in "PIO mode", slow but it does the job!
After it detects and enables SATA/IDE hard-disks or CD/DVD
drives, UIDE caches data for them and for A:/B: diskettes!
Both directories and data files are cached, which offers a
HUGE speed improvement to all DOS systems, especially when
using diskette or CD/DVD files. Hard-disks declared to a
BIOS but which did not "match" a SATA/IDE controller (e.g.
SCSI, USB, etc.) are still cached by UIDE which "calls the
BIOS" to handle I-O for the different type of disk. Upon
return from the BIOS, UIDE caches the "odd" disk's data as
well. CD/DVD drives not detected by UIDE are not cached,
as the BIOS offers UIDE no info about "odd" CD/DVD drives.
XMS memory is used as the cache, and UIDE now allows up to
4-GB of memory for caching. More reasonably, users would
likely give UIDE up to 3-GB, keeping 500-MB for a RAM-disk
(as in my RDISK driver) and the last 500-MB for user tasks
that also need some XMS memory.
UIDE does BOTH read- and write-caching. UIDE uses "Write
Through" caching, which writes new output data immediately
to disk, unlike "Write Back" caching that delays writes to
see if the data may get updated again. "Write Backs" are
more efficient for compilers or databases but are HORRIBLY
complex! I want UIDE to work with all DOS versions, so I
will NOT include all the needed "special hooks" to allow a
"Write Back" cache. UIDE with "Write Through" caching is
fast-enough anyway for most tasks! [Writing diskettes is
slow, due to updating directories on track 0. But, when
reading diskettes, directory caching DOES improve speed!].
At present, UIDE does not directly handle SCSI or USB hard
disks, although if they are "declared" as BIOS units, UIDE
"calls the BIOS" for their I-O and then caches their data,
afterward. Sadly, most USB hard-disks are NOT "declared"
as BIOS units, so UIDE may not be able to run them at all.
And at present UIDE handles only SATA or IDE CD/DVD drives
as it does not detect controllers other than SATA and IDE.
Finally, UIDE does not-yet have logic to handle new "AHCI"
controllers. This should not be a problem, as most AHCIs
can be configured via the BIOS to "legacy" or "compatible"
mode (meaning IDE!), in which case UIDE will run them O.K.
Note that UIDE still DOES allow "external" drivers to call
it for caching, in ways similar to its own "call the BIOS"
logic. Nobody has ever used this, though if anybody DOES
want to "interface" a SCSI/USB/etc. driver to UIDE's cache
I would be happy to "work with them" to achieve this.
On running UIDE with LBACache/CDRCache, this should NOT be
necessary. UIDE provides much-larger and usually faster
caches. In cases when "protected mode" (JEMM386) is used
and absolute-maximum speed with smaller caches is desired,
LBAcache may be of benefit ("protected mode" does slow XMS
usage by UIDE a little). "Real mode" (UMBPCI) users will
not have any speed problems due to XMS memory. Also, for
systems with SCSI or other-type CD/DVD drives that are not
detected by UIDE, then CDRcache may be of benefit. But,
for most users who have only SATA/IDE hard-disks or CD/DVD
drives, UIDE should be used without LBACache or CDRcache.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
