
                          UHDD DOS Device Driver
          ===========================================================

1. Description
   -----------

   UHDD is a small disk-only caching driver.    It functions like UIDE and
   handles up to 22 BIOS disks of all sizes, including A: or B: diskettes,
   on up to 9 "Legacy" and Native-PCI SATA/IDE controllers.    When loaded
   after UHDD, the UDVD2 driver (see below) will call UHDD to cache CD/DVD
   files and directories.    With a 20-MB+ cache, UHDD uses Read-Ahead for
   its UltraDMA disks (10% faster speed than UIDE).   UHDD takes 720 bytes
   of upper/DOS memory and 2032 HMA bytes with a /H switch, or 2752 memory
   bytes without /H, for all cache sizes.   Its cache is in XMS memory and
   holds up to 4 Gigabytes of data.   UHDD's /B switch also offers a basic
   UltraDMA disk driver (no cache) using 128K of XMS as its buffer for I-O
   unsuited to UltraDMA.   The basic UHDD is for tests or other non-cached
   work and uses 576 bytes of upper/DOS memory and 752 bytes of HMA with a
   /H switch, or 1328 bytes of memory without /H.

   The small CC.COM "Clear Cache" program can help verify files written by
   UHDD.   Entering  CC  at a command prompt makes UHDD "flush" its cache.
   Disk data (NOT cache data) can then be compared to the original output.
   NOTE:  Some CompactFlash cards cause CC to execute very slowly.


2. NO Warranties
   -------------

   UHDD is offered at no cost, "as is", "use at your own risk", and with
   NO warranties, not even an implied warranty of FITNESS for any
   particular purpose nor of MERCHANTABILITY!


3. Switch Options
   --------------

   UHDD usually needs only a /H switch to load in free HMA and a /S switch
   to set its cache size.   A summary of all UHDD switches is as follows:

      /A     Sets ALTERNATE addressing for "Legacy" IDE controllers. The
                first legacy controller uses 01E8h/0168h addresses and a
                second (if present!) uses 01F0h/0170h addresses. /A is
                only for "odd" mainboards with REVERSED addressing for the
                two legacy IDE controllers!   Without /A, the first legacy
                controller uses 01F0h/0170H and a second uses 01E8h/0168h,
                as is normal for most PC mainboards. Rarely necessary.

      /B     Requests a 1328-byte "stand alone" driver (no caching). This
             may help in tests or diagnostics.   The /B driver can request
             128K of XMS as an UltraDMA I-O buffer, and it can load in the
             HMA.

      /E     Makes the driver "call the BIOS" for hard disk I-O requests.
                /E avoids setup trouble on some DOS emulators (VirtualBox,
                etc.) that do not emulate all PC hardware logic!   /E also
                allows using hard disks on 1994 or older PCs which have no
                PCI/EDD BIOS.   /E still caches disk data, unlike /N1 that
                removes ALL disk support!   If /B is given, /E is ignored.
                With /E, UHDD omits all UltraDMA disk logic, saving 448
                bytes.

                ***** NOTE *****

                Using /E on protected-mode systems (JEMM386 etc.) may LOSE
                much speed!   For full details, see the "Technical Notes"
                section below. If /E is necessary, the DOS system should
                be run in real-mode (UMBPCI, etc.) whenever possible.

      /H     Loads all but 720 bytes of the driver (576 with /B) into HMA
                space. /H must not be used with ROM-DOS, which has no
                "free HMA"! MS-DOS kernels have ERRORS in posting free HMA
                space which can give CRASHES!   Specifying /H is "At the
                user's risk!" and PCs should be tested before /H is used
                in any critical tasks. FreeDOS offers no "free HMA" before
                FDAUTO is run so using /H with FreeDOS requires the
                drivers to load from FDAUTO.BAT (not from FDCONFIG.SYS).

      /Q     Awaits "data request" before beginning UltraDMA I-O with old
                controllers. /Q is for "old" systems and may be used only
                if the driver loads O.K. but seems unable to transfer
                data. /Q must be OMITTED with SATA-to-IDE adapters from
                Sabrent and others, since they may not emulate "data
                request" from SATA disks! /Q does not affect CD/DVD
                drives. Rarely necessary.

      /R15   Reserves 15-MB or 63-MB of XMS, for old DOS "game" programs,
      /R63      which require XMS memory below 16- or 64-MB.   The drivers
                must be able to reserve this memory, reserve their own XMS
                memory beyond that, and then "free" the 15/63-MB XMS.   If
                not, the drivers display "XMS init error" and abort!   For
                further details, see the "Technical Notes" section below.

      /Snn   Specifies the desired cache size in megabytes of XMS memory.
                /S values may be 5, 10, 15, or any number from 20 to 4093
                (4 Gigabytes).   If /S is omitted/invalid, an 80-MB cache
                is set.   UHDD displays "XMS init error" and aborts, when
                not-enough XMS is free!   If so, request a smaller cache.

      /Z     Moves protected-mode XMS data in 6K blocks (not 64K blocks),
                and for XMGR/UIDE, 2K blocks.    With JEMM386, /Z is
                unneeded.   With other EMM/VCPI/DPMI drivers, a PC must be
                tested to find if /Z is needed.   BAD schemes, allowing
                too few interrupts during XMS moves, may still be in use!

   For all switches, a dash may replace the slash and lower case letters
   may be used if desired.


