Alone In The Dark 1 und 2

Vor 30 Jahren hatte mein Vater preisgünstig die von Infogrames entwickelten, sowie veröffentlichten Action-Adventures Alone in the Dark von 1992, welches als Begründer des Untergenres Survival Horror gilt, und Alone in the Dark 2 von 1993 erworben. Obwohl der Computer für die Spiele mehr als genug Arbeitsspeicher besaß, bekam er die Spiele nicht gestartet. Das lag daran, dass unter DOS nicht mehr ausreichend konventioneller Speicher unterhalb der ersten 640 Kibibyte war und grundsätzlich Expanded Memory benötigte. Das verstand mein Vater aber nicht, und dadurch leider auch ich noch nicht.
Vor wenigen Wochen habe ich mal wieder die von einem früheren Mitbewohner individuell zusammengestellte, gebrannte CD mit einer Sammlung von alten DOS-Spielen durchstöbert und bin wieder auf die beiden ersten der inzwischen um einige Spiele mehr umfassenden Alone In The Dark Reihe gestoßen, und habe sie mal auf einem neu zusammengestellten DOS-PC mal durchgespielt.

Die Spiele sind recht realistisch. So gibt es keine Auswahl an Schwierigkeitsgraden, sondern nur einen. Und der ist recht herausforderungsvoll. Es gibt auch nur ein Leben. Das bedeutet, dass es lohnt, sehr viel zwischenzuspeichern. Wird mit einer Schusswaffe abgefeuert – und davon gibt es nur die Auswahl zwischen einem Revolver, einer Schrotflinte, sowie einem Thompson-Maschinengewehr im zweiten Teil – so erfährt die Spielfigur einen entsprechend heftigen, anuimierten Rückstoß. Anders als in den meisten Ego-Shootern und Action-Spielen gibt es nur sehr wenig Munition und Erste-Hilfe-Kästen bei den Alone In The Dark Titeln. Und diese sind bereits relativ zu Beginn der Spiele zu finden. Man muss sich die vorhandenen Ressourcen also wirklich sehr gut einteilen. Eine sinnvolle Eigenschaft, die es nur im ersten der von mir gespielten zwei frühsten Alone In The Dark Titel gibt, ist die begrenzte Kapazität des Inventars. Man kann nicht alles mit sich herumtragen. Irgendwann ist es voll. Und ein voller Kochtopf ist sperriger und schwerer, als Munition, mehrere Notizen und eine Handvoll Pfeile. Einen Umstand, auf dem man im zweiten Teil nicht mehr achten musste, denn es passte wirklich alles hinein, was man im Spielverlauf so fand.
Von den ersten beiden Alone In The Dark Spielen hat mir – nicht zuletzt wegen der begrenzten Inventarkapazität und der etwas übersichtlichen Story – der erste Teil am besten gefallen.
Unabhängig davon ist das zweite Spiel der Reihe immer an derselben Stelle abgestürzt. Bedauerlicherweise war der Fehler auch auf anderen Systemen und auch in Emulatoren reproduzierbar. Das spricht deutlich für eine fehlerhafte Version, die ich habe. So hatte ich bisher keine Möglichkeit, Alone In The Dark 2 auch bis zum Ende zu spielen.

Zu guter Letzt sei noch die lustige Kreatur, die einem als Gegner im späteren Spielverlauf des ersten Alone In The Dark Spiels begegnet, erwähnt. Eine Mischung aus Ratte und Spinne.

Eine Kreatur aus einer Spinne und einer Ratte aus dem Spiel 'Alone In The Dark' von 1992.
Kreatur aus einer Spinne und einer Ratte

Links:

Catacomb 3-D

Nach der Veröffentlichung von Commander Keen 4 entwickelte id Software in den Monaten Oktober und November des Jahres 1991 Catacomb 3-D zeitgleich mit Commander Keen 6 und 5. Catacomb 3-D war der technologisch ausgereiftere Nachfolger von Hovertank One und führte das Konzept der dreidimensionalen Darstellung der Spielerhand fort und führte damit verbundenes Texture Mapping ein. Somit war Catacomb 3-D das erste First-Person-Shoter mit Texture Mapping. Anders als der sehr erfolgreichen Commander Keen Reihe wurde das Spiel nicht als Shareware, sonders direkt als Vollversion vertrieben. Und obwohl Catacomb 3-D auch nur einen Bruchteil durch den Verkauf einbrachte, wurde mit der Entwicklung von Commander Keen 7 die finanziell erfolgreiche Reihe des Side-Scrollers eingestellt, da id Software die Zukunft in First-Person-Shoter sah. Eine verbesserte Version dieser Technologie wurde später für das erfolgreichere Wolfenstein 3D verwendet, dem Urvater der First-Person-Shoter.

Auch für mich war Wolfenstein 3D in den frühen 1990er Jahren der Einstieg in das Genre der First-Person-Shoter, aber erst vor wenigen Wochen habe ich den technologischen Grundsteinleger Catacomb 3-D gespielt. Was mir dabei positiv auffiel, dass es einen Kompass gibt, jedes Level einen eigenen Namen, sowie in den Level auch Räume oder ganze Bereiche Namen haben. Etwas, was ich mir jetzt in der Rückschau auch für Wolfenstein 3D gewünscht hätte. Vielleicht hätte es die Navigation durch die Labyrinthartigen Levels von Wolfenstein 3D sowie dessen Sequel Spear of Destiny etwas geholfen.
Anders als alle Nachfolger das Genre in den 1990er Jahren ist die Abfolge der Levels bei Catacomb 3-D an einigen Stellen deutlich nicht linearer und es gilt durch das Sammeln von Schriftrollen herauszufinden, an welcher Stelle der Spieler zu den letzten der 20 gelangt. Ein deutlicher Hinweis, dass die Handlung ihren Ursprung in den Rollenspielen hat.

Wie bei vielen anderen Spiele war es auch beim Durchspielen von Catacomb 3-D mein Anspruch, möglichst alle Levels zu absolvieren. Bedauerlicherweise gibt es aber abgesehen von YouTube Walkthroughs keine ausführliche Lösungsbeschreibung oder vollständige Übersicht der Karten aller Levels im Internet. Ohne dass ich jetzt eine Lösungsbeschreibung verfasse, möchte ich aber dennoch die optimale Abfolge der Levels aufzeigen, um sie alle nicht unnötig mehr als einmal durchlaufen zu müssen, sowie das Einsammeln aller Schriftrollen.

1 → 2 → 3, via Secret → 8 → Warp via Cheat nach 4 → 5 → 6 → 7 → 9 → 10 → 11 → 14 → 15 → 16 → 12 → 13 → 9 → 12 → 13 → 17 → 18 → 19 → 20

Da zumindest ich keinen Ausgang aus Level 8 nach Level 4 gefunden habe, musste ich mit einem Cheat etwas schummeln. Dazu ist die Tastenkombination F10 + W zu drücken und mit der 4 das Level 4 zu wählen.

Der Ausgang nach Level 9 ist auch Über ein Secret von Level 1 aus möglich. Es fehlt dann aber der Durchlauf der Levels 2 bis 8.
Wer keinen Cheat anwenden möchte, nutzt in Level 3 den Ausgang nach Level 4. Es entgeht einem lediglich Level 8.

Zum Schluss möchte ich noch die 17-minütige Dokumentation Making Catacomb 3-D des Spieleentwicklers sowie Gründer von id Software John Romero zur Entstehunsgeschichte von Catacomb 3-D auf YouTube allen Interessierten ans Herz legen.

Links:

Embeddable Linux Kernel Subset auf dem NuXT

