DOS ain't dead

> It must be an ICH7 chipset limitation.

BIOS ???

> UIDE loaded but did not improve performance.

What a surprise, considering that UIDE supports only IDE / ATA / SATA (non-AHCI) internal disks



> I read on this forum some time ago about USB 2.0 driver support in DOS
> but now I can't find the thread.

NOPE

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

From my 2010-03-03 post on FD-User:

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

UIDE was originally a hard-disk IDE driver, from a time when
BIOS handling for such disks was non-existent or poor. But
IDE and UltraDMA "standards" did exist, so a "common" driver
for such disks, CD/DVD drives, and SATA (an IDE enhancement)
was possible. Adding caching into the original UDMA/XCDROM
driver logic has ultimately resulted in the current UIDE.

Regrettably, USB has at least two "standards", which COMPETE
with each other, and a "common" USB disk/CD/DVD driver would
demand adding too much logic in UIDE, if this is possible at
all! As I do not want UIDE to become "bloated" by a lot of
incompatible and competing "standards", I am in fact AGAINST
adding USB logic in the UIDE driver!

There are at least 2 solutions. First would be for writers
of BIOS logic to handle USB disk drives as actual BIOS units
just like hard-disks. UIDE would then "detect" one or more
non-PCI disks (i.e., the USB disks) and would cache them via
its "call the BIOS" logic. Not a "help" for CD/DVD drives,
which were never part of BIOS I-O and are always handled via
SHCDX33E/MSCDEX and the CD/DVD drivers, which includes UIDE.
But, BIOS support for USB hard-disks and maybe for a "memory
stick" is better-than-nothing, as UIDE would need NO changes
to cache their data automatically. [Periodically, I do try
loading UIDEJR /N2 (no CDs/DVDs) and then UIDE /N1 (no hard-
disk I-O) which makes UIDE use its "call the BIOS" logic for
disks. Disk I-O will get "intercepted" and done by UIDEJR.
Thus I am confident UIDE's "call the BIOS" logic does work!]

Second, existing USB drivers could be changed to detect that
UIDE is present, then they can invoke UIDE's "external call"
logic to achieve caching. I have never documented this, as
I am unaware of anyone ever trying to call UIDE for caching.
But, that logic is still present in UIDE, and if anyone ever
does want to call UIDE for caching, I would be happy to work
with them to achieve this. Such a scheme COULD support USB
CD/DVD drive caching, which should offer the same HUGE speed
increase as UIDE gives for SATA/IDE CDs and DVDs. When any
USB diskettes and other-type drives are present, they can be
cached by UIDE as well.

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