
                 XMGR, UDMA, and UDVD -- DOS Device Drivers
               ==============================================

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

   XMGR, UDMA, and UDVD are DOS device drivers.    They can be used with a
   system having an 80386+ CPU and running MS-DOS V5.0+ or equivalent.

   XMGR is a DOS driver that works as an XMS memory manager.   It supports
   V3.70+ UMBPCI by Uwe Sieber.    After UMBPCI enables upper-memory, XMGR
   can load there directly and provide both upper and XMS memory for a DOS
   system.   XMGR uses an "I-O catcher" with UMBPCI, to intercept diskette
   or hard disk I-O above 640K.   Such I-O is done thru a low memory area,
   to avoid DMA trouble in UMBPCI "Shadow RAM".   XMGR also supports V4.49
   and V4.95 EMM386 (MS-DOS V6.22 or V7.10).   With EMM386, XMGR using its
   /B switch can first "boot" into temporary space.   After EMM386 enables
   upper-memory, XMGR loads there with no /B switch, copies all its "boot"
   data, and takes-over XMS work.    Only its XMS "Handles" table stays in
   low memory, so EMM386 can always find them at fixed addresses.    For a
   small XMS-only system, XMGR can also load entirely in low memory.

   UDMA is a DOS hard-disk caching driver.    It intercepts "Int 13h" BIOS
   I-O requests and caches data for up to 17 BIOS disk drives.   New types
   with over 128-GB of data are supported.   One or two standard diskettes
   (A: and B: drives) will also be cached, when present.   UDMA can accept
   48-bit LBA mode and 24-bit CHS mode I-O calls, so it runs on new or old
   DOS systems.   It has internal UltraDMA logic and does all possible I-O
   for UltraDMA disks thru its XMS cache buffers, for faster speed.   UDMA
   calls the BIOS to handle diskettes and non-UltraDMA disks, so it caches
   ALL such drives on DOS systems!   SATA or other type disks require only
   their BIOS I-O logic.   DOS "Int 13h" drivers can load before UDMA, and
   it will cache data for their disks too.   ("ASPI" or other drivers with
   no Int 13h logic are unsupported).    UDMA caches 5-MB to 1-Gigabyte of
   data!   For an "LZ" V7.10 MS-DOS kernel and 4DOS COMMAND.COM, only 1456
   bytes of upper memory are used for up to a 250-MB cache!   UDMA also is
   able to run as a stand-alone UltraDMA driver (no caching or diskettes),
   for use in system tests or diagnostics.

   UDVD is a DOS driver for 1 to 3 CD/DVD drives.   It handles standard PC
   IDE channels, and it can run newer UltraDMA or older "PIO mode" drives.
   On loading, it checks both IDE channels in order from primary-master to
   secondary-slave, and it runs the first 3 CD/DVD drives seen.   UDVD has
   switches (see below) to specify a driver name or request other options.
   UDVD accepts file-input requests from SHCDX33C, MSCDEX, etc.    It also
   accepts DOS "audio" requests and can "play back" audio CDs.    If "raw"
   CD/DVD input is not needed and UDMA is loaded, UDVD's /C switch enables
   caching of data files through the UDMA driver!

   The small CC.COM "Clear Cache" program can help verify files written by
   UDMA.   Entering  CC  at the DOS command-prompt sends a BIOS "reset" to
   all disks, making UDMA discard its cache.    Data on the disk (NOT data
   still in the cache!) can then be compared with the original output.


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

   XMGR, UDMA, and UDVD are offered as "free software", as-is, and "use at
   your own risk", and with NO warranties, not even the implied warranties
   of MERCHANTABILITY nor of FITNESS for ANY particular purpose!

   Driver questions or comments may be addressed to the website of Johnson
   Lam, <johnson@tmfc.net>.