Da ich mich schon länger mit zwei PCs der 16 Bit x86 XT-Klasse beschäftige, – über das originale Schätzchen von IBM hatte ich aber bisher noch gar nicht geschrieben – kam ein Kollege vor ein paar Wochen mit dem Link zum ‚Embeddable Linux Kernel Subset‘ (kurz: ELKS) auf mich zu. ELKS ist relativ kurz gesagt in Projekt, das einen frühen Fork des Linux-Betriebssystems für Systeme mit Intel IA16-Architektur (16-Bit-Prozessoren: 8086, 8088, 80188, 80186, 80286, NEC V20, V30 und kompatible) bereitstellt. in Projekt, das einen frühen Fork des Linux-Betriebssystems für Systeme mit Intel IA16-Architektur (16-Bit-Prozessoren: 8086, 8088, 80188, 80186, 80286, NEC V20, V30 und kompatible) bereitstellt. Unterstützt werden Netzwerk, Grafik, ia16-elf-gcc, OpenWatcom C und ein eigener nativer C-Compiler, sowie die Installation auf Festplatten mit den FAT-Dateisystemen MINIX und MSDOS. Die Bitte war, auch auf der historischen Hardware-Klasse neben dem üblichen DOS auch ein für die Zeit der Architektur unüblich ein Linux zu betreiben.
Schnell habe ich mir von der GitHub-Projektseite das heruntergeladene, 1,44 MB große Floppy-Image auf eine Diskette kopiert, um es auf meinem NuXT mit NEC V20 Prozessor und 640 KiB RAM starten zu können. Die Installation auf ein durch eine CompactFlash Karte dargestelltes Festplattenlaufwerk hatte ich nicht mehr hinbekommen. Da auch bereits im Gegensatz zu den 360 und 720 KB Disketten-Images das vollständige Subset auf der 1,44 MB Variante Platz findet und die Diskette erfolgreich gebootet war, war somit die Machbarkeitsstudie mit dem derzeitigen ELKS in Version 0.8.1 erfolgreich abgeschlossen.

Jetzt am Wochenende hatte mich der Ehrgeiz aber erneut gepackt, und ich wollte es nicht unversucht lassen. Direkt bei dem erneuten ersten Versuch hat es geklappt und ich konnte das ELKS von der echten, 1,44 MB großen Diskette auf eine übrige 256 Megabyte große CompactFlash Karte installieren. Allerdings empfand ich zum einen die Formatierung der CF-Karte mit dem Minix-Dateisystem als nicht optimal, zum anderen hielt ich die 256 MB Karte grundlegend für zu groß. Irgendwo hatte ich schließlich noch eine ungenutzte 64 MB Karte, die mir in Bezug auf die Speichergröße für die Rechenleistung der XTs geeigneter erschien. Nur mit dem Versuch, die Installation von Diskette auf CF-Karte in Vernünftig durchzuführen, wurde zum Drama!:
Ich bekam sowohl beim Ausführen der Programme zur Bearbeitung und Formatierung des Zielmediums, als auch beim Kopieren der einzelnen Dateien des Subsets von Quell- auf Zielmedium Lese- und Schreibfehler. Ist die ganze Blockstruktur so empfindlich für Disketten? Ich habe also unterschiedliche 3,5″ HDD Disketten, anderer USB-Diskettenlaufwerke für meinen Internet-fähigen Computer, sowie ein anderes internes Diskettenlaufwerk für den XT ausprobiert, aber ohne Besserung. Auch das Ausprobieren der Images auf FAT32- statt der Minix Dateisystembasis ergab keinen Unterschied. Die Alternative war dann das stupide Kopieren der vorgefertigten Harddisk Images von der Projekt-Download-Seite. Das Problem dabei: sowohl die Images mit MBR, als auch ohne, ließen sich nicht booten, da das Boot-Flag in der Image-Geometrie fehlte. Nach stundenlangem Probieren hatte ich schließlich erst wieder Erfolg, nach dem ich mir unter einem Windows Computer einen USB-Stick für mehrere Floppy-Images erstellt und das entsprechende 1,44 MB Image hineingeladen hatte. Dies bedeutete aber auch, dass ich den NuXT einen Floppy-Emulator nur für diesen Zweck einbauen musste. Nur für den einen Zweck, das ELKS von einer „Diskette“ auf eine CF-Karte zu installieren, bedeutet dies sehr viel Bastelei. Ausführen der Festplattenprogramme und Kopieren der Dateien von USB-Stick verliefen dann ohne nennenswerten Lese- und Schreibfehlern.

Quelle: https://frankfurt.social/@sommteck/115091257215484879 (eigner Mastodon Feed)
ELKS Installation mit NuXT Versuchsaufbau

Ich werde mal abwarten, bis eine neuere Version als die aktuelle 0.8.1 zur Verfügung steht. Vielleicht wurden dann die vorgefertigten Harddisk Images mit einem Boot-Flag nachgebessert. Weitere Konfiguration, sowie Optimierungen werde ich mal separat behandeln. Hoffentlich dann mit den Eindrücken des eigenen IBM XT PCs. Hier nur die Kurzanleitung zur Installation von Floppy auf eine 64 Megabyte CompactFlash-Karte.

fdisk /dev/hda
  • n → neue Partition /dev/hda1 über das ganze Speichermedium
  • b → bootable Flag setzen
  • w → schreiben, dann q zum Verlassen
mkfs /dev/hda1 60000     # MINIX v1 erstellen
sys -M /dev/hda1         # ELKS + Bootloader installieren
echo "##" > /bootopts
echo "root=hda1" >> /bootopts
sync; shutdown -r

Links:

MS-DOS Speicheroptimierung auf dem Monotech NuXT Turbo PC

Vor gut zwei Jahren hatte ich meinen Monotech NuXT Turbo PC vorgestellt. Ein Design für einen Turbo XT aus dem Jahr 2019 nach aktueller ATX-Spezifikation mit wahlweise Intel 8088 oder NEC V20 CPU, Intel 8087 FPU, eingebauten XT-IDE Controller, und und und! Ausgestattet ist es aber auch mit 832 KiB RAM aufgeteilt auf zwei ICs in DIP-Gehäuse.

englischdeutsch
UMAUpper Memory Areaoberer Speicherbereich
HMAHigh Memory Areahoher Speicherbereich
Vollständige Nutzung des konventionellen Speichers

In der Zeit bis jetzt hatte ich den PC unter MS-DOS ausschließlich mit den 640 KiB konventionellen Speicher genutzt, was bedeutete, dass das gesamte DOS-Betriebssystem, sowie alle aktiven Treiber nur diesen verwendeten und im Zweifel für Anwendungsprogramme, beziehungsweise für Spiele nicht mehr ausreichend RAM zur Verfügung steht. Jetzt habe ich mich aber mal hingesetzt und den noch zur Verfügung stehenden, sogenannten Upper Memory Area (kurz UMA, deutsch: ‚oberen Speicherbereich‘) aktiviert, konfiguriert, sowie versucht zu optimieren, damit mehr konventioneller Speicher für Programme und Spiele zur Verfügung steht. Schließlich hat Monotech Vintage PCs auf der mit MS-DOS vorinstallierten, sowie mitgelieferten CompactFlash-Karte auch gleich die passenden Treiber und Tools wie USE!UMB und DOSMAX beigefügt.
Abzüglich der 640 KiB konventionellen Speicher stehen mir also von den physischen 832 KiB grundsätzlich noch 192 KiB Upper Memory Area zur Verfügung. Dieser ist wiederum in sechs 32 KiB große Upper Memory Blocks (UMB) aufgeteilt. Über den auf dem NuXT Mainboard aufgelöteten 6-fach Dip-Switch lassen sich die einzelnen Blöcke stufenweise aktivieren. Allerdings muss ich hier beachten, dass es Erweiterungskarten für den ISA-Bus gibt, die auch den oberen Speicherbereich nutzen. Das wären neben Speichererweiterungskarten, Netzwerkkarten mit oder ohne Boot ROM, Karten mit eigenen Option ROMs wie HDD-/FDD-Controller auch EGA und VGA Grafikkarten wie die auch bei Monotech Vintage PCs mitgelieferte ‚Onboard PC/104 VGA Card‘. Das heißt, dass ich den ersten 32 KiB Block UMB nicht aktivieren kann, da es sonst zu einem Konflikt kommt und ich keine Grafikausgabe bekomme. So bleiben mir also effektiv nur fünf Blöcke mit zusammen 160 KiB als oberen Speicherbereich. Wirklich mehr als genug um die ersten 640 KiB konventionellen Speicher zu entlasten.
Dank der kurzen Anleitung im ‚NuXT Turbo PC‘ Handbuch, den originalen Dateiversionen der autoexec.bat und config.ays, sowie etwas Selbstoptimierung habe ich den verfügbaren Speicher für ausführbare Programme nun von 548 auf 625 KiB erhöht. Dies habe ich erreicht, in dem ich erst einmal überhaupt mit dem USE!UMBS.SYS Treiber den oberen Speicherbereich für MS-DOS zur Verfügung gestellt habe. In diesen wurden dann bereits einige Teile vom MS-DOS Betriebssystem, der Teriber für den USB2ISA Adapter und der Maus SYS-Treiber verschoben.

