
                 XMGR, RDISK, XHDD and XDVD2 -- DOS Drivers
               ==============================================


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

   XMGR, RDISK, XHDD, and XDVD2 are Closed-Source DOS drivers for PCs with
   an 80386+ CPU (XHDD requires an 80486+ CPU) and using MS-DOS V5.0+ or a
   fully compatible variant.

   XMGR is an "XMS manager" for up to 4-GB of XMS memory, with support for
   V3.70+ UMBPCI by Uwe Sieber.   XMGR can load directly to UMBPCI "Shadow
   RAM" upper memory, and it can "boot" into regular upper memory if using
   protected-mode.   See the example CONFIG.SYS files in Section 5 below.

   RDISK is a RAM-disk driver.   It creates a "fast" disk using up to 2-GB
   of XMS memory.   Files can be uploaded via AUTOEXEC to the RAM-disk and
   accessed at memory speeds.    RDISK is a simple RAM-disk driver with no
   resizing or other options.

   XHDD is a disk caching driver.   It traps BIOS "Int 13h" I-O and caches
   data for up to 15 BIOS disks of any type or size using up to 6 "Legacy"
   or Native-PCI UltraDMA controllers.   It calls the BIOS to run A: or B:
   diskettes or other non-UltraDMA drives, and it can cache data for other
   Int 13h drivers loaded first.   The XDVD2 driver can load after XHDD to
   cache CD/DVD data files.   XHDD overlaps UltraDMA with caching and uses
   Read-Ahead for UltraDMA disks.   Its cache uses XMS memory and can hold
   4 Gigabytes of data.   XHDD's /B switch also sets a "basic" disk driver
   (no cache) using 128K of XMS to buffer I-O unsuited to UltraDMA.    The
   basic XHDD is for tests or other noncached work.

   XDVD2 is a CD/DVD driver for up to 4 SATA, IDE, or old PIO-mode drives.
   It reads CD/DVD data files, plays audio CDs, and can read "raw" (track-
   writer) data.   XDVD2 can work alone; or when XHDD is used, XDVD2 calls
   it to cache CD/DVD data.    XDVD2 buffers input unsuited to UltraDMA in
   128K of XMS.   It "shares" XHDD's buffer, sets its own buffer when XHDD
   is absent, or it does PIO-mode input if XMS is unavailable.

   The small RDISKON.COM program will re-enable an RDISK drive if a format
   command is issued to it by mistake!   Entering  RDISKON L  at a command
   prompt, where L is the drive letter (A to Z), re-enables the drive.

   The small CC.COM "Clear Cache" program can help verify files written by
   XHDD.    Entering   CC  at a DOS prompt causes XHDD to flush its cache.
   Disk data (NOT cache data) can then be compared to the original output.


2. NO Warranty
   -----------

   XMGR, RDISK, XHDD and XDVD2 are offered at no cost, as-is, "Use at your
   own risk" and with NO warranty, not even an implied warranty of FITNESS
   for any particular purpose, nor an implied warranty of MERCHANTABILITY!


