Befehl: xmgr.sys

  XMGR ist ein "XMS-Manager" für bis zu 4 GB XMS-Speicher mit Unterstüt-
  zung von UMBPCI ab Version 3.70 von Uwe Sieber. XMGR kann direkt in den
  oberen UMBPCI-Speicher ("Shadow RAM") laden und im geschützten Modus in
  den regulären oberen Speicher "booten".

Syntax:

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

Optionen:

  XMGR benötigt normalerweise nur den Schalter /B, wenn mit einem EMM-
  Treiber gebootet wird. Es gibt folgende XMGR-Schalter:
  /B    Aktiviert den Boot-Modus. XMGR verwendet einen temporären Be-
        reich, bis ein EMM-Treiber den oberen Speicherbereich aktiviert.
        Ohne /B lädt XMGR in den UMBPCI-"Shadow-RAM" oder in den unteren
        Speicherbereich, falls UMBPCI nicht verwendet wird.
  /Mn   Legt einen temporären Bereich fest, der zum Laden von XMGR im
        Boot-Modus oder für UMBPCI-"Shadow RAM"-DMA verwendet wird, bis
        ein Arbeitsbereichspuffer eingerichtet ist.
        /M-Werte:
        /M1 = 64 KB  /M3 = 192 KB /M5 = 320 KB /M7 = 448 KB
        /M2 = 128 KB /M4 = 256 KB /M6 = 384 KB /M8 = 512 KB
        Ohne /M wird der 320-KB-Bereich verwendet. Temporäre Systemdaten
        können überall im Speicher abgelegt werden! /Mn hilft, einen
        sicheren Bereich für XMGR zu finden.
  /Nnn  Legt fest, wie viele XMS-Handles verfügbar sind. Der Wert nn kann
        48, 80 oder 128 sein. Die "Boot"-Option /B erlaubt /N24 und /N32,
        um Speicher zu sparen. Möglicherweise sind jedoch 24 oder 32
        Handles zu wenig und sollten getestet werden! Ohne /N werden 48
        Handles gesetzt.
  /PA   Gibt an, ob die PS/2-Port-92h-Logik zur Verarbeitung der "A20"
  /PN   Leitung verwendet werden soll. /PA bedeutet, die Port-92h-Logik
        "immer" zu verwenden. /PN bedeutet, die Port-92h-Logik "nie" zu
        verwenden und "A20" über die normale Tastatur-Port-Logik zu ver-
        arbeiten. Ohne /P "fragt XMGR das BIOS", ob Port-92h-Hardware
        vorhanden ist. Andernfalls wird die Tastatur-Port-Logik verwen-
        det. Wenn "A20" beim Laden von XMGR als "aktiv" erkannt wird,
        verarbeitet XMGR ihn überhaupt nicht.
  /Rnn  Reserviert (überspringt) niedrigen XMS-Speicher, der für DOS-
        "Spiele" usw. benötigt wird. Die Werte sind beliebig viele Mega-
        byte zwischen 2 und 2048 (2 Gigabyte) und geben den Beginn des
        Benutzer-XMS an. Z.B. reserviert /R16 den gesamten XMS-Speicher
        bis zum 16-MB-Bereich. Wird nach einem /R-Wert ".5" angegeben,
        wird 0,5 MB mehr XMS reserviert; z.B. reserviert /R15.5 15,5 MB
        XMS, was im geschützten Modus hilfreich sein kann.
        Bei einem ungültigen /R-Wert zeigt XMGR "/R ungültig; KEIN reser-
        viertes XMS gesetzt!" an, fährt aber fort. Der reservierte XMS
        wird gehalten, bis der letzte von UHDD/UDVD2/RDISK zu ladende
        Treiber /F ausgibt, um ihn freizugeben. Andere Treiber, die XMS
        verwenden, können daher keinen für ein DOS-Spiel reservierten XMS
        "stehlen".
  *** HINWEIS ***
        XMS-Handler können XMS erst nach dem ersten XMS-Aufruf zur Lauf-
        zeit vom BIOS abrufen. Das heißt, nachdem die Init-Routinen von
        XMGR beendet wurden! Wenn /R mehr XMS anfordert, als das System
        zur Verfügung hat, wird keine Fehlermeldung ausgegeben; XMGR wird
        jedoch ohne reserviertes XMS fortgesetzt. Benutzer sollten unmög-
        liche /R-Werte vermeiden!
  /Tn   Legt die BIOS-Aufrufe fest, die beim Abrufen des erweiterten
        Speichers verwendet werden sollen:
        /T0  Keine "E820h" oder "E801h" Aufrufe.
        /T1  Nur Speicher-Listen-Aufrufe (Int 15h, AX=E820h).
        /T2  Nur Dual-Area-Aufruf (Int 15h, AX=E801h).
        /T3  Zuerst "E820h"-Aufrufe, dann ein "E801h"-Aufruf.
        /T   Kann in der Regel weggelassen werden, was zu einem /T3-
             Standard führt. Ein alter 64-MB-Aufruf wird auch für /T0-
             Speicher verwendet. Benutzer sollten /T1 und /T2 testen,
             da ein BIOS vor 1996 diese möglicherweise nicht korrekt aus-
             führt. In diesem Fall ist /T0 erforderlich.
  /W    Fordert die Verwendung des System-Arbeitsbereichspeichers (System
        Workspace Buffer) für UMBPCI-"Shadow RAM"-DMA an. Wird /W wegge-
        lassen, legt XMGR seinen eigenen Puffer im unteren Speicherbe-
        reich an. /W darf nicht mit PC-DOS oder EDR-DOS verwendet werden!
        /W wird ignoriert, wenn UMBPCI nicht verwendet wird.
  /Z    Verschiebt Daten im Protected-Mode für XMGR oder UHDD in 8-KB-
        Blöcken (nicht 64-KB). /Z ist bei vielen EMM-Treibern oder im
        Real-Mode-Betrieb nicht erforderlich. Bei VCPI-/DPMI-/usw.-Trei-
        bern sollte ein PC getestet werden, um festzustellen, ob /Z er-
        forderlich ist. Fehlerhafte Schemata, die zu wenige Interrupts
        während der XMS-Verschiebung zulassen, sind möglicherweise
        immer noch im Einsatz!

