Command: XMGR.SYS

  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.

Syntax:

  DEVICE[HIGH] = [path] XMGR.SYS [/B] [/Mn] [/Nnn] [/PA] [/PN] [/Rnn]
                 [/Tn] [/W] [/Z]

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 = 64KiB    /M3 = 192KiB   /M5 = 320KiB   /M7 = 448KiB
         /M2 = 128KiB   /M4 = 256KiB   /M6 = 384KiB   /M8 = 512KiB
         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 UHDD/UDVD2/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 UHDD, 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!

Comments:

  For all switches in each driver, a dash may replace the slash and lower
  case letters may be used if desired.
  UHDD and UDVD2 are Closed-Source DOS drivers for PCs with an 80386+
  CPU (UHDD requires an 80486+ CPU) and using MS-DOS V5.0+ or a
  fully compatible variant.
  The latest UHDD and UDVD2 are Open Source device drivers for PCs with
  an 80386+ CPU and using FreeDOS, whereas at XMGR, RDISK it depends on
  the version number if it is Open Source or Closed Source.
  For more information and if you are in doubt, read "README.txt" in
  "drivers.zip".

Examples:

  Comment: There are new closed source drivers for UHDD.SYS (=XHDD.SYS)
  and UVD2.SYS (=XDVD2.SYS) which may have other options. So please do
  not rely on the options in the examples!
  A) A small real-mode system that needs only XMS may use this
    CONFIG.SYS/FDCONFIG.SYS example file:
       ..
       ..
     DOS=HIGH
     DEVICE=C:\BIN\XMGR.SYS /Rnn              ;R if DOS "games" need it
       ..
       ..  Int 13h drivers cached by UHDD load now.
       ..
     DEVICE=C:\BIN\UHDD.SYS /S20 /H /O        ;Min. 20 MB recommended
     DEVICE=C:\BIN\UDVD2.SYS /D:BLURAY1 /H    ;Must load after UHDD
     DEVICE=C:\BIN\RDISK.COM /S5 /F           ;Optional. If not used,
                                              ; UHDD/UDVD2 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 UHDD load now
       ..  and can be loaded in UMBPCI upper memory.
       ..
     DEVICEHIGH=C:\BIN\UHDD.SYS /S200 /H /O    ;Fast 200 MB cache
     DEVICEHIGH=C:\BIN\UDVD2.SYS /D:CDROM1 /H  ;Must load after UHDD
     DEVICEHIGH=C:\BIN\RDISK.COM /S50 /F       ;Optional. If unused,
                                               ; UHDD/UDVD2 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 UHDD load
       ..  now and can load into upper memory.
       ..
     DEVICEHIGH=C:\BIN\UHDD.SYS /S400 /H /O /P ;Optimal 400 MB cache
     DEVICEHIGH=C:\BIN\UDVD2.SYS /D:MYDVD /H   ;Must load after UHDD
     DEVICEHIGH=C:\BIN\RDISK.COM /S125 /F      ;Optional. If unused,
                                               ; UHDD/UDVD2 can issue /F
       ..
       ..  Further CONFIG.SYS commands can be given here.
       ..
  In each example above, UDVD2 must load after UHDD, so UDVD2 will "find"
  UHDD 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 UHDD and RDISK will both run, users must balance how much XMS memory
  the drivers take. UHDD 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 UHDD then caches "regular"
  data files. Properly balanced use of XMS memory will give a VERY fast
  DOS system!

Command: XMGR.SYS

Syntax:

Options:

Comments:

Examples:

See also: