EMS-Speicher

    Hallo zusammen.
    Zur Zeit lasse ich mein GEOS in der DOSEmu2 mit FDPP und comcom32 mit XMS/UMB- und EMS-Speicher laufen. Zu diesem Thema habe ich hier im Forum einige (zum Teil englischsprachige) Beiträge gelesen, aber so wirklich schlau bin ich nicht geworden, was dieses Thema angeht.
    Nun habe ich bemerkt, das GEOS in der jetzigen Konfiguration beim Herunterfahren nicht mehr hängen bleibt, was bei der Konfiguration nur mit XMS/UMB-Speicher häufiger der Fall war. Zwar habe ich mit der jetzigen Konfiguration weniger freien DOS-Arbeitsspeicher zur Verfügung, aber GEOS scheint mir stabiler beim Herunterfahren und einen signifikanten Unterschied bei der Arbeitsgeschwindigkeit habe ich auch noch nicht festgestellt.
    Das bringt mich zu der Frage, ob es sinnvoll ist, auf einen nicht unerheblichen Teil des DOS-Arbeitsspeichers unter 1 MB zu verzichten? (Scheint erst mal so...) Und... Wofür braucht GEOS eigentlich den EMS-Speicher?

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Hallo Achim

    Ich habe mit dem Herunterfahren unter DOSEMU(2) nie Probleme gehabt. Erinnere mich nur an Windows, wo man die CTRL-Taste jeweils drücken musste...

    Also, ich verstehe das so:

    GEOS verwendet für direkt adressierbaren Speicher (HEAP) grundsätzlich den freien Platz < 1MB. Sprich Konventioneller und UMB. Ob HMA (die ersten 64kB über 1MB) auch verwendet wird, weiss ich nicht.

    Wenn nun der Speicher im HEAP nicht mehr genügt, dann muss GEOS Teile davon mittels eines Swap-Treibers auslagern.

    Hierzu gibt es folgernde Swap-Treiber:
    - XMS
    - EMS
    - Swapfile

    Alle diese Swap-Treiber können ausgelagerte Speicherbereiche aufnehmen. Die Grenze liegt glaube ich bei 32MB pro Swap-Treiber.

    Aber Achtung:
    Jeder Swap-Treiber benötigt selber Speicher im HEAP. Denn es muss eine Tabelle führen, wo was ausgelagert wurde. Wenn Du alle Swap-Treiber mit voller Grösse lädst, werden diese Tabellen entsprechend gross und es bleibt weniger Platz für Deine Programme im HEAP. Es kann gut sein, dass Dein System dann instabiler läuft, obwohl Du total viel Speicher zum Auslagern hast. Liegt eben daran, dass gewisse Speicherbereiche nicht ausgelagert werden können und im HEAP verbleiben müssen.

    Jeder Treiber ist dann auch noch unterschiedlich schnell beim ein- und auslagern. Grundsätzlich: Je schneller, umso besser. Eine Swap-Datei in einer RAM-Disk kann super schnell sein im Vergleich zu einer Festplatte oder auch SSD. Bin der Meinung, EMS und XMS unterscheiden sich noch bezüglich Wechsel zwischen Real und Protected Mode. Wenn man immer im Real Mode bleiben kann (XMS?EMS), ist das oft performanter als jeweils in den Protected Mode und zurück zu wechseln (EMS?XMS). Solche Wechsel ergeben sicher einen Context-Switch, was ein Sichern und Zurückholen der CPU-Register bedeutet und Zeit kostet. Dafür kann man im Protected Mode effizienter Speicher schieben.

    So, habe nun mein esoterisches Halbwissen hier mal raus gelassen. Freue mich um Richtigstellungen und Ergänzungen. Das Thema wird wahrscheinlich weiterhin immer wieder einmal aufpoppen.

    Gruss
    Andreas

    Einmal editiert, zuletzt von bolle732 (22. März 2021 um 10:07)

    Bei Hardware-Karten war EMS definitiv besser und auf alten Prozessoren (286er) die einzige? Wahl. Es soll effizienter als XMS sein, weil einfacher bei der Verwendung und so wie es aussieht ohne Umschaltung Real / PM.

    https://de.wikipedia.org/wiki/Expanded_Memory_Specification

    XMS soll im Protected-Mode arbeiten, sprich es muss zwischen Real und PM umschalten. Bei Wikipedia scheint es relativ gut beschrieben:

    https://de.wikipedia.org/wiki/Extended_Memory_Specification

    Schlussendlich glaube ich aber, dass heute in einer virtuellen DOS-Umgebung (DOSBOX, DOSEMU2, QEMU etc.) alles etwas anders aussieht. Das Host-OS ist ja immer im PM und es kommt auf die Emulation der Speicher-Zugriffe und/oder die Treiber an. Für reine DOS-Installationen aber kann es doch noch den entscheidenden Unterschied machen (z.B. die Igels von Thomas).

    Klar, man könnte ein Test-Tool schreiben und den Zugriff auf den Arbeits-Speicher messen. Hatte mir selber schon einmal dazu Gedanken gemacht. Leider habe ich noch keinen Weg gesehen, wie man auf relativ einfache Weise in den Speicher-Bereich eines spezifischen Swap-Treibers schreiben und wieder daraus lesen kann. Die Grundidee war ja eh, den Programmen gegenüber den Speicherzugriff Transparent zu machen.