Befehl: cc
Das kleine CC.COM-Programm "Cache leeren" kann bei der Überprüfung von
Dateien helfen, die von UIDE und UHDD geschrieben wurden.
Durch die Eingabe von CC in einer Eingabeaufforderung wird der Cache
des Caching-Treibers geleert.
Die Daten auf der Festplatte (NICHT die Daten im Cache!) können dann
mit der ursprünglichen Ausgabe verglichen werden.
Beachten Sie, dass einige CompactFlash-Karten die Ausführung von CC
sehr langsam machen.
Syntax:
cc
Optionen:
- keine -
Kommentar:
Bei allen Schaltern in den Treibern kann der Schrägstrich durch einen
Bindestrich ersetzt werden; Kleinbuchstaben können auf Wunsch verwendet
werden.
Weitere Informationen 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.
..
cc ;Leert den Cache von UHDD
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.
..
cc ;Leert den Cache von UHDD
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.
..
cc ;Leert den Cache von UHDD
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
uide.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.