4. Setup and Configuration
   -----------------------

   XMGR, UIDE, UHDD, and UDVD2 all load thru the CONFIG.SYS file.    RDISK
   loads via either the CONFIG.SYS or the AUTOEXEC.BAT file.   Your CONFIG
   or AUTOEXEC should contain command lines similar to these examples:

      DEVICE=C:\DOSDVRS\XMGR.SYS /N128 /B

      DEVICEHIGH=C:\DRIVERS\RDISK.COM /S200

      DEVICEHIGH=C:\SYSTEM\UIDE.SYS /D:TOSHIBA1 /S500 /H

      DEVICEHIGH=C:\USERDVRS\UHDD.SYS /S250 /H

      DEVICEHIGH=C:\MYDVRS\UDVD2.SYS /D:BLURAY1 /H

   Note that "Int 13h" BIOS drivers must be loaded first, so UIDE/UHDD can
   intercept and cache their I-O requests.   Note also that if UDVD2 is to
   share UHDD's XMS buffer and/or call it for CD/DVD data caching, it must
   load after UHDD, so UDVD2 can locate UHDD in memory and "link" with it.
   See the CONFIG.SYS examples below.

   With V3.70+ UMBPCI and XMGR, a "boot" procedure is not needed!   UMBPCI
   loads first to enable upper-memory, then XMGR loads to offer it and XMS
   to DOS, then other drivers may load.    For V6.22/V7.10 MS-DOS, JEMM386
   can also be loaded, to offer extra upper-memory in the "video graphics"
   areas, or if other JEMM386 features are desired.

   NOTE:  FreeDOS and some other DOS variants will not "add up" the memory
   found by both UMBPCI and JEMM386, like MS-DOS does!   FreeDOS users who
   desire more upper-memory or other protected-mode items must omit UMBPCI
   and load HIMEMX/JEMM386 per their instructions, or load XMGR/JEMM386 as
   shown in the third example below.

   An example CONFIG.SYS file using V3.70+ UMBPCI and XMGR is as follows:

          ..
          ..
      DOS=HIGH,UMB
      DOSDATA=UMB                               ;When available
      DEVICE=C:\BIN\UMBPCI.SYS
      DEVICE=C:\BIN\XMGR.SYS /W
      DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF X=C800-EFFF NOEMS   ;Optional
          ..
          ..  Int 13h drivers cached by UIDE/UHDD load now.
          ..
      DEVICEHIGH=C:\BIN\UHDD.SYS /S250 /H       ;Or UIDE alone.  Load via
      DEVICEHIGH=C?\BIN\UDVD2.SYS /H            ;  FDAUTO with FreeDOS
      DEVICEHIGH=C:\BIN\RDISK.COM /S125         ;Optional
          ..
          ..  Etc.
          ..

   XMGR can be used "stand alone" on a small XMS-only system.   It must be
   the first DOS system driver to load, and it must load in LOW memory, as
   in the following example:

          ..
          ..
      DOS=HIGH
      SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
      DEVICE=C:\BIN\XMGR.SYS
          ..
          ..  Int 13h drivers cached by UIDE/UHDD load now.
          ..
      DEVICE=C:\BIN\UHDD.SYS /S80               ;Or UIDE alone.  Load via
      DEVICE=C:\BIN\UDVD2.SYS                   ;  FDAUTO with FreeDOS
      DEVICE=C:\BIN\RDISK.COM /S20              ;Optional
          ..
          ..  Etc.
          ..

   With JEMM386 and XMGR,  XMGR loads first in "boot" mode,  then JEMM386,
   then XMGR finally loads into upper-memory.   An example CONFIG.SYS file
   which uses the XMGR "boot" procedure is as follows:

          ..
          ..
      DOS=HIGH,UMB
      DOSDATA=UMB                               ;When available
      DEVICE=C:\BIN\XMGR.SYS /B                 ;Loads only XMGR's "boot"
      DEVICE=C:\DOS\JEMM386.EXE I=B000-B7FF ...
      DEVICEHIGH=C:\BIN\XMGR.SYS                ;Loads the runtime XMGR
          ..
          ..  Int 13h drivers cached by UIDE load now.
          ..
      DEVICEHIGH=C:\BIN\UHDD.SYS /S250 /H       ;Or UIDE alone.  Load via
      DEVICEHIGH=C?\BIN\UDVD2.SYS /H            ;  FDAUTO with FreeDOS
      DEVICEHIGH=C:\BIN\RDISK.COM /S500         ;Optional
          ..
          ..  Etc.
          ..

   After the above drivers are loaded, further CONFIG.SYS drivers (SETVER,
   ANSI.SYS, etc.) can then load in any desired order.

   FreeDOS users should load UIDE/UHDD/UDVD2 via FDAUTO.BAT (not FDCONFIG)
   using the DEVLOAD program, so the drivers can load in "free HMA" with a
   /H switch.   Example FDAUTO command lines are:

          ..
          ..
      DEVLOAD /H C:\BIN\UHDD.SYS /S20 /H        ;20-MB+ cache recommended
      DEVLOAD /H C:\BIN\UDVD2.SYS /H            ;Must load after UHDD
          ..
          ..  Etc.
          ..

   When a specific RDISK drive letter is required, RDISK can now be loaded
   by AUTOEXEC.BAT, and its /: switch can specify any "free" drive letter,
   e.g.  /:Q  assigns drive Q: for RDISK files.    Whenever RDISK is used,
   AUTOEXEC.BAT should also include commands to copy all RDISK programs or
   data up to the RAM-disk.   This is required each time DOS loads, as XMS
   memory is LOST when a system shuts down!    Such copies usually require
   little time.

   If RDISK and UIDE/UHDD are used, users must balance how much XMS memory
   the drivers use.   RDISK must take no more XMS than its files may need.
   UIDE/UHDD can take most remaining XMS for its caches.   Some XMS memory
   must be saved for other programs needing it!   As an example, on a 4-GB
   system, RDISK might use 500-MB, UIDE/UHDD might use 3-GB, and 500-MB is
   free for other programs.   These values can be adjusted, so RDISK holds
   programs and "fast" data files, while UIDE/UHDD cache "ordinary" files.
   Properly balanced use of XMS will give a VERY high-speed DOS system!

   Please be sure to set each hard disk's geometry correctly in your BIOS.
   Set it to "Auto", "LBA" or "LBA Assisted", but NOT to "None", "Normal",
   "CHS", "ECHS".   "User Cylinders/Heads/Sectors", "Revised ECHS" or "Bit
   Shift" should run but are NOT preferred.   If a BIOS has a setting like
   "UltraDMA" or "UDMA Capable" for a disk, enable it.

   "Laptop" power-saving items like a "drive spin-down timeout" should run
   O.K. but must be TESTED before use!   All these drivers allow 7 seconds
   for a disk or CD/DVD drive to spin-up, after being idle.   More DRASTIC
   power-saving items like a "drive SHUTDOWN timeout" (may require "extra"
   logic to restart the drive!) should be DISABLED, or driver I-O requests
   may time out!

   Also, be sure to use an 80-pin IDE cable with any UltraDMA drive set to
   "mode 3" ATA-44 (44 MB/sec) or higher.   When cabling a single drive to
   an IDE channel, note that you MUST use both "ends" of the cable, NOT an
   "end" and the middle connector!   This prevents ERRORS, since an unused
   cable-end can pick up "noise", like a RADIO antenna!

   Be sure to enable all CD/DVD drive(s) through the BIOS set-up routines!
   A drive that is "disabled" may cause the BIOS to clear all its UltraDMA
   flags and force the drive into "PIO mode" zero, which is terribly SLOW!


5. Revision History
   ------------------------

   31-Mar-19   UHDD now uses Read-Ahead for its UltraDMA disks with 20-MB+
                 caches (10% more speed than UIDE).   The caching UHDD now
                 uses 2752 bytes (720 upper/DOS memory + 2032 HMA); the /B
                 non-cached UHDD is unchanged.   README file updated.

   16-Mar-19   README file updated.    UHDD.ASM changed to note UDVD2 must
                  load AFTER the UHDD driver (not before!) to cache CD/DVD
                  data.   No code changes, UHDD still dated 15-Feb-2019.

   15-Feb-19   UHDD updated as follows:

        2576 bytes (720 upper/DOS memory, 1856 HMA) for the caching driver
        and still 1328 bytes (576 + 752) for the /B non-cached driver.

        10-MB and all 20-MB+ cache sizes added, for old systems with small
        memory.   Default is still 80-MB if UHDD's /S switch is omitted or
        invalid.

        The 5-MB cache has 16K cache blocks, the 10- and 15-MB caches have
        32K blocks, and the 20-MB+ caches use 64K blocks for faster speed.

        Maximum cache size is still 4 Gigabytes (really 4093-MB; 3-MB held
        for UHDD's cache tables [max. 1-MB] and mainboard control regs.).

        The 5-Mar-2015 UDVD2 can still call this UHDD to cache CD/DVD data
        files; no UDVD2 changes needed.

        If LBACache is wanted, the non-cached UHDD /B can still load first
        to provide disk UltraDMA.

        The "80386 errata" commands used by Ninho on his 386/SX are added.

        SSDs and CompactFlash cards with an ATAPI flag are run as UltraDMA
        disks, not as slower "Call the BIOS" drives like in UIDE.

        Disks over 128-GB now use only LBA48 commands, to stop disk ERRORS
        at exactly 128-GB when an LBA28 command "crosses OVER" that limit.
        All disks less than 128-GB still use LBA28 commands.

        NOTE:  UIDE has not been so updated but can still be used on older
               systems.   For newer systems, UHDD + UDVD2 are preferred.

    5-Mar-15   UHDD now handles 9 controllers, 22 BIOS disks or
                 diskettes, 4 CD/DVD drives.    UHDD binary-search buffer
                 is again 512 bytes. UHDD "CD/DVD" cache deleted. Other
                 drivers unchanged (re-dated only).

   24-Nov-14   UHDD "User" caches deleted, due to non-use.

   14-Nov-14   UHDD now "overlaps" UltraDMA disk input AND output with as
                 many caching tasks as possible, for much improved speed!

   19-Oct-14   UHDD "overlaps" cache work during UltraDMA disk output and
                 disk sector "gaps" at I-O end, for more speed!   UHDD /M
                 switch deleted, 256-byte search buffer is now permanent.

   27-Sep-14   New UHDD /M switch sets a 512-byte binary search buffer.

   26-Jan-14   UHDD offers "Common" & "CD/DVD" caches.

   12-Jan-14   "Stand alone" UHDD re-added, for use as needed.

   12-Dec-13   UHDD deleted (low use).

   21-Nov-13   UHDD old style "stand alone" driver re-added.

    9-Sep-13   Possible but unlikely UHDD exit errors corrected.

    2-Sep-13   UHDD /N1 size reduced.

   30-Apr-13   UHDD can now run without XMS (lower speed) for tests and
                 FreeDOS "scripts".

   15-Oct-12   UHDD again detects A: and B: diskettes from BIOS data, NOT
                 from "Int 13h" calls that FAIL with an LS-120 drive!

    2-Aug-12   UHDD "disk only" caching driver added.


6. Error Reporting
   ---------------

   UHDD works as a "BIOS driver" and returns whichever codes are set
   for diskettes and hard-disks handled by the BIOS. For SATA and IDE
   hard-disks, UHDD can post the following error codes:

       Code 0Fh - DMA error.           CCh - Disk is FAULTED.
            20h - Controller busy.     E0h - Hard I-O error.
            AAh - Disk not ready.      FFh - XMS memory error.

   Many DOS programs display only "Disk Error" messages with NO code, thus
   disk errors may require running a diagnostic to get better information!


7. Technical Notes
   ---------------

   Protected-mode users must pretest "I=nnnn-nnnn" or "X=nnnn-nnnn" values
   for JEMM386, as its "I=TEST" or "X=TEST" options may fail on newer PCs.
   Protected-mode is unrecommended with old DOS games needing reserved XMS
   as JEMM386 takes some XMS memory first.   Newer "cheap BIOS" mainboards
   now OMIT logic used only for DOS and need a disk UltraDMA driver loaded
   before JEMM386 sets its protected-mode!    With such boards, CONFIG.SYS
   example C above will require Int 13h drivers cached via UHDD, then UHDD
   itself, to load only in LOW memory, after XMGR's "boot" provides XMS to
   the system.    JEMM386 can then load and set its protected-mode safely.
   2015 or older mainboards with a "regular" BIOS usually do not need this
   and can use example C as-is.   Use of JEMMEX or other "EMM" drivers but
   JEMM386 should now be avoided.   Other "EMM" drivers got abandoned long
   ago, some with leftover ERRORS!   JEMMEX cannot be used on "cheap BIOS"
   boards with these drivers and has caused crashes on newer PCs, probably
   due to an old XMS detection scheme.   If not updated, JEMMEX should now
   be viewed as "obsolete"!

   The drivers' /R15 or /R63 switch is for a real-mode system using UMBPCI
   and XMGR, to play old DOS games.   Game players prefer real-mode, as it
   gives higher speed.   If UIDE or UDVD2 are used alone, they can use the
   /R15 or /R63 switches with no problem.   If UDVD2 is loaded after UHDD,
   only UHDD can "reserve" XMS memory, and UDVD2 must not use a /R switch.
   Note that NO other programs or drivers that require XMS memory can load
   before the "game", so the reserved XMS cannot be re-allocated to anyone
   else!   Also note that if the "game" cannot be loaded and then "frozen"
   (not started immediately!), loading other programs and drivers AFTER it
   will be impossible!   Both of these issues make using JEMM386/EMM386 or
   other "EMM" drivers difficult, so an old "game" program which must have
   XMS memory below 16- or 64-MB will usually need to be run in real-mode.

   UHDD handles only "Legacy" or "Native PCI" IDE controllers.   RAID-only
   chipsets, "port multiplier" chips, and ADMA chipsets are not supported.
   UHDD requires "Legacy", "Compatibility", or "Native IDE" mode with AHCI
   controllers.   For mainboards with no such controller settings, Sabrent
   or similar SATA-to-IDE cards will let UHDD or UDVD2 run SATA disks/CDs/
   DVDs from a parallel-port IDE controller (80-pin cable), at DMA speeds.
   "Add on" PCI-bus adapter cards, that can be detected via normal PCI-bus
   logic, may also be used for disks/CDs/DVDs.

   XMGR loads in UMBPCI upper memory that is not "provided" to the system.
   With UMBPCI, a "MEM" list may begin with a block having a 00A7h offset,
   or greater with 80 or 128 XMS "Handles".    The upper memory skipped by
   this offset contains XMGR.

   The UMBPCI upper memory manager uses system "Shadow RAM" that cannot do
   DMA.    A newer BIOS may use UltraDMA to load programs in upper memory.
   If this is "Shadow RAM", a HANG can occur!    These two rules apply, if
   using UMBPCI with XMGR and UHDD:

     A) V3.70+ UMBPCI must load before XMGR, so XMGR finds UMBPCI and sets
        its "I-O Catcher", to handle diskette "Shadow RAM" DMA forever and
        to handle disk "Shadow RAM" UltraDMA until UHDD is loaded.   Older
        UMBPCI drivers, or other UMBPCI load schemes, are not recommended!

     B) When CHS I-O is done (MS-DOS V6.22 or older), every disk must have
        valid CHS parameters set in the BIOS.    If not, the "I-O Catcher"
        and UHDD let the BIOS handle CHS I-O.   When BIOS UltraDMA is left
        enabled, a "Shadow RAM" HANG can occur!

   Old BIOS programs may not configure a mainboard controller when no user
   drives are on it!   The drivers then display "BAD controller" and go on
   looking for others to use.   If this message is given, users must check
   that all SATA/IDE drives are set "active" with the BIOS setup routines.
   If so, "BAD controller" means a chip is not using "Bus Master" and "I-O
   Space" modes, and a BIOS update is needed!
