Nachdem wir beim letzten Mal die ersten Spiele auf dem Sysline-PC zum Laufen gebracht haben, wird es Zeit, diesen mit ein paar weiten DOS-Games zu bestücken! 😉
Bevor wir die letzten paar Titel der „Zehn Adventures“-CD angehen, möchte ich noch ein paar kleinere Spiele, welche ich auf Diskette besitze, installieren. Papa braucht ein Erfolgserlebnis! 😛 Den Anfang macht „Silverball“, eine 1993 erschienene Flipper-Simulation.
Dank eigenem Setup-Programm ist das Spiel schnell installiert. Anschließend müssen wir in einem Konfigurationsmenü noch die richtige Soundkarte auswählen. Unsere Yamaha SoundEdge-Karte hat einen eigenen Betriebsmodus (OPL4), welcher allerdings nur von ein paar Spielen unterstützt wird. Gut, dass die Karte auch den wesentlich populäreren SoundBlaster (Pro)-Standard unterstützt! 🙂
Not so fun Fact: Auf dem Foto ist die IRQ-Angabe falsch. Ich gehe davon aus, dass das Bild entstanden ist, bevor ich richtig „durchgeblickt“ habe. Die Soundkarte wurde für IRQ 5 konfiguriert und genau das müssen wir auch hier angeben, sonst bleiben die PC-Boxen stumm! 😉
Doch was ist das? Beim Start des Spiels bekommen wir eine Fehlermeldung. Auweia – das leidige Thema Hauptspeicher… Ich höre schon die Rufe aus der ersten Reihe: Aber retrololo, was will denn das Spiel mit den 544kB? Wir haben doch eigentlich 8MB Arbeitsspeicher in unserem Computer verbaut?! Tja, beim letzten Mal hatte ich es ja bereits angekündigt: „DOS und seine Tücken“! 😛
Alleine über die Art und Weise, wie MS-DOS RAM (also Arbeitsspeicher) in verschiedene Bereiche aufteilt und verwaltet, könnte man vermutlich zehn Blogbeiträge schreiben. Für Freaks ist das ein interessantes Thema, da man auf zahlreiche Einstellungen Einfluss nehmen kann, um die Verwaltung des Speichers zu optimieren. Ich werde versuchen, euch damit nicht allzu sehr zu langweilen. 😀
Vielleicht nur so viel zum Verständnis: Einfach gesagt gibt es einen konventionellen Bereich (0-640kB), welcher von den meisten DOS-Anwendungen sowie dem Betriebssystem selbst verwendet wird. Dann gibt es einen 384kB große UMA (Upper Memory Area), welche für Zusatzhardware (Grafikkarten, SCSI-Controller, etc.) sowie das BIOS reserviert ist. Ab der 1MB-Grenze folgt der Extended Memory (XMS), welcher letztendlich den restlichen verfügbaren RAM bis zur physikalisch verbauten Speichergrenze (bei uns 8MB) abbildet.
Fun Fact: Diese etwas merkwürdige Aufteilung kommt aus Zeiten, in denen einfach nicht mehr als 1MB Arbeitsspeicher von den damaligen Prozessoren (z.B. der 8088-CPU bei den ersten IBM-PCs im Jahre 1981) adressiert werden konnte. Da ein Großteil der DOS-Software aus dieser Zeit stammt, ist es nicht verwunderlich, dass Programme sich an diese Limitierung halten mussten und dementsprechend so programmiert wurden, dass sie innerhalb des 640kB-Limits laufen.
Auf einem sauber, bzw. gut konfigurierten MS-DOS-System sollte der konventionelle Bereich im Arbeitsspeicher (also unter 640kB) so frei wie möglich gehalten werden, um den Anwendungsprogrammen möglichst viel Spielraum zu geben. Mit Hilfe des Befehls „mem“ lässt sich anzeigen, wie viel Speicher im jeweiligen Speicherbereich zur Verfügung steht:
Fun Fact: Die ganzen Dienste oder zentralen Anwendungen werden oft TSR-Programme (terminate and stay resident) genannt. Meistens sind das Treiber, welche im Hintergrund immer geladen sein müssen, damit der Computer und seine Peripheriegeräte (z.B. Maus oder CD-Laufwerk) funktionieren.
Ganz klar – laut der Auflistung haben wir ca. 452kB (463.040 Byte) zur Verfügung, Silverball möchte aber 544kB verwenden. Einfach gesagt – wir können das Spiel nicht laufen lassen, weil zu wenig konventioneller Speicher zur Verfügung steht. Ok – und wie räumen wir jetzt Arbeitsspeicher frei? Dafür müssen wir uns etwas genauer mit den System-Konfigurationsdateien AUTOEXEC.BAT und CONFIG.SYS beschäftigen. Den Anfang macht die CONFIG.SYS, in welcher beim Start des Computers zu ladende Gerätetreiber definiert werden. Anhand dieser Parameter wird letztendlich auch die Speichernutzung bestimmt. Mehr Treiber und Programme bedeuten weniger freien Platz im RAM.
Unser Ziel ist es, so viele Komponenten (Programme, Treiber sowie Teile des Betriebssystems selbst) wie nur irgendwie möglich, in den XMS-Bereich zu laden. Einige zentrale Treiber müssen im konventionellen Bereich bleiben, aber tatsächlich lassen sich sogar einige Betriebssystemteile aus dem 640k-Bereich verlagern. Dafür wird der Parameter DOS=HIGH benötigt. Leider ist der in unserem Fall schon gesetzt. Damit versucht MS-DOS, Teile von sich selbst in die High Memory Area (HMA) zu laden. Die HMA befindet sich im ersten Teil (die ersten 65.520 Bytes) des XMS.
Um noch etwas mehr konventionellen Speicher freizukratzen, können wir den Parameter „UMB“ hinzufügen. Damit wird festgelegt, dass MS-DOS auch Adressbereiche in der UMA verwendet. Zur Erinnerung: Der UMA-Bereich sind die 384kB oberhalb der 640kB, welche für Zusatzhardware und BIOS reserviert sind. Tatsächlich wird aber ein Großteil dieses Bereichs in den seltensten Fällen komplett verwendet, meist bleiben zwischen 128 und 256kB ungenutzt. Ganz wichtig: In diesen 386kB befindet sich kein Arbeitsspeicher, sondern lediglich der reservierte Adressbereich für die Zusatzhardware. Programme (und so auch DOS selbst) können zwar auf diese Adressen zugreifen, sie dann aber eben nicht als Arbeitsspeicher für die Verarbeitung nutzen. Hm, das ist ja blöd!
Das stimmt, doch es gibt eine Abhilfe. Um den UMA-Bereich für DOS und Anwendungsprogramme verwendbar zu machen, benötigen wir einen „Memory Manager“. Es gibt wie immer mehrere Alternativen, ich verwende ein beim Betriebssystem mitgeliefertes Systemprogramm namens „EMM386.EXE“. Und wie funktioniert das? Letztendlich ordnet dieses Tool Adressbereichen in der UMA reale Speicherbereiche oberhalb der 1MB-Grenze (im XMS-Bereich) zu. Mit diesem Trick können wir DOS die eigentlich nicht verwendbaren UMA-Bereiche in Form von UMB-Speicherblöcken zugänglich machen. Dafür muss lediglich der Speichermanager als DEVICE geladen werden:
Not so fun Fact: Damit EMM386.EXE funktioniert wird zusätzlich noch der Gerätetreiber „HIMEM.SYS“ benötigt, welcher koordiniert und sicherstellt, dass keine Anwendungen oder Gerätetreiber denselben Speicher gleichzeitig verwenden. Ja ja, DOS und seine Tücken… 😉
Anschließend können die Gerätetreiber (z.B. für die Maus, das CD-Laufwerk oder) über den Befehl „DEVICEHIGH“ (anstatt DEVICE) in die oberen Speicherbereiche geladen werden:
Ob unsere „Aufräumaktion“ erfolgreich war? Das lässt sich (nach einem Neustart des PCs) nur mit Hilfe des Befehls „mem“ herausfinden. Es scheint so, als hätte das „Umladen“ der Systemkomponenten und Gerätetreiber tatsächlich etwas gebracht, denn tatsächlich stehen uns nun ca. 552kB konventioneller Speicher zur Verfügung – very nice! 🙂 Fassen wir also zusammen: Der EMM ist ein verdammt wichtiges Tool, welches benötigt wird, damit wir überhaupt auf höhere Speicherbereiche (in unserem Fall die 8MB RAM) zugreifen zu können.
Fun Fact: Ich weiß – das alles klang jetzt sehr theoretisch und ich hatte ja versprochen, euch nicht zu sehr mit dem Speicherverwaltungs-Thema zu langweilen. Daran will ich mich halten und darum lass ich es an der Stelle auch gut sein. Auch wenn ihr mir das nicht glaubt, bzw. glauben wollt – das alles war jetzt noch recht oberflächlich und letztendlich nur ein extrem knapper Einstieg in die Thematik. Was soll ich sagen, so ein Betriebssystem ist eben kompliziert! 😉
Na, damit sollte jetzt doch auch „Silverball“ funktionieren, oder? YES – das Spiel startet und endlich können wir „flippern“! 🙂
Nachdem das so gut geklappt hat, möchte ich mit „Micro Machines“ gleich einen weiteren DOS-Klassiker auf unseren Rechner aufspielen. Mit dem auf der Diskette befindlichen Installationsprogramm ist das ein Klacks und diesmal startet das Spiel auf Anhieb ohne Probleme. Zur Abwechslung begrüßt uns aber mal wieder eine Kopierschutzabfrage. Klar, was sonst? 😀
Angeblich befindet sich in der Box zum Spiel eine sog. „Code Card“. Hm, die Box habe ich nicht mehr, aber dafür das Handbuch! Und wie es der Zufall will, fällt mir doch tatsächlich eine schwarze, kaum lesbare Karte entgegen. Auf dieser müssen wir das passende Symbol in Zeile 11 Spalte D heraussuchen, um es in einer grauen Tabelle einzugeben. Aha – ein fettes Ausrufezeichen also! 😀
Not so fun Fact: Die Code Card wurde mit voller Absicht auf schwarz beschichtetes (und somit nur extrem schwer lesbares) Papier gedruckt, um nicht so einfach mit einem Fotokopierer kopiert werden zu können. Die Spielentwickler (Codemasters) wussten sich gut gegen Raubkopierer zu wehren! 😛
Könnt ihr das glauben? Dieser Kopierschutz, ist so penetrant und frägt uns sogar nach einem weiteren Symbol, weil es könnte ja nur Glück gewesen sein, dass wir das richtige Symbol (auch ohne Code Card) ausgewählt haben. So ein Quatsch, welcher Geisteskranke würde denn auf gut Glück alle der insgesamt 64 Symbole immer wieder durchprobieren, nur um ein Videospiel zu starten? Wozu braucht es die zweite Abfrage? Unfassbar, die Entwickler waren wohl extrem misstrauisch…
Aber egal – irgendwann ist auch das zweite Symbol gefunden und wir können endlich mit den Mini-Flitzern durch die Gegend heizen. Nostalgie pur! 🙂
Not so fun Fact: Wenn ich mich recht erinnere, musste man auch hier in einem Konfigurationsmenü den Sound von „PC Speaker“ auf „Blaster“ abändern. Ganz sicher bin ich mir nicht mehr und spätestens nach 2 Runden Micro Machines habe ich das auch vergessen (oder verdrängt)? 😉
Ein weiteres Spiel, welches ich unbedingt zum Laufen bekommen möchte ist „Electro Body“. Auf dem DTK-Computer in Artikel 238 haben wir es ja bereits auf einem monochromen Bildschirm zum Laufen bekommen, aber mich würde interessieren wie das Spiel auf einem Farbdisplay aussieht! 😉
Der Installationsvorgang ist kinderleicht, denn tatsächlich müssen wir nur die Dateien von der Diskette kopieren und im Setup-Menü den Sound Blaster auswählen. Das ist ja fast zu einfach! 😛
Soviel dazu – beim Start holt uns eine Fehlermeldung auf den Boden der Tatsachen zurück. Nicht schon wieder der Arbeitsspeicher! Um ehrlich zu sein, hatte ich schon fast die Befürchtung bzw. das Gefühl, dass wir nicht gründlich genug entrümpelt haben. Gute 566kB (580.000 Bytes) werden benötigt, das heißt wir müssen noch mal an die Systemeinstellungen ran, um weitere 14kB freizuschaufeln. Mist! 🙁
Über den Befehl „mem /c“ lässt sich etwas genauer anzeigen, wer denn die Übeltäter sind, die den ganzen konventionellen Speicher fressen. Spontan fallen mir da der Maustreiber und Smartdrive (eine Art „Zwischenspeicher“ (auch „Cache“ genannt) für Festplattenzugriffe im Arbeitsspeicher) auf:
Um den „Bösewichten“ das Handwerk zu legen, machen wir diesmal einen Abstecher in die „AUTOEXEC.BAT“. Darin werden neben Angaben zur Lokalisierung des Systems (also so Dinge wie die Systemsprache oder das Tastaturlayout) auch Anwendungen und Treiber gestartet:
Smartdrive habe ich ganz deaktiviert (rem vor der entsprechenden Zeile), von der Software halte ich sowieso nicht viel. Den Maustreiber können wir natürlich nicht deaktivieren, sonst würde die Maus nicht mehr funktionieren. Zumindest können wir den Treiber aber dank EMM386 Speichermanager mit Hilfe des Befehls „LOADHIGH“ (LH) in einen höheren Speicherbereich laden. Bei der Gelegenheit macht es Sinn, auch alle weiteren verlagerbaren Programme auf „LH“ anzupassen.
Not so fun Fact: Leider muss man bei jedem einzelnen Programm genau (ggf. in irgendwelchen Dokumentationen oder Handbüchern) hinsehen, ob es sich verlagern lässt oder zwingend im konventionellen Bereich laufen muss. Normalerweise sollte das für fast alle Programme funktionieren, aber Ausnahmen bestätigen die Regel… 🙁
Neues Spiel, neues Glück – wie viel RAM haben wir jetzt frei? Boah, das hat sich ja echt gelohnt! Laut „mem“ haben wir jetzt fast 584kB im konventionellen Bereich frei. Das hört sich echt gut an! 🙂
Fun Fact: Zugegeben – um auf den Wert zu kommen, habe ich in der Zwischenzeit auch noch ein paar weitere Optimierungsmaßnahmen in der CONFIG.SYS vorgenommen. Was das alles war, kann ich euch im Detail gar nicht mehr so genau sagen. Seht es mir nach, es ist oft schwer, im Nachhinein sich an alle durchgeführten Änderungen zu erinnern. Ich werde auch älter! 😛
Und prompt lässt sich auch Electro Body problemlos starten und wir können endlich ein paar Roboter abballern. Den obligatorischen Kopierschutz per Wortabfrage aus dem Handbuch kennen wir ja mittlerweile auch zu Genüge! 😀
Nanu? Wer hat an der Uhr gedreht, ist es wirklich schon so spät? Irgendwie habe ich den Eindruck, dass wir heute nicht viel geschafft haben. Und das, obwohl die Installationen und das Zusammenfassen der Bilder sehr viel Zeit gekostet haben. Sowas aber auch! Egal – beim nächsten Mal geht’s weiter. Ich habe da noch ein paar Spiele, die ich gerne installieren würde! 😉
In diesem Sinne – bis die Tage, ciao!