3. Summary of Major Revisions
   --------------------------

    1-Jul-22   XMGR /R switch accepts ".5" for an extra 0.5-MB of reserved
                  XMS.    24-bit "Sound Blaster" cards etc. can use /R15.5
                  and work in protected-mode (the last 0.5-MB of the 16-MB
                  area is for JEMM386).    PLEASE READ the updated XMGR /R
                  comments and Sections 5 and 6 of this README, re: use of
                  reserved XMS!    Other drivers unchanged, re-dated only.

   15-May-22   README file updated only, to better explain using protected
                  mode and "cheap BIOS" mainboards.    PLEASE READ Section
                  6 below!   All drivers remain dated 23-Jan-22.

   24-Apr-22   README file updated only, re: BIG changes needed for V5.80+
                 JEMM drivers.   See the protected-mode notes in Section 6
                 and the upgraded CONFIG.SYS examples in Section 5 below.

   23-Jan-22   /R deleted from XHDD/XDVD2/RDISK and added into XMGR.   New
                 /F switch added into XHDD/XDVD2/RDISK, to "free" reserved
                 XMS when all drivers are loaded.   These changes HOLD all
                 reserved XMS memory until a DOS "game" can begin!

   30-Nov-21   REAME file update; Section 5 describes how to use both XHDD
                 and RDISK for best speed.

   21-Nov-21   XHDD now handles up to 15 BIOS disks using up to 6 UltraDMA
                 controllers, to support larger workstations.

    6-Jun-21   XHDD now handles up to 10 BIOS disks using up to 4 UltraDMA
                 controllers.

   18-Apr-21   XHDD re-adds /P resident search-table logic, for more cache
                 speed with SSD/NVmE "disks".

   14-Mar-21   XHDD re-adds extra XMS logic and better "VDS" code for more
                 cache speed with SSD/NVmE "disks".

   16-Feb-21   XHDD now handles 8 BIOS disks using 3 UltraDMA controllers.
                 It offers ALL cache sizes from 5-MB to 4-GB and does Read
                 Ahead and DMA/Caching Overlap (with /O) with any cache to
                 help small-memory PCs!

   27-Dec-20   XHDD now supports 5 UltraDMA controllers (was 6).

   16-Nov-20   XHDD back to handling up to 12 BIOS disks on 6 controllers.

    7-Jul-20   XHDD corrected to handle 4-bit controller numbers properly.

   23-Jun-20   XHDD now handles up to 20 BIOS disks on 9 controllers.

   26-May-20   XMGR and XHDD now do XMS moves in 8K blocks with 486+ CPUs,
                 4K blocks on slow 386 CPUs.

   10-Mar-19   XHDD uses Read-Ahead for a 10-MB+ cache and sets all 10-MB+
                 cache sizes.

    2-Feb-19   XHDD handles 128-GB+ disks using only LBA48 I-O opcodes, to
                 avoid errors "crossing over" 128-GB!

   31-Jan-18   /G switch added to XDVD2/RDISK, for DOS "game" PCs.

   20-Nov-17   Initial "private" release of these drivers.


4. Switch Options
   --------------

   XMGR usually needs only a /B switch, if "booting" with an "EMM" driver.
   All XMGR switches are:

      /B     Sets "boot" mode.   XMGR uses a temporary area until an "EMM"
                driver enables upper memory.   Without /B, XMGR loads into
                UMBPCI "Shadow RAM" or in low memory if UMBPCI is unused.

      /Mn    Sets a temporary area, for loading XMGR in "boot" mode or for
                UMBPCI "Shadow RAM" DMA until a workspace buffer gets set.
                /M values are:

                    /M1 = 64K.    /M3 = 192K.   /M5 = 320K.   /M7 = 448K.
                    /M2 = 128K.   /M4 = 256K.   /M6 = 384K.   /M8 = 512K.

                Without /M, the 320K area is used.   Temporary system data
                can go anywhere in memory!   /Mn helps to find a safe area
                for XMGR to use.

      /Nnn   Sets how many XMS "Handles" are available.   The value nn may
                be 48, 80, or 128.   The /B "boot" option permits /N24 and
                /N32 to save memory, but 24 or 32 "Handles" may be too few
                and should be tested!   Without /N, 48 "Handles" are set.

      /PA    Specifies use or non-use of PS/2 Port 92h logic to handle the
      /PN       "A20" line.   /PA means "Always" use Port 92h logic.   /PN
                means "Never" use it and handle "A20" via normal keyboard-
                port logic.   Without /P, XMGR "asks the BIOS" if Port 92h
                hardware is present.   Keyboard-port logic is used if not.
                If "A20" is found "on" as XMGR loads, XMGR does not handle
                it at all.

      /Rnn   Reserves (skips above) low XMS memory needed for DOS "games",
                etc.   Values are any number of megabytes from 2 thru 2048
                (2 Gigabytes) and specify the start of user XMS, e.g. /R16
                reserves all XMS up to the 16-MB area.    If ".5" is given
                after a /R value, 0.5-MB more XMS is reserved, e.g. /R15.5
                reserves 15.5-MB of XMS, which may help in protected-mode.
                For an invalid /R value, XMGR will display "/R invalid; NO
                reserved XMS set!" but will proceed.   The reserved XMS is
                held until the last of XHDD/XDVD2/RDISK to load  issues /F
                to "free" it.   So, other drivers using XMS cannot "steal"
                any XMS reserved for a DOS "game"!   READ Section 6 below,
                for a full description of reserved XMS usage.

             *** NOTE ***
                XMS handlers cannot get XMS from the BIOS before the first
                runtime XMS call.   That is after XMGR's Init routines are
                dismissed!   If /R asks for more XMS than a system has, no
                error message can be given; but XMGR will proceed, without
                ANY reserved XMS.   Users must AVOID impossible /R values!

      /Tn    Sets the BIOS calls to use in getting extended memory:

                   /T0   No "E820h" or "E801h" calls.
                   /T1   Memory-list calls only (Int 15h, AX=E820h).
                   /T2   A dual-area call only  (Int 15h, AX=E801h).
                   /T3   "E820h" calls first, then an "E801h" call.

                /T can usually be omitted, causing a /T3 default.   An old
                64-MB call is also used for /T0 memory.   Users might want
                to test /T1 and /T2, since a pre-1996 BIOS may not execute
                them properly.   If so, /T0 will be required.

      /W     Requests using the system workspace buffer for UMBPCI "Shadow
                RAM" DMA.   If /W is omitted, XMGR sets its own low memory
                buffer.   /W may NOT be given with PC-DOS or EDR-DOS!   /W
                is ignored if UMBPCI is not used.

      /Z     For XMGR or XHDD, moves protected-mode data in 8K blocks (not
                64K).   /Z is unneeded with many "EMM" drivers or for real
                mode usage.    With VCPI/DPMI/etc. drivers, a PC should be
                tested to find if /Z is needed.   BAD schemes, which allow
                too few interrupts during XMS moves, may still be in use!

             --------------------

   RDISK requires only a /S size and a /: drive-letter switch.   All RDISK
   switches are:

      /F     For RDISK, XHDD, and XDVD2, makes "free" any reserved XMS set
                by XMGR for a DOS "game".    /F should be issued only from
                the LAST of these drivers to load, so any XMS reserved for
                a DOS "game" will STAY reserved until /F "frees" it!

      /G     For RDISK, XHDD, or XDVD2, reserves ALL "leftover" XMS memory
                with old DOS games that FAIL if the game finds unused XMS!
                /G should be issued only from the LAST of these drivers to
                load, as NO free XMS will be left afterward!

      /Snn   Specifies a desired RAM-disk size in megabytes of XMS memory.
                Values are any number from 2 to 2047 (2 Gigabytes).   When
                /S is omitted or invalid, a 25-Megabyte default is used.

      /:L    Specifies the DOS drive letter desired to access RDISK files.
                L may be any available drive letter from A to Z, e.g.  /:N
                assigns drive N: to all RDISK files.   If the drive letter
                is too high or already in use, RDISK aborts, and users may
                need "LASTDRIVE=" in CONFIG.SYS to set more drives.   When
                RDISK loads from CONFIG.SYS, or if /: is omitted, the next
                free drive letter is used.

             --------------------

   XHDD usually needs only a /H switch to use HMA space and a /S switch to
   set its cache size.   All XHDD switches are:

      /A     For XHDD and XDVD2, requests "alternate" addresses for Legacy
                IDE controllers, 01E8h/0168h for the first one, and 01F0h/
                0170h for a second.    /A is rarely needed.    Without /A,
                the first Legacy controller uses 01F0h/0170h, and a second
                uses 01E8h/0168h, as usual for PC mainboards.

      /B     Loads a basic UltraDMA disk driver (no cache).    128K of XMS
                is required as a buffer for disk I-O unsuited to UltraDMA.
                With /B, the /E /O /P and /S switches are ignored.

      /E     Omits all UltraDMA logic, for early 486 PCs with no UltraDMA,
                or for "emulators" that FAIL to emulate all disk commands!
                XHDD then "calls the BIOS" for disk I-O and caches data as
                needed, after BIOS I-O is done.   /E can cause SLOW speed,
                as most BIOS programs cannot do DMA when protected-mode is
                used!   With /E, the /A /O and /Q switches are ignored.

      /F     See /F for RDISK, above.

      /G     See /G for RDISK, above.

      /H     For XHDD and XDVD2, loads most of the driver into "free HMA".
                /H must NOT be used with ROM-DOS (NO "free HMA")!   MS-DOS
                kernels have ERRORS declaring "free HMA" which can cause a
                crash!    If so, OMIT /H when loading both XHDD and XDVD2,
                so they load only in upper/DOS memory.

      /O     "Overlaps" disk UltraDMA with caching tasks for faster speed.
                /O may NOT work on old/odd/"cheap" PC mainboards unable to
                do UltraDMA and access XMS at the same time!   PCs must be
                tested with /O.   If disk errors occur but CD/DVD input by
                XDVD2 runs fine, /O must NOT be used!

      /P     Puts the binary-search table in upper/DOS memory (not in XMS)
                for a slight real-mode and up to a 3% protected-mode speed
                increase.   /P uses 32 more bytes per megabyte of cache; a
                200-MB cache takes 6400 extra bytes, etc.   The maximum /P
                cache is 1536-MB (1.5-GB).   /P is totally optional.    If
                not used, or when over a 1.5-GB /P cache is requested, the
                search table goes in XMS memory and XHDD will work exactly
                as before.

      /Q     Awaits "data request" before starting UltraDMA I-O transfers.
                /Q is rarely needed, only for old systems where the driver
                loads O.K. but seems unable to transfer data.    /Q is NOT
                for use with Sabrent or other SATA-to-IDE adapters that do
                not emulate "data request"!

      /Snn   Sets the cache size, in megabytes of XMS memory.   Values are
                any number from 5 to 4093 (4 Gigabytes).   A minimum 20-MB
                cache is recommended, when possible, for best performance.
                If /S is omitted or invalid, a 20-MB cache is used.   XHDD
                will display "XMS init error" and abort, if not-enough XMS
                memory is free.   If so, request a smaller cache.

      /Z     See /Z for XMGR, above.

             --------------------

   XDVD2 usually needs only a /H switch to use "free HMA" and a /D: switch
   to set its "device name" for SHSUCDX/MSCDEX.   All XDVD2 switches are:

      /A     See /A for XHDD, above.

      /D:    Specifies the "device name" used by the CD/DVD Redirector to
                access CD/DVD drives, e.g.   /D:CDROM1   /D:SANYO1   etc.
                If /D: is omitted, or the name following a /D: is missing
                or invalid,  UDVD1  is set by default.

      /F     See /F for RDISK, above.

      /G     See /G for RDISK, above.

      /H     See /H for XHDD, above.

      /UX    Disables all CD/DVD UltraDMA, even for units that can do it.
                All CD/DVD data input then uses PIO-mode.   /UX is rarely
                needed, only for odd drives that do not obey ATAPI rules.

             --------------------

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


