DOS ain't dead

> I would like to ask what exactly the /E option does ...

Congratulations! You win "The PRIZE!" for being certainly the FIRST person
in almost 4 years to inquire about UIDE's caching for "External Drivers"!

The /E switch causes UIDE to retain its entry-point logic for caching calls
from "external" drivers, such as Bret Johnson's USB drivers. If /E is not
given, UIDE zeros its entry-point offset at address 00016h, which indicates
to other drivers they must NOT call UIDE for caching. This saves 48 bytes
that nobody, so far, has ever used. If UIDE is run "stand alone" with its
/B switch (i.e., as only a disk/CD driver without caching), the entry-point
logic is also discarded.

If you want to modify Bret Johnson's USB drivers, or other drivers as well,
to call UIDE for caching, you must include /E and then do the following --

A device-driver which desires caching must be loaded AFTER the UIDE driver,
so it can "find" UIDE in memory. The device-driver should scan all memory
from a segment address of about 00100h thru 0EFFFh. Each increment of the
segment register points to the next 16-byte memory "page". The scan looks
for the assigned 8-byte name of the UIDE driver, which is at offset 10 from
the segment register. Assuming a "working" segment value is loaded in the
ES-reg. and UIDE was loaded with /D:MYUIDE$ an example would be --

cmp dword ptr es:[10],"IUYM" ;Are 1st 4 name bytes "MYUI"?
jne short NextPage ;No, increment segment and try again.
cmp dword ptr es:[14]," $ED" ;Are 2nd 4 name bytes "DE$ "?
jne short NextPage ;No, increment segment and try again.

FoundUIDE: ;At this point, UIDE has been found!

NextPage: ;At this point, bump ES: and try again.

With today's fast CPU chips, such a memory scan takes microseconds. After
the device-driver has found UIDE, it should save its segment-register value
for caching calls. Then, the value at Segment:00016h should be tested for
zero. If so, UIDE is NOT able to handle external-driver caching, as noted
above, and the device-driver can continue with other setup tasks.

A non-zero value at address 0016h of UIDE is an offset to the routine named
"ExEntr" (external entry), and 32 bytes beyond that is the routine "ExRSet"
(external cache-reset). To request that UIDE cache some data, the device-
driver should set up the registers as noted for UIDE's "ExEntr" subroutine,
then call that subroutine with a command similar to:

CachePtr dd 0 ;Holds saved UIDE segment and 016h offset.
ResetPtr dd 0 ;Holds saved segment and (016h offset) + 32.

call CachePtr ;Call UIDE for caching.
jc IOError ;If carry comes back set, I-O has FAILED!

Note that such a call MUST include a pointer to the device-driver's handler
for I-O, in case UIDE must read or write some or all of the indicated data.
If the data is already cached, the only possible error is an XMS error from
UIDE. If not, UIDE shall "call back" the device-driver's handler, and any
error must be reported back to UIDE via the CPU "carry" flag, with an error
code in the AH-reg. similar to what BIOS logic does. If carry is not set,
the caching call, including I-O if needed, was successful.

If a "fatal" error occurs, or if the device uses removable media (diskettes
etc.) and the media changes, the device-driver should request that the UIDE
cache be "flushed". UIDE does not have logic to "selectively" flush data
for individual drives, since such events do not occur often, and since this
would take a LOT more complex programming! The "flush" is requested by:

call ResetPtr ;Call UIDE via above pointer, to flush its cache.

UIDE will post an internal "flush" flag, and all cache data will be flushed
upon the next caching request by any units or devices using UIDE, including
any of its OWN disks/diskettes/CDs.

So you see, one needs only a small amount of device-driver "setup logic" to
find UIDE in memory and get its segment and entry-routine offsets, then one
simply does "cache data" and "flush cache" requests as required. In past,
I have done tests in which UIDE is loaded with its /N1 or /N2 switches i.e.
do NOT "handle" disks or CDs, then I have used a special "debug" version of
UIDEJR that does all of the above. Worked great and was a LOT faster, due
to the cache! [Sadly, I did not save that "debug" driver as nobody seemed
interested in UIDE "external drive" caching!].

If you need more help, let me know by private E-Mail, and I will reply.

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