3. Revisions
   ---------

   13-Aug-07   UDMA now uses /S5 to /S1023 for 5-MB to 1-Gigabyte caches!
                 All drivers again check for an 80386+ CPU.

    8-Aug-07   UDMA /SL switch added to cache 750 Megabytes!
    2-Aug-07   UDMA stand-alone driver corrected to ignore "other" disks.
                 400-MB cache added to UDMA!

   27-Jul-07   XMGR/UDMA/UDVD "real mode" moves corrected for 80386 CPUs.
   24-Jul-07   UDMA now has "7-byte block addresses" and handles up to 17
                 BIOS units, 3 UDVD CD/DVD drives, 236 other "externals"!

   22-Jul-07   UDMA can now "dismiss" its UltraDMA logic with no UltraDMA
                 disks, and it now supports 3 other "internal" drivers.
   14-Jul-07   UDMA now at 1424 bytes for 200-MB with an "LZ" DOS kernel.

   17-Jun-07   UDMA 120- and 200-MB cache sizes added for better HMA use.
   14-Jun-07   UDVD now shares UDMA's "XMS move" logic, saving 240 bytes!
   11-Jun-07   UDMA caches A: and B: diskette drives!   /C added to UDVD.

    7-Jun-07   UDVD now caches CD/DVD data through the UDMA driver!
    5-Jun-07   UDMA saves memory by putting much of its logic in the HMA!
    4-Jun-07   UDMA and UDVD ignore "A20 disable" errors for JEMM386.

   29-May-07   UDMA 250-MB cache re-added, HMA memory capability added!
   24-May-07   HUGE problem in XMGR (BX-reg. error codes) has been FIXED!
   22-May-07   Original issue, derived from the old QHIMEM/QCACHE/QCDROM.


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

   XMGR normally needs only the /B switch if "booting" with EMM386.   XMGR
      switch options are as follows:

      /B     Specifies "boot" mode.   XMGR loads in temporary memory until
                upper-memory is enabled by EMM386.   Without /B, XMGR will
                load stand-alone in low memory or directly in upper-memory
                with UMBPCI.   See the CONFIG.SYS examples in section 5.

      /Mn    Specifies the temporary area used to load XMGR in "boot" mode
                and used for UMBPCI upper memory I-O before DOS can post a
                "workspace" buffer.   Values are:

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

                Without /M, /M5 is assumed and the 320K area will be used.
                NOTE:  A DOS system often may NOT load at address 0 up and
                may leave temporary data anywhere in memory!   /Mn changes
                the temporary area to find a "safe" place for XMGR to use.
                /M is ignored if XMGR loads stand-alone.

      /Nnn   Specifies how many XMS "Handles" can be used by DOS programs.
                The value nn may be 48, 80, or 128.   If /N is omitted, 48
                "Handles" are used and work fine for most systems.   A big
                system doing much XMS work may need 80 or 128 "Handles".

      /Tn    Specifies the BIOS requests to use in getting extended memory
                as follows:

                   /T0   Neither "E820h" nor "E801h" requests.
                   /T1   Memory-list requests only (Int 15h, AX=E820h).
                   /T2   A dual-area request only  (Int 15h, AX=E801h).
                   /T3   "E820h" requests first, then an "E801h" request.

                /T can usually be omitted, which causes /T3 to be assumed.
                In addition, XMGR always uses an old 64-MB request, to get
                extended memory for /T0, or if the requests specified with
                /T1 through /T3 are unsuccessful.   Users may need to test
                /T1 and /T2 separately, to see if their BIOS accepts them.
                A pre-1994 BIOS may not "ignore" /T1 thru /T3 properly and
                may require /T0 to be used.   For compatibility with older
                QHIMEM drivers, /T4 thru /T7 may be used and work the same
                as /T0 thru /T3.

      /W     Specifies use of the DOS "workspace" buffer, for upper-memory
                I-O if loading with UMBPCI.    If /W is omitted, or if the
                DOS system does not have proper workspace logic, XMGR will
                set its own buffer in low memory.   An EDR-DOS system must
                OMIT this switch!   Without UMBPCI, /W will be ignored.

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

   UDMA normally needs no switches.   Its switch options are as follows:

      /A     Specifies use of the old alternate EIDE controller addresses,
                01E8h-01EFh on the primary channel, and 0168h-016Fh on the
                secondary channel.   If /A is omitted, the driver will use
                normal controller addresses of 01F0h-01F7h or 0170h-0177h.
                /A is only for an "odd" SATA BIOS or other unusual cases.

      /Q     Enables awaiting "data request" before starting UltraDMA data
                transfers.   /Q must be OMITTED with a SATA-to-IDE adapter
                by Sabrent etc., as such cards do not emulate data request
                from SATA disks!   /Q is not needed with newer controllers
                or IDE disks.   It is for "old" systems and should be used
                only if UDMA loads O.K. but seems unable to transfer data.

      /R     Restricts UDMA to "regular" memory and avoids the HMA for its
                binary-search table.   /R may be required with DOS systems
                that will NOT allocate memory until after CONFIG.SYS loads
                drivers!   /R is unneeded with V7.10 MS-DOS, V6.22 MS-DOS,
                V7.1 PC-DOS, PTS-DOS, or EDR-DOS.   /R is REQUIRED to work
                with ROM-DOS!   Other DOS variants should be tested first.

      /Sn    Specifies a cache size in Megabytes of XMS memory as follows:

                /S5         5-MB cache,  1280-byte table size,  8K blocks.

                /S10       10-MB cache,  2560-byte table size,  8K blocks.
                /S20       20-MB cache,  2560-byte table size, 16K blocks.
                /S40       40-MB cache,  2560-byte table size, 32K blocks.

                /S80       80-MB cache,  2560-byte table size, 64K blocks.
                  .        .              .
                  .  thru  .              . (32 bytes per MB)
                  .        .              .
                /S1023   1023-MB cache, 32736-byte table size, 64K blocks.

                Values for /S may be 5, 10, 20, 40, or a large-cache value
                from 80 thru 1023 (1023 = 1-Gigabyte!).   If /S is omitted
                or invalid, an 80-MB large cache is assumed.    Except for
                old systems with less memory, /S125 or more should be used
                for today's BIG files!   Some memory must be kept free for
                other applications, thus with current system memory sizes,
                suggested UDMA /S values are:

                     256-MB memory:  /S125      1-GB memory:   /S500
                     512-MB memory:  /S250      2-GB or more:  /S1000

                For more about UDMA and cache sizes, see section 7 below.

      /U     Requests the "stand alone" UltraDMA driver only (no caching),
                which may be of help in running a disk diagnostic program.

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

   UDVD usually needs only /C for caching and /D: to specify a device-name
      for the SHCDX33C "CD-ROM Redirector".   UDVD switch options are:

      /A     Specifies use of the old alternate EIDE controller addresses.
                See the /A description for UDMA, above.

      /C     Requests data-file caching by the UDMA driver.    This causes
                "raw mode" input requests to be rejected, as UDMA requires
                sectors that are an even multiple of 512 bytes for caching
                ("raw" sectors are 2352 bytes!).    If /C is omitted, "raw
                mode" input (audio, track-writers, etc.) will be accepted.

      /D:    Specifies the desired device name, used by SHCDX33C to access
                the CD/DVD drives.   Example:  /D:CDROM1  /D:MYCDROM  etc.
                Device names must be from 1 to 8 bytes O.K. for use in DOS
                filenames.   If /D: is omitted, or the device name after a
                /D: is missing or invalid, UDVD1 will be used by default.

      /UX    Disables ALL UltraDMA, even for a CD/DVD drive capable of it.
                UDVD then uses "PIO mode" for every I-O request.    /UX is
                rarely needed.   It is mainly for tests and diagnostics.

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

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


5. Setup and Configuration
   -----------------------

   XMGR, UDMA, and UDVD are all loaded through the CONFIG.SYS file.   Your
   CONFIG.SYS file should have command lines similar to:

       DEVICE [HIGH] = [path] XMGR.SYS [/B] [/Mn] [/Nnn] [/Tn] [/W]

       DEVICE [HIGH] = [path] UDMA.SYS [/A] [/Q] [/R] [/Snnnn] [U]

       DEVICE [HIGH] = [path] UDVD.SYS [/A] [/C] [/D:DeviceNm] [/UX]

   Examples:   DEVICE=C:\BIN\XMGR.SYS /N128 /B

               DEVICEHIGH=C:\DRIVERS/UDMA.SYS /S125

               DEVICEHIGH=C:\BIN\UDVD.SYS /D:MYDVD /C

   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.   An example CONFIG.SYS file using
   V3.70+ UMBPCI and XMGR is as follows:

      SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
      DEVICE=C:\BIN\UMBPCI.SYS
      DEVICE=C:\BIN\XMGR.SYS /W
      DOS=HIGH,UMB
      DEVICEHIGH=C:\BIN\UDMA.SYS /S200
      DEVICEHIGH=C:\BIN\UDVD.SYS /D:CDROM1 /C
          ..
          ..  Etc.
          ..

   XMGR can be used stand-alone, for 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:

      SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
      DEVICE=C:\BIN\XMGR.SYS
      DOS=HIGH
      DEVICE=C:\BIN\UDMA.SYS /S40
      DEVICE=C:\BIN\UDVD.SYS /D:MYCDROM /C
          ..
          ..  Etc.
          ..

   With EMM386 and XMGR, XMGR must load first in "boot" mode, then EMM386,
   and then XMGR can finally load in upper-memory.   An example CONFIG.SYS
   file using the XMGR "boot" procedure is as follows:

      SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
      DEVICE=C:\BIN\XMGR.SYS /B                         [/B for "boot"]
      DOS=HIGH,UMB
      DEVICE=C:\DOS\EMM386.EXE I=B000-B7FF NOEMS ...
      DEVICEHIGH=C:\BIN\XMGR.SYS                        [No /B used here!]
      DEVICEHIGH=C:\BIN\UDMA.SYS /S250
      DEVICEHIGH=C:\BIN\UDVD.SYS /D:MYDVD /C
          ..
          ..  Etc.
          ..

   UDVD "links" with UDMA using the Int 13h vector address, that UDMA sets
   to intercept diskette or hard disk I-O.   If CD/DVD caching is desired,
   UDVD must load directly after UDMA, so other drivers do NOT "intervene"
   and change the Int 13h vector!   If other Int 13h DOS drivers are used,
   UDMA must load after them, so it can cache the other drivers' disk I-O.
   When XMGR, other disk drivers, UDMA, and UDVD are loaded, the remaining
   drivers in CONFIG.SYS (SETVER.EXE, ANSI.SYS, etc.) can then load in any
   desired order.

   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
   "UDMA Capable" for a disk, enable it.   Power-saving features such as a
   "drive spin-down timeout" should be DISABLED or driver I-O requests may
   time out!   Also, be sure to use an 80-connector cable for any UltraDMA
   drive running in "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 one "end" and the middle connector!   This avoids ERRORS
   as 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!
   Also, note that some CD/DVD drives (Sony, etc.) do NOT "obey" all ATAPI
   standards and may require the UDVD /UX switch to DISABLE all UltraDMA!


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

   XMGR and UDVD return normal XMS or CD/DVD driver error codes if needed.
   These are shown in the V3.0 XMS Specification and the Microsoft "MS-DOS
   CD-ROM Extensions 2.1" documentation, available from Microsoft or other
   sources on the Internet.

   UDMA works as a "BIOS driver" and returns whatever codes the BIOS posts
   for its diskettes and hard-disks.   For UltraDMA disks, UDMA can return
   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.
           BBh - "Unspecified".

   "Unspecified" is returned only if UDMA runs as a caching driver.   As a
   stand-alone driver, UDMA returns all the other disk codes, to help with
   diagnostic work.   Many DOS programs display only "Disk Error" messages
   with NO code, and disk errors may require running a diagnostic program!


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

   UDMA uses 2528 bytes for driver logic and stack, plus the binary-search
   table sizes shown above for its /S switch.   It places its search table
   and 1088 bytes of logic into the HMA, unless /R is given or the HMA has
   under 3648 bytes free (2368 bytes for /S5), in which case normal memory
   will be used.   UDMA sets the largest of its 5-MB, 10-MB, 20-MB, 40-MB,
   or user-specified "large cache" size which will fit in available HMA or
   normal memory.   /S values below 80 will be "rounded" to the nearest of
   5, 10, 20, or 40-MB, and that is the maximum cache which is set.   UDMA
   loads from a 4.5K object file, thus its 5-MB cache in normal memory can
   always be set.   To avoid kernel "bugs" in V7.10 MS-DOS and maybe other
   DOS variants, UDMA caches above 250-MB avoid the HMA and always load in
   normal memory.   Enough XMS cache memory must be free, or UDMA displays
   "XMS init error" and ABORTS!   If so, a lower /S value is needed.   For
   an old V2.0 XMS manager (ROM-DOS, etc.), do not use over /S40 or 40-MB!

   To save memory, UDVD is written for use with SHCDX33C and sets no stack
   of its own.   Users of other "CD-ROM redirectors" (MSCDEX, etc.) should
   verify that they provide adequate stack space for drivers, before using
   UDVD with them!

   XMGR loads in UMBPCI upper-memory BEFORE that memory is declared to the
   DOS system!   Memory displays using UMBPCI may not list XMGR, since its
   memory is not part of the DOS memory lists.   Such memory displays will
   begin with a block having a 00A7h offset, or greater if using 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!   Newer BIOS programs may use UltraDMA to load programs into upper
   memory.   If this is UMBPCI "Shadow RAM", a CRASH will occur!   To stop
   this, and handle new BIOS programs, users should follow these two RULES
   for running UMBPCI together with XMGR and UDMA:

     A) The loading "order" for V3.70+ UMBPCI and XMGR, shown in section 5
        above, MUST be used!    This lets the XMGR "I-O Catcher" intercept
        and process upper memory disk I-O, until the UDMA driver loads and
        takes-over disk UltraDMA.   Older UMBPCI versions, or other UMBPCI
        loading schemes, are NOT recommended!

     B) When CHS I-O is done (MS-DOS V6.22 or older), every disk MUST have
        valid CHS parameters!   If not, UDMA and the "I-O Catcher" let the
        BIOS handle CHS I-O.   If BIOS UltraDMA is not disabled, a similar
        "Shadow RAM" CRASH will occur!

   Some "CD-ROM boot" programs handle the CD/DVD as a "fake" hard disk and
   provide incorrect EDD BIOS data for it!   In scanning for disks to use,
   UDMA may display "EDD BIOS error!  Unit ignored.", then go on searching
   for more UltraDMA disks.   Users who did NOT "boot" from CD/DVD need to
   see which disk was passed-over and why.   Users who DID "boot" from CD/
   DVD, where all UltraDMA disks were found O.K., may IGNORE this message!
   It is caused by an ERROR in the "CD-ROM boot" program, NOT by a problem
   with UDMA or its UltraDMA disks!

   Some BIOS programs do not "configure" a mainboard controller chip if no
   user devices are found!   If the drivers detect no UltraDMA units, UDMA
   handles all disks as non-UltraDMA, and UDVD uses "PIO mode" for all its
   CD/DVD drives.   But the drivers first test for an UltraDMA controller.
   If it is unconfigured, they display "BAD UltraDMA controller" and go on
   as above (in stand-alone mode, UDMA will abort!).   If "Bad controller"
   is displayed, users must check that every UltraDMA drive was set active
   using the BIOS set-up logic.   If this was done, "Bad controller" means
   the chip is not set for both "Bus Master" and "I-O Space", and the BIOS
   needs to be UPDATED!   Also, note that UDMA and UDVD cannot run "Native
   PCI mode" chips (i.e. servers), only chips set for "Legacy IDE mode".