5. Example Configuration Files
   ---------------------------

   A) A small real-mode system that needs only XMS may use this CONFIG.SYS
      example file:

          ..
          ..
      DOS=HIGH
      DEVICE=C:\BIN\XMGR.SYS /Rnn              ;R if DOS "games" need it
          ..
          ..  Int 13h drivers cached by XHDD load now.
          ..
      DEVICE=C:\BIN\XHDD.SYS /S20 /H /O        ;Min. 20 MB recommended
      DEVICE=C:\BIN\XDVD2.SYS /D:BLURAY1 /H    ;Must load after XHDD
      DEVICE=C:\BIN\RDISK.COM /S5 /F           ;Optional.   If not used,
                                               ; XHDD/XDVD2 can issue /F
          ..
          ..  Further CONFIG.SYS commands can be given here.
          ..

   B) Real-mode systems with V3.70+ UMBPCI and XMGR do not need the LOWDMA
      driver, as XMGR has an "I-O Catcher" for UMBPCI.   This scheme takes
      NO low memory if /W can be used (MS-DOS etc.) or only 544 low memory
      bytes without /W (PC-DOS etc.).   XMGR and other drivers load direct
      to UMBPCI "Shadow RAM"!   Systems which permit multiple providers of
      upper memory (MS-DOS, PC-DOS, etc.) can also load an "EMM" driver as
      shown below, to map the B000-B7FFh "Monochrome Graphics" area as 32K
      more upper memory.     For more SERIOUS protected-mode notes, please
      READ Section 6 below!    An example CONFIG.SYS file is:

          ..
          ..
      DOS=HIGH,UMB
      DEVICE=C:\BIN\UMBPCI.SYS
      DEVICE=C:\BIN\XMGR.SYS /W /Rnn            ;W only when permitted!
                                                ;R <= 15.5 MB with JEMM!
      DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF X=C800-EFFF ...   ;Optional
          ..
          ..  Int 13h drivers cached via XHDD load now
          ..  and can be loaded in UMBPCI upper memory.
          ..
      DEVICEHIGH=C:\BIN\XHDD.SYS /S200 /H /O    ;Fast 200 MB cache
      DEVICEHIGH=C:\BIN\XDVD2.SYS /D:CDROM1 /H  ;Must load after XHDD
      DEVICEHIGH=C:\BIN\RDISK.COM /S50 /F       ;Optional.  If unused,
                                                ; XHDD/XDVD2 can issue /F
          ..
          ..  Further CONFIG.SYS commands can be given here.
          ..

   C) A protected-mode system with XMGR and an "EMM" driver can use XMGR's
      "boot", taking a minimum 304 bytes of low memory for a 24-entry "XMS
      Handles" table, plus any low memory the "EMM" driver may need.   For
      more SERIOUS protected-mode notes, please READ Section 6 below!    A
      CONFIG.SYS example file is:

          ..
          ..
      DOS=HIGH,UMB
      DEVICE=C:\BIN\XMGR.SYS /B /N24 /R15.5     ;24 Handle XMGR "boot"
                                                ;R <= 15.5 MB with JEMM!
      DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF ...
      DEVICEHIGH=C:\BIN\XMGR.SYS                ;Loads the runtime XMGR
          ..
          ..  Int 13h drivers cached by XHDD load
          ..  now and can load into upper memory.
          ..
      DEVICEHIGH=C:\BIN\XHDD.SYS /S400 /H /O /P ;Optimal 400 MB cache
      DEVICEHIGH=C:\BIN\XDVD2.SYS /D:MYDVD /H   ;Must load after XHDD
      DEVICEHIGH=C:\BIN\RDISK.COM /S125 /F      ;Optional.  If unused,
                                                ; XHDD/XDVD2 can issue /F
          ..
          ..  Further CONFIG.SYS commands can be given here.
          ..

   In each example above, XDVD2 must load after XHDD, so XDVD2 will "find"
   XHDD in memory and call it for CD/DVD file caching.

   Users that need RDISK with a specific drive letter may delay loading it
   until AUTOEXEC.BAT is run.   If /F or /G are also needed for DOS games,
   RDISK must issue them from AUTOEXEC, since it is then the last of these
   drivers to load.   Whenever RDISK is used, AUTOEXEC.BAT must also issue
   commands to copy all RDISK programs and data up to the RAM-disk, as XMS
   memory is LOST when PCs shut down!   Such copies require little time.

   If XHDD and RDISK will both run, users must balance how much XMS memory
   the drivers take.   XHDD can set a 400-MB cache, as in example C above,
   and RDISK can request 125-MB of XMS for its programs, "fast" data files
   and compiler TEMP files.   Such sizes should be optimal on most systems
   but can be adjusted up or down, as desired.    All remaining XMS memory
   is left free for use by other programs.   The basic "plan" is for RDISK
   to hold programs and high-speed files, while XHDD then caches "regular"
   data files.   Properly balanced use of XMS memory will give a VERY fast
   DOS system!


6. Technical Notes
   ---------------

   Protected-mode users must pretest "I=nnnn,nnnn" or "X=nnnn,nnnn" values
   for "EMM" drivers, as "I=TEST"/"X=TEST" options may fail on newer main-
   boards.   New "cheap BIOS" mainboards now OMIT logic used only for DOS,
   at-least UltraDMA output code, perhaps more!   Such boards require XHDD
   to load AFTER the "EMM" driver enables "V86" protected-mode, which will
   "fix" any BIOS problem; also users CANNOT issue UltraDMA disk output in
   CONFIG.SYS until after XHDD can load (V7.0+ MS-DOS users should disable
   any CONFIG.SYS "log" files).   Use of JEMMEX or other "EMM" drivers but
   JEMM386 should be AVOIDED!   Other "EMM" drivers were discontinued long
   ago, some with never-fixed ERRORS, e.g. Microsoft EMM386 "Virtual DMA"!
   JEMMEX or other combined "EMM + XMS" drivers are unrecommended, as they
   cannot work with XMGR and so CANNOT have XMGR'S "I-O Catcher" deal with
   "Shadow RAM" disk/diskette I-O!   Thus the LOWDMA driver offered in the
   UMBPCI package shall be required for diskette ISA DMA in UMBPCI "Shadow
   RAM" (burns up 672 low-memory bytes!), and some "cheap BIOS" mainboards
   may YET require XHDD to load first, which JEMMEX will NOT allow (no XMS
   until it loads)!   Users needing "Shadow RAM" and "mapped" upper memory
   can run CONFIG.SYS example B, as in Section 5 above, which loads ALL of
   XMGR in "Shadow RAM" and takes NO low memory!    This includes its "I-O
   Catcher" (makes LOWDMA not needed) and ensures disk UltraDMA in "Shadow
   RAM" will be reliable until XHDD can load.

   When reserved XMS is needed for a DOS "game" etc., XMGR /R can be given
   with no restrictions on a real-mode PC (CONFIG.SYS example A in Section
   5 above, or CONFIG.SYS example B without JEMM386).   However, protected
   mode PCs cannot reserve over 15.5-MB of XMS, as JEMM386 takes <= 0.5-MB
   of XMS for its data and DMA buffer, and that buffer must "end" at 16-MB
   or below!    Also, if a "cheap BIOS" mainboard requires that XHDD loads
   before JEMM386, the reserved XMS plus XHDD's cache XMS may not go above
   15.5-MB.   Users can test XMGR /R8 with XHDD /S7, that may work for old
   "Sound Blaster" cards, etc., which actually need <= 8-MB of XMS (XHDD's
   7-MB cache is only 10% slower than 200-MB).   As a last-resort, XHDD /B
   can be run (only 128K of XMS) to allow XMGR /R15; but this forfeits all
   caching.   If these cases do not work (and many DOS "games" ARE written
   with NO "rules"!), or for other cases when protected-mode PCs need over
   15.5-MB of reserved XMS, XMGR /R may NOT be used, and old XMSGet/XMSPut
   handlers must deal with reserved XMS, AFTER JEMM386 loads.

   With V7.0+ MS-DOS, CONFIG.SYS cannot set over "BUFFERS=12" if both XHDD
   and XDVD2 load in "free HMA" (/H switches).   For more DOS buffers, use
   "BUFFERSHIGH=nn".    On systems with limited "free HMA", XHDD and XDVD2
   can omit /H switches and load in only upper/DOS memory.

   XMGR and XDVD2 post normal XMS or CD/DVD error codes, as needed.   They
   are listed in the "V3.0 XMS Specification" and in the Microsoft "MS-DOS
   CD-ROM Extensions 2.1" document, from Microsoft or elsewhere.   XHDD is
   a "BIOS driver" and returns BIOS error codes for disks/diskettes run by
   the BIOS.    For its own SATA/IDE disks, XHDD can return these 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!

   XHDD handles only "Legacy" or Native-PCI IDE controllers.   "RAID only"
   chipsets, port-multiplier chips, and ADMA chips are unsupported.   XHDD
   runs only "Legacy", "Compatibility", and "Native IDE" AHCI controllers.
   On mainboards with no such controller settings, a Sabrent or equivalent
   SATA-to-IDE adapter can let XHDD and XDVD2 run SATA disks/CDs/DVDs from
   a parallel-port IDE controller (80-pin cable) at DMA speeds.   "Add-on"
   PCI-bus adapter cards, which can be detected thru 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 00A8h 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 XHDD:

     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 run disk "Shadow RAM" UltraDMA until XHDD loads.   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 XHDD let the BIOS deal with CHS I-O.    When BIOS UltraDMA was
        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 were set "active" via 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.