Kommentar:

  Bei allen Schaltern in den Treibern kann der Schrägstrich durch einen
  Bindestrich ersetzt werden; Kleinbuchstaben können auf Wunsch verwendet
  werden.
  UHDD und UDVD2 sind Closed-Source DOS-Treiber für PCs mit einer CPU ab
  80386 (UHDD benötigt eine CPU ab 80486) und verwenden MS-DOS ab Version
  5.0 oder eine vollständig kompatible Variante.
  Die neuesten UHDD- und UDVD2-Treiber sind Open-Source-Gerätetreiber für
  PCs ab 80386 und verwenden FreeDOS. Bei XMGR und RDISK hingegen hängt
  es von der Versionsnummer ab, ob es sich um Open Source oder Closed
  Source handelt.
  Weitere Informationen und, falls Sie im Zweifel sind, finden Sie in
  der Datei "README.txt" in der zip-Datei "drivers.zip".

Beispiel:

  Hinweis: Es gibt neue Closed-Source-Treiber für UHDD.SYS (=XHDD.SYS)
  und UDVD2.SYS (=XDVD2.SYS), die möglicherweise andere Optionen bieten.
  Bitte verlassen Sie sich daher nicht auf die Optionen in den Bei-
  spielen!
  A: Ein kleines Real-Mode System, das nur XMS benötigt, kann zum Bei-
     spiel diese CONFIG.SYS/FDCONFIG.SYS Datei verwenden:
       ..
       ..
     DOS=HIGH
     DEVICE=C:\BIN\XMGR.SYS /Rnn              ;R falls es DOS "Spiele"
                                               brauchen
       ..
       ..  Int 13h Treiber, die von UHDD gecached sind, laden jetzt.
       ..
     DEVICE=C:\BIN\UHDD.SYS /S20 /H /O        ;Min. 20 MB empfohlen
     DEVICE=C:\BIN\UDVD2.SYS /D:BLURAY1 /H    ;Muß nach UHDD laden.
     DEVICE=C:\BIN\RDISK.COM /S5 /F           ;Optional. Falls nicht ver-
                                              ;wendet, kann UHDD/UDVD2
                                              ;/F ausgeben
       ..
       ..  Hier können weitere CONNFIG.SYS / FDCONFIG.SYS Befehle stehen.
       ..
  B: Real-Mode-Systeme mit UMBPCI und XMGR ab V3.70 benötigen den LOWDMA-
     Treiber nicht, da XMGR über einen I/O-Catcher für UMBPCI verfügt.
     Dieses Schema benötigt keinen Low-Memory-Speicher, wenn /W verwendet
     werden kann (MS-DOS usw.), bzw. nur 544 Low-Memory-Bytes ohne /W
     (PC-DOS usw.). XMGR und andere Treiber laden direkt in den UMBPCI-
     Shadow-RAM! Systeme, die mehrere Anbieter von High-Memory-Speicher
     zulassen (MS-DOS, PC-DOS usw.), können auch, wie unten gezeigt,
     einen EMM-Treiber laden, um den Bereich B000-B7FFh für Monochrome
     Graphics als 32 KB zusätzlichen High-Memory-Speicher abzubilden.
     Eine Beispieldatei für die CONFIG.SYS/FDCONFIG.SYS ist:
       ..
       ..
     DOS=HIGH,UMB
     DEVICE=C:\BIN\UMBPCI.SYS
     DEVICE=C:\BIN\XMGR.SYS /W /Rnn            ;W nur wenn erlaubt!
                                               ;R <= 15.5 MB mit JEMM!
     DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF X=C800-EFFF ...   ;Optional
       ..
       ..  Int 13h Treiber, die von UHDD gecached sind, laden jetzt
       ..  und können in den UMBPCI oberen Speicher geladen werden.
       ..
     DEVICEHIGH=C:\BIN\UHDD.SYS /S200 /H /O    ;Schneller 200 MB Cache
     DEVICEHIGH=C:\BIN\UDVD2.SYS /D:CDROM1 /H  ;Muß nach UHDD laden
     DEVICEHIGH=C:\BIN\RDISK.COM /S50 /F       ;Optional. Falls nicht
                                               ;verwendet, kann UHDD/
                                               ;UDVD2 /F ausgeben
       ..
       ..  Hier können weitere CONNFIG.SYS / FDCONFIG.SYS Befehle stehen.
       ..
  C: Ein Protected-Mode-System mit XMGR und einem "EMM"-Treiber kann
     XMGRs "boot" verwenden, wobei mindestens 304 Bytes an unterem Spei-
     cher für eine "XMS Handles"-Tabelle mit 24 Einträgen benötigt wer-
     den, zuzüglich eines niedrigen Speichers, den der "EMM"-Treiber
     möglicherweise benötigt. Eine CONFIG.SYS/FDCONFIG.SYS-Beispiel-
     datei sieht wie folgt aus:
       ..
       ..
     DOS=HIGH,UMB
     DEVICE=C:\BIN\XMGR.SYS /B /N24 /R15.5     ;24 Handelt XMGR "boot"
                                               ;R <= 15.5 MB mit JEMM!
     DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF ...
     DEVICEHIGH=C:\BIN\XMGR.SYS                ;Lädt die Laufzeit XMGR
       ..
       ..  Int 13h Treiber, die von UHDD gecached sind, laden jetzt
       ..  und können in den oberen Speicher geladen werden.
       ..
     DEVICEHIGH=C:\BIN\UHDD.SYS /S400 /H /O /P ;Optimal 400 MB Cache
     DEVICEHIGH=C:\BIN\UDVD2.SYS /D:MYDVD /H   ;Muß nach UHDD laden
     DEVICEHIGH=C:\BIN\RDISK.COM /S125 /F      ;Optional. Falls nicht
                                               ;verwendet, kann UHDD/
                                               ;UDVD2 /F ausgeben
       ..
       ..  Hier können weitere CONNFIG.SYS / FDCONFIG.SYS Befehle stehen.
       ..
  In jedem der obigen Beispiele muss UDVD2 nach UHDD geladen werden,
  damit UDVD2 UHDD im Speicher "findet" und für das CD/DVD-Datei-Caching
  aufruft.
  Benutzer, die RDISK mit einem bestimmten Laufwerksbuchstaben benötigen,
  können den Ladevorgang verzögern, bis die AUTOEXEC.BAT / FDAUTO.BAT
  ausgeführt wird.
  
  Falls /F oder /G auch für DOS-Spiele benötigt werden, muss RDISK diese
  von AUTOEXEC aus ausführen, da dieser Treiber dann als letzter geladen
  wird. Bei Verwendung von RDISK muss AUTOEXEC.BAT / FDAUTO.BAT außerdem
  Befehle ausführen, um alle RDISK-Programme und -Daten auf die RAM-Disk
  zu kopieren, da XMS-Speicher beim Herunterfahren des PCs verloren geht!
  Solche Kopien benötigen wenig Zeit.

  Wenn sowohl UHDD als auch RDISK ausgeführt werden, müssen Benutzer den
  XMS-Speicherbedarf der Treiber abwägen. UHDD kann, wie in obigem Bei-
  spiel C einen 400-MB-Cache einrichten, und RDISK kann 125 MB XMS für
  seine Programme, "schnellen" Datendateien und Compiler-Temp-Dateien
  anfordern. Diese Größen sollten für die meisten Systeme optimal sein,
  können aber nach Bedarf nach oben oder unten angepasst werden. Der
  verbleibende XMS-Speicher bleibt für andere Programme frei. Der Grund-
  plan sieht vor, dass RDISK Programme und Hochgeschwindigkeitsdateien
  "speichert", während UHDD "normale" Datendateien zwischenspeichert.
  Eine ausgewogene Nutzung des XMS-Speichers sorgt für ein SEHR schnelles
  DOS-System!




Siehe auch:

  autoexec.bat/fdauto.bat
  config.sys/fdconfig.sys
  device/devicehigh
  dos
 (fdxms)
 (fdxms286)
  himemx
  jemm386
  jemmex
  lastdrive
  rdisk
  rdiskon
  tdsk
  udvd2.sys
  uhdd.sys
  xmgr.sys

  Copyright © 2018 - 2022 Jack Ellis, Hilfeversion 2025 W. Spiegl.

  Diese Datei ist abgeleitet vom FreeDOS Spezifikationen-HOWTO.
  Vgl. auch die Datei H2Cpying bezüglich der Kopierbedingungen.