Systemteile und Treiber wurden in hohen und oberen Speicherbereich verlagert

Neben dem oberen Speicherbereich (UMA) kann in der config.sys auch noch der hohe Speicherbereich (HMA = High Memory Area) aktiviert werden. Das Programm DOSMAX sorgt dafür, dass weitere Teile des MS-DOS Betriebssystems nun in den zusätzlich zur Verfügung stehenden hohen Speicherbereich geladen werden. DOSMAX selber wurde natürlich zuvor in den oberen Speicherbereich geladen. Für den hohen Speicherbereich wird anscheinend aber wieder ein Teil des oberen Speicherbereichs genutzt. Zumindest werden mir mit dem Programm mem.exe wieder nur 123 KiB gesamt UMA angezeigt, der HMA wird leider nicht aufgezeigt.
Bei immer noch so viel zur Verfügung stehenden oberen Speicher habe ich mir auch mal das MS-DOS eigene Programm doskey.exe gegönnt und in die Startkonfiguration hinzugefügt. doskey.exe ist ein kleines Programm, welches eine Commandline-History für die aktuelle DOS-Sitzung seit Systemstart bietet.

Seit Aktivierung der Upper Memory Area zeigt das DOS-Programm mem.exe als insgesamt zur Verfügung stehenden Speicher nun 1024 KiB an. Dies stimmt insofern, als DOS mit dem entsprechenden aktivierten Speicherbereich die Menge auch verwalten und nutzen kann, allerdings kommuniziert DOS – zumindest beim NuXT – nicht mit dem BIOS, sodass der Wert nicht mit dem physisch zur Verfügung stehenden Speicher korrespondiert. Es geht stattdessen nur davon aus, dass 1024 KiB RAM zur Verfügung steht. Sieht man sich das Board Layout des NuXTs unter Verwendung des Handbuchs an, so scheint der physisch zur Verfügung stehende Arbeitsspeicher aus zwei 512 KiB D-RAM Speicherbausteine zu bestehen. – Was in Summe 1024 KiB sind. Da aber über die DIP-Schalter nur bis zu sechs UMBs à 32 KiB zusätzlich zu dem konventionellen Speicher zugeschaltet werden können, können praktisch auch nur maximal 832 KiB Gesamspeicher genutzt werden. Das ist MS-DOS hier nicht in der Lage exakt zu prüfen. Außerdem werden laut dem NuXT Handbuch noch Teile des UMAs für den Video-RAM (MDA, CGA, EGA oder VGA), für das XT-IDE Universal BIOS, sowie für das System BIOS genutzt. Der Power On Self Test zählt unabhängig davon trotzdem nach wie vor nur den gesamten konventionellen Speicher von 640 KiB hoch. Der zusätzlich konfigurierte hohe, sowie obere Speicherbereich – sprich die gesamten 832 KiB – sieht das BIOS anscheinend gar nicht.

Aufschlüsselung, welche Programme im konventionellen, sowie oberen Speicherbereich liegen.

Links:

Lagacy Workarounds für Dateisysteme unter macOS

Software entwickelt sich mit der Zeit weiter und oft werden auch Komponenten, Funktionen oder auch alte Kompatibilitäten entfernt. So unterstützt Apples Festplattendienstprogramm (englisch: Disk Utility) seit einigen Jahren nicht mehr das im Jahr 1980 eingeführte Dateisystem FAT12, sowie das 1984 eingeführte Dateisystem FAT16. Für mich als Retro-Computer-User, der mit Wechseldatenträger wie 3,5″ Disketten und USB-Sticks über entsprechende Seriel-Controller unter (MS-) DOS Systemen hantiert sehr ärgerlich. Obwohl das grafische Festplattendienstprogramm und auch das entsprechende Kommandozeilenprogramm diskutil einem suggeriert, dass es mit der Option FAT (MS-DOS), beziehungsweise mit dem Parameter MS-DOS FAT16 ein Medium zu formatieren, ist es am Ende doch das modernere FAT32. Ganz zu schweigen von FAT12 für Disketten. Einziger Wermutstropfen ist, dass im derzeitig aktuellen macOS immer noch das alte Kommandozeilenprogramm newfs_msdos enthalten ist. Und so müssen der Formatierungsprozess auf zwei Programmbefehle inzwischen aufgeteilt werden.

Als Beispiel sei ein USB-Stick genommen, auf dem die FAT16 Partition erstellt werden soll. Mit dem Befehl diskutil list wurde herausgefunden, dass es sich um das physische Geräte /dev/disk2 handelt. Zuvor wurde mit diskutil list die physische Datenträgernummer ermittelt.

sommteck@MacBook-Pro ~ % diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         500.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD - Data     154.9 GB   disk1s1
   2:                APFS Volume Macintosh HD            11.2 GB    disk1s2
   3:              APFS Snapshot com.apple.os.update-... 11.2 GB    disk1s2s1
   4:                APFS Volume Preboot                 2.4 GB     disk1s3
   5:                APFS Volume Recovery                1.3 GB     disk1s4
   6:                APFS Volume VM                      1.1 GB     disk1s5

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *4.1 GB     disk2
   1:                 DOS_FAT_32 USB-DRIVE               4.1 GB     disk2s1

Mit diskutil muss trotzdem erst einmal Partitionsschema erstellt werden.:

sommteck@MacBook-Pro ~ % diskutil partitionDisk /dev/disk2 1 MBR MS-DOS FAT16-USB 1G

Mit newfs_mnsdos wird dann die Partition formatiert.:

sommteck@MacBook-Pro ~ % sudo newfs_msdos -F 16 -v "FAT16-USB" -c 32 /dev/disk2s1

Am Ende ist bei einer Cluster-Größe von 32 Sektoren eine etwa 1 Gigabyte große FAT16 entstanden. Der Parameter für die Cluster-Größe ist prinzipiell optional, aber muss ein realistischer Wert angegeben werden, wie physische Speicherkapazität des Mediums größer als die maximal unterstützte Größe des zu verwendeten Dateisystems ist. Mit dem Befehl diskutil /dev/disk2s1 info lässt sich das Ergebnis noch überprüfen.


Ein anderes Problem, welches ich mit einem USB-Stick neulich hatte, war, dass das darauf enthaltene Dateisystem FAT32 scheinbar korrupt war und macOS sich weigerte das Medium einzubinden. Der Trick ist, den Mount-Prozess unter macOS manuell durchzuführen. Im Verzeichnis /Volumes werden in macOS alle interne Datenträger, sowie die Wechseldatenträger eingebunden. Der problematische USB-Stick bekam also erst sein eigenes Unterverzeichnis und mit dem alten Unix-Programm mount_msdos wurde es händisch eingebunden. – Auch wurde zuvor mit diskutil list die physische Datenträgernummer ermittelt.

sommteck@MacBook-Pro ~ % mkdir /Volumes/Testvolume
sommteck@MacBook-Pro ~ % sudo mount_msdos /dev/disk2s1 /Volumes/Testvolume

Danach konnten die Dateien von dem inkonsistenten USB-Stick herunter kopiert und anschließend das Medium erst einmal neu formatiert werden.


Links: