Ich denke ja, dass bei ID-Softwares Computerspiel Doom neben der Grafik, der Spielsteuerung, Spielprinzip und dem Level-Design auch die Musik einen Teil des Erfolgs mit ausgemacht hat. Die Hintergrundmusik des Spiels wurde von Robert Prince komponiert. Es handelt sich hierbei um MIDI-Sequenzen, die großenteils Musikstücken aus dem Metal-Genre, wie Rise von Pantera und Behind the Crooked Cross von Slayer, nachempfunden sind. Mir gefiel sie jedenfalls von Anfang an. Irgendwann habe ich mit einem Level-Editor für die spiel typischen WAD-Dateien diese MIDIs herausextrahiert, um die Musik nur als solche anzuhören. Die MIDI-Dateien wurden mit den Jahren immer wieder durch neue Sequenzer überarbeitet, dass sie etwas mehr und mehr klingen, wie mit richtigen Instrumenten im Studio eingespielt. Im Internet gibt es inzwischen zahlreiche Websites von Retro-PC-Enthusiasten, wo sie als Klangbeispiele für die Entwicklung der PC-Soundkarten in der Nachschau herhalten. So gab es auch bereits eine Klangauffrischung im Rahmen des Brutal-Doom Projekts, welches das Ziel hat, die originalen Doom-Titel aus den 1990er Jahren um weitere spielerische Elemente zu ergänzen. Im Jahr 2016 hat dann schließlich der US-amerikanische Videospielkomponist und Sound-Designer Andrew Hulshult die Musik vom allerersten Doom-Spiel gänzlich neu arrangiert und vertont. – Und was dabei herauskam ist meiner Meinung richtig gut gelungen, denn es klingt nun nicht mehr danach, als ob die Instrumente durch einen Computer-Synthesizer erzeugt worden, sondern nach richtiger Heavy Metal und Gothic Musik.
Das Gute dabei ist, dass man sich nicht nur auf den bei YouTube veröffentlichten Audio-Stream verlassen muss, sondern die klanglich hochwertigeren mp3- und Flac-Dateien des neuen Soundtracks herunterladen kann.
In der zweiten Runde habe ich auf meiner emulierten MicroVAX das von der Digital Equipment Corporation entwickelte ULTRIX installiert. ULTRIX ist die Unix-Variante für die VAX- sowie die DECstation- und DECsystem-Rechnerfamilien von DEC, die erstmals im Jahr 1982 veröffentlicht wurde. Das erste native VAX UNIX-Produkt von DEC war Ultrix-32, basierend auf 4.2BSD mit einigen Nicht-Kernel-Funktionen von System V, und wurde im Juni 1984 veröffentlicht. Später wurde es um Funktionen von BSD4.3 und Unix System V Release 2 ergänzt. Mit ULTRIX-11 bot DEC noch eine Implementation für die Minicomputer der Reihen PDP11 und Micro/PDP-11 an. Die letzte Version von ULTRIX war die Version 4.5 für DECstation und DECsystem mit RISC-CPU, sowie der VAX-Architektur. Sie wurde im November 1995 veröffentlicht. ULTRIX unterstützte sowohl TCP/IP als auch DECnet, ebenso beherrschte es neben SMTP auch Mail-11. Ursprünglich wurde für die VAXstations unter Ultrix-32 die Desktopumgebung Ultrix Workstation Software (UWS) basierend auf dem X Window System verwendet. Mit der Verbreitung von X Version 11 (X11) wurde die DECwindows-Umgebung eingeführt, welche auch Grundlage für die Gestaltung des späteren Motif der OSF war.
Die letzte von DEC veröffentlichte ULTRIX Version 4.5 habe ich auch im Internet als CD-ROM Image gefunden. Hat man im Emulator von dem Installationsmedium gebootet, so steht man auch schon vor der ersten Hürde. Da es sich nicht um (originale) Hardware handelt, stimmen die Laufwerksbezeichnungen für CD-ROM Laufwerk und Festplattenlaufwerk nicht überein. Die Lösung ist, dass die Bezeichnung in dem Installationsprogramm angepasst werden müssen. Und das ist zum Glück keine wilde Sache, denn bei dem Installationsprogramm handelt es sich lediglich nur um ein etwas umfangreiches Shellscript. Allerdings stand ich dann vor der nächsten Hürde. Das minimale System des Installationsmediums, welches in den Computer geladen wurde, besitzt noch nicht einmal den vi als Texteditor. Es steht lediglich nur der noch ältere und zeilenorientierte ed als Texteditor zur Verfügung. Ich habe mich daher bereits im Vorfeld mit der Bedienung dessen ein wenig auseinander gesetzt gehabt. – Und es ist noch nicht mal das Programm cat auf der Shell verfügbar, mit dem man sich den Inhalt des Installationsskripts ausgeben lassen könnte. Auch hier ist man auf umständliche Weise auf den ed angewiesen.
ULTRIX war nie Jahr 2000-kompatibel. Also habe ich mich exakt um 25 Jahre in die Vergangenheit gebeamt, also in den November 1995. Die Zeit in der ULTRIX 4.5 veröffentlicht wurde und ich so langsam begann mich für Computer zu interessieren.
Login ULTRIX mit DECwindows
Man ist aus heutiger Sicht durchaus erstaunt, wie übersichtlich doch die Config-Datei für den ULTRIX-Kernel ist. Es gibt lediglich sieben Optionen, die zusätzlich hineinkonfiguriert und kompiliert werden können. Ein Menuconfig, respektive Xconfig hat unter Linux über die Jahre hingegen deutlich an Optionen und Komplexität zugenommen.
Man ist ja froh, dass ULTRIX neben DECs eigenem DECNet auch irgendwann TCP/IP-Protokollfamilie aus der BSD-Welt mit übernommen hat. Ich konnte dem Host zwar eine IPv4 Adresse und das Gateway konfigurieren, aber das Routing über den nächsten Hopp hinaus habe ich nicht hinbekommen, so dass Computer aus anderen Netzen leider nicht zu erreichen sind. Auch die Namensauflösung von Domains funktioniert leider nicht. Dies liegt wahrscheinlich an der bereits veralteten Bind-Version. Das Problem scheint zu sein, dass ULTRIX sogenannte inverse Abfragen sendet, um eine IP-Adresse einem Hostnamen zuzuordnen. Die meisten DNS-Server unterstützen diese inversen Abfragen aber nicht mehr.
ULTRIX wird von dem Installationsprogramm so installiert und eingerichtet, dass der Systembenutzer root leider kein eigenes Heimatverzeichnis /root/ erhält. Alle Dateien werden also in die oberste Wurzelverzeichnisebene erstellt. Da ich ein Freund von Ordnung bin, habe ich das nachgebessert, so wie ich es von Linux und den modernen BSD-Unix gewohnt bin. Verzeichnis /root/ erstellen und alle .xxx-Dateien in dieses verschieben. Interessanterweise gibt es unter ULTRIX die Datei /etc/shadow nicht. Die Passwörter der User werden verschlüsselt auch in der Datei /etc/passwd abgelegt.
Motif DECwindows
Selbst das Release des letzten großen ULTRIX-Updates ist (nicht nur) aus heutiger sehr minimalistisch und unkomfortabel auf der Commandline-Shell. Es fehlt an erster Stelle schon an einer vernünftigen Shell. Selbst die Korn-Shell unter ULTRIX unterstützte noch keine Commandline-History und die Tabulator-Autovervollständigung der Befehle. Auch gibt es kein (GNU-)tar, dass in einem Rutsch gezipte tar-Archive dekomprimiert und in die Ordnerstruktur zurückextrahiert. Stattdessen muss ein Archiv jedes mal mit dem ineffizienten uncompress dekomprimiert und tar extrahiert werden. Mal ganz davon abgesehen, dass außer dem Standard C-Compiler keine Skript-Programmiersprache wie Perl auf dem System verfügbar ist. Der Hardwaresammler und Websitebetreiber Joachim Buss hatte sich mal die Mühe gemacht und eine eigene ULTRIX Freeware CD-ROM mit etwas GNU-Software, welche man auch eher aus dem Linux-Umfeld kennt, zusammengestellt und bietet diese als Download im Internet an. Das war im Jahr 2002. Das heißt, dass die Versionen der Programme aus heutiger Sicht auch schon wieder sehr veraltet sind, aber dank einer Bash, dem Midnight Commander, wget und Skriptsprachen wie Perl oder Python, macht es die Bedienung von ULTRIX deutlich komfortabler. Es ist auch zu empfehlen, sich als Erstes den GNU C-Compiler und GNU make zu installieren. So lässt sich nämlich GNU tar nicht mit dem Standard C-Compiler von ULTRIX bauen. GNU tar ist aber in der Lage ein tar-Archiv mit einem Befehl gleichzeitig zu dekomprimieren und extrahieren. Des Standard-tar unter ULTRIX kann ein Archiv nur extrahieren und dazu muss es aber vorher erst mit bzip2 separat dekomprimiert worden sein. Einige Programme sind auf dieser CD-ROM als Quellcode vorhanden, während bei anderen wie dem Midnight Commander bereits vorkompilierten Programmbinaries einschließlich der Dokumentation als Archiv enthalten sind. Bei Diesen müssen die Dateien lediglich im Dateisystem entsprechend den Pfaden nachgehend kopiert werden. So lässt sich das System um einige nützliche Programme, der GNU X11-Umgebung und Window-Manager erweitern. Es gibt aber auch einen SSH-, DHCP-, sowie einen Apache-Server für das ULTRIX.
Das letzte ULTRIX-Release war so rudimentär, dass es noch nicht einmal Aliase gab. Auch in vielen anderen Dingen ist das ULTRIX anders aufgebaut. So werden zum Beispiel die Heimatverzeichnisse der User nicht in dem Verzeichnis /home/ angelegt, wie es heute bei Linux und den BSD-Systemen die Konvention ist, sondern im Verzeichnis /usr/users/. Das Dialogbasierte Programm erlaubt die Speicherung der User-Verzeichnisse aber auch an eine andere beliebige Stelle des Dateisystems, ganz wie es dem Systemadministrator beliebt. Hier eine tabellarische Übersicht über die Unterschiede zwischen den einzelnen Unix-Derivaten und Linux. (eigenes DokuWiki)
ULTRIX DECwindows DECterminal 1
Am Ende habe ich auf meinem Linux-Host, der die Emulation bewirtet, noch das Programmpaket xserver-xephyr installiert. Dieses erlaubt die Entgegennahme von einer X11-Session eines Host innerhalb eines Netzwerkes und stellt die Bildschirminformationen in einem separaten Fenster dar. Somit lässt sich die Ausgabe des X-Window-Servers vom Ultrix auch darstellen und das System über das grafische DECwindows mit Motif mit Maus und Tastatur bedienen. Allerdings hat sich das System bei mit ab diesem Punkt immer recht schnell die Karten gelegt und es funktionierte nicht über einen längeren Zeitraum. Mal ließen sich die Standard-Applikationen nicht starten oder das System brach nach einigen wenigen Minuten die X-Windows-Session wieder ab und warf mich auf das Login-Fenster zurück. Ich vermute – und das ist insgeheim auch meine Hoffnung – dass das Acer-Notebook als Host-Computer mit seinem AMD Athlon X2 Dual Core als Prozessor nicht leistungsstark genug für die Emulation ist.
ULTRIX DECwindows DECterminal 2
Update 16. Mai 2021 14:05 Uhr:
Das sich die Standard-Applikationen von DECwindows sich oft nicht öffnen ließen, lag daran, dass ich das Fenster mit der dxconsole meistens geschlossen hatte. Damit die DECwindows-Programme sich immer starten lassen, sollte die dxconsole wenigstens als Icon minimiert im Hintergrund weiter ausgeführt werden. Allerdings lässt sich das Programm Paint prinzipiell nicht starten. Es muss wohl fehlerhaft sein, da auch andere User das Problem haben. Aber es bleibt immer noch zu klären, warum mich nach wie vor die X-Windows-Session immer wieder nach ein paar Minuten ausloggt und mich wieder zum grafischen Login-Fenster zurückbringt.
Es gibt – wie fast immer – einen Hauptgrund und Motivator sich mit Computern auseinander zu setzen: Spiele! Das war bei mir nicht anders. Bei mir hat es ja in den späten 1980er Jahren auf dem DDR-Kleincomputer KC85/4 von Robotron angefangen, seit es dann ab dem Jahr 1991 bis heute ohne Unterbrechung die x86 PC-Plattform ist.
Worm – früher Spielverlauf
Über das c’t Sonderheft Retro des Heise-Verlags bin ich über das Thema CP/M auf das Computerspiel Worm aufmerksam geworden. Dank des großen Angebots an CP/M-Versionen, der dazu passenden Software im Internet und dem SIMH, der auch den Altair 8800 mit Zilog Z80 Prozessor emulieren kann, ist die Einstiegshürde gering.
Worm – Der kopf jagt seinem Körperende hinterher
Worm ist eine frühe Umsetzung des später auf den Nokia-Mobiltelefonen sehr beliebten Snake gewesen. Das gute an dieser frühen Implementation von Worm ist, dass im Spielablauf nur dann etwas passiert, wenn man eine Taste zur Bewegung des Wurmes drückt. Das entschleunigt den Bewegungsablauf auf eine beliebige Langsamkeit. Dies gibt im Umkehrschluss für den Spieler die Möglichkeit langsam, behutsam und mit System den Bewegungsverlauf der Spielfigur zu Steuern und letztendlich das Spiel vollständig zu lösen. Noch nie ist es mir gelungen, in der Lage zu sein ein Spiel überhaupt – und zudem in der Schnelligkeit von zwei bis drei Tagen und ein paar Anläufen zu lösen.
Worm – Letztes Segment mit neuer Zahl besetztWorm – Gelöstes Spiel
Die erste Version von Worm ist im Jahr 1978 von dem US-Amerikaner Peter Trefonas programmiert worden. Es ist damit für mich das älteste von mir gespielte Computerspiel.
Nun berichte ich in dieser Artikel-Serie über Hardware und zeige auf, welche Betriebssysteme sich auf dieser betreiben lässt, ohne selber einen eigenen visuellen Eindruck von ihr abgeben zu können. Um ehrlich zu sein, ich selber bin noch nie mit einem Computer, oder mit deren Peripherie, von der Digital Equipment Corporation in Berührung gekommen. Stattdessen hatte ich in den letzten rund 6 Jahren dreimal die Möglichkeit Zutritt zu Räumlichkeiten zu bekommen, wo jedes mal ein Stück DEC-Hardware im Begriff einzustauben war.
Die Erste war mit einem VT420 Terminal, welches die EMR-Technik eines seinerzeit bereits stillgelegtem Betriebes meiner alten Chemie-Firma noch herumstehen hatten. Der Kollege von der IT-Abteilung merkte dazu an, dass die dazugehörige Computer-Hardware bereits einige Monate zuvor verschrottet wurden. Im Juni 2015, keine ganzes Jahr später, besuchte ich mit Bekannten den Tag der offenen Tür bei der Deutschen Nationalbibliothek in Frankfurt. Bei der Führung durch deren Inhouse betriebenen, kleinen Rechenzentrum, war in einer Ecke des Raums auf einem rollbaren Pult von mir wieder eine VT420 Terminal auszumachen. Auf meine Frage, ob denn das Terminal aus musealem Zweck abseits der deutlich moderneren Computer-Hardware da stehe, versicherte aber ein Angestellter, dass das Terminal ganz gut und gerne noch für die Konfigurations- und Wartungsarbeiten der Router und Switche genutzt wird. Vor zwei Jahren hatte man mir im Rahmen eines Vorstellungsgespräches bei einem großen, deutschen Transportunternehmen noch deren Betriebszentrale gezeigt. Dort stand dann auch noch eine vollständige VAXstation samt Monitor ungenutzt im Regal neben der anderen EMR- und Computertechnik.
DEC VT420 Serial Terminal
Der amerikanische YouTuber TrackZero hatte vor gut zwei Monaten ein Video veröffentlicht, in dem er seine im Laufe des Jahres erstandene MicroVAX 3800 in Einzelteilen präsentiert und dann zusammenbaut. In meinem Blog-Artikel zu der von mir mit SIMH zu emulierenden Hardware habe ich mich für die MicroVAX 3900 entschieden. MicroVAX 3800 und MicroVAX 3900 wurden gemeinsam unter dem Code-Namen „Mayfair III“ 1989 als High-Ende-Modelle der MicroVAX-Familie durch DEC auf den Markt gebracht. Beide Computer sind im wesentlichen völlig identisch. Sie arbeiten beide mit dem gleichen KA655-CPU-Modul und unterstützten bis zu 64 MiB ECC-RAM. Die kleinere MicroVAX 3800 unterscheidet sich aber von ihrem größeren Schwester-Modell insofern, da sie nicht das mehr als 19″ breite, sondern ein kleineres auf Rollen beweglicheres Gehäuse besitzt. Dadurch konnte sie aber auch nur eine Festplatte mit einer Speicherkapazität von maximal 1,2 Gigabyte aufnehmen, währende die größere 3900 mit einer Festplatte von bis zu 1,5 Gigabyte Speicherkapazität ausgestattet werden konnte.
MicroVAX3900 (Quelle: The NetBSD Foundation, VAX Hardware Reference: www.netbsd.org)
Quelle: YouTube-Kanal TrackZero
In einem später folgendem Video wird TrackZero noch seine nachträglich erstandene Video Card für seine VAX präsentieren. – Ich werde gespannt auf sein!
NetBSD ist ein unixoides Betriebssystem, bei dem die einzelnen Komponenten des Userland mit den Fähigkeiten des Kernels optimal abgestimmt sind. Dies wird dadurch erreicht, dass der Kernel und fast das ganze Userland aus einer Hand stammen. Großer Wert wird darauf gelegt, dass sich das System auf allen Architekturen gleich verhält. NetBSD versteht sich sowieso darauf, auf vielen Computer-Architekturen ausgeführt werden zu können, von denen inzwischen viele einen historischen Charakter haben. – Nicht umsonst gibt es den alten Witz.: ‚NetBSD läuft auf allen Geräten. Selbst auf einem Toaster.‘
Die Portierung von NetBSD auf die VAX-Architektur der Digital Equipment Corporation war erstmals mit der NetBSD-Version 1.2 im Oktober 1996 abgeschlossen. Seitdem wird der VAX-Port kontinuierlich weiter entwickelt. Trotzdem ist NetBSD ein modernes Betriebssystem am Puls der Zeit. So war NetBSD auch das erste unter den Open Source-Betriebssystemen, welches die USB-Schnittstelle mit der Version 1.4 im Mai 1999 unterstützte. Selbst unter Linux wurde die Unterstützung für USB erst mit Kernel 2.4 im Januar 2001 realisiert.
Boot NetBSD 9.1 MicroVAX 3900
Ich selber habe meinen ersten Kontakt mit NetBSD mit Erscheinen der Version 4.0 aufgenommen. – Das war im Jahr 2008. Motivation war damals für mich, dass das Betriebssystem selber nur aus einem kleinen Basissatz mit den wichtigsten Programmen (also dem Useland) besteht und so trotz Fehlen einer grafischen Benutzeroberfläche mit Maus, stattdessen mit einer ncurses-ähnlichen Menü-Steuerung extrem fix auf dem Computer installiert werden kann. Nach dem ersten Boot auf das installierte System war und ist man nur mit dem vi als Texteditor ausgestattet, gezwungen das System durch editieren von Dateien und den Kommandozeilenprogrammen des Basissystems zu konfigurieren und sich einzurichten. Das war für mich der Hebel, einen Zugang zu der Shell zu bekommen. Schneller und deutlich angenehmer als, wenn ich mich zum Beispiel mit Linux From Scratch erst einmal durch lange Anleitungen lesen hätte müssen und die nötigen Programme sowie Bibliotheken aus dem Sorce-Code erst in Binädaten kompiliert werden müssen.
Inzwischen ist das Programm sysinstall – so heißt der ncurses-ähnliche Installer nämlich – nochmals verbessert worden. So lassen sich über ihn inzwischen unter anderem auch die Quellpfade für die pre-kompilierten Programmpakete sowie das Archiv der Programmpakete mit dem Quellcode konfigurieren und beziehen, den lokalen NTP-Zeitserver aktivieren, den Displaymanager xdm für den automatischen, grafischen Login systemweit aktivieren oder einen eingeschränkten User-Account erstellen. Im Prinzip verläuft die Installation und Einrichtung des Systems auf der VAX-Architektur genau so wie bei der x86 PC-Version (32 und 64 Bit). Das einzige, was im Gegensatz zu den x86 PC-Versionen zum Glück wegfällt, ist die Partition mit der MBR-/GPT-Formatierung. Während des Boots des Installationsmediums muss aber noch ein Terminal ausgewählt werden, sonst kann verständlicherweise das sysinstall-Programm nicht starten. – Es stehen als Terminal-Emulation VT100, VT220, Ansi und XTerm zur Verfügung, wobei die Darstellung von der Ansi-Emulation im SIMH-Emulator absolut furchtbar aussieht. War ich nach der Installation von dem NetBSD 7.x im SIMH ziemlich angenervt, weil der Init-Prozess bei jedem Booten von der HDD nach der gewünschten Terminal-Emulation fragt, wird bei NetBSD 9.x das System ohne der Emulation gestartet. Es kann sein, dass da die Skripte vor Veröffentlichung nicht vollständig implementiert wurden. Die Umgebungsvariable muss also nachträglich noch händisch gesetzt werden.
Da zum heutigen Veröffentlichungszeitpunkt dieses Beitrags NetBSD 9.1 erst 12 Tage zur Verfügung steht, wurden noch keine pre-kompilierten pkgsrc-Programmpakete für den VAX-Port auf den Servern zur Verfügung gestellt. Waren für NetBSD 8.2 noch 476 Binärpakete verfügbar, gibt es für NetBSD 9.0 nur noch 26 Pakete zur Auswahl. Ich denke, dass aufgrund der aus heutiger Sicht extrem begrenzten Leistungsfähigkeit der VAX-Architektur die Computermodelle längst nicht mehr auch nur für halbwegs sinnvolle Aufgabengebiete eingesetzt werden können, wird an der Menge der angebotenen Programmpakete auch kein Zuwachs mehr zu erwarten sein. Der NetBSD-User John Klos hatte mal das Experiment gewagt und auf seiner VAXStation 4000/VLC mit 24 Megabyte RAM unter Version 9.0 Perl in der Version 5.30.3 aus den Quellen kompiliert. Das Kompilat stand erst nach exakt 9 Tagen, 15 Stunden, 6 Minuten und 48 Sekunden zur Verfügung.
Woohoo! #NetBSD 9 on a #VAX 4000/VLC has finished compiling Perl 5.30.3. It only took 9 days, 15 hours, 6 minutes and 48 seconds.
I'm amazed that it can compile on a system with a modern OS in just 24 megs of memory.
— 🇺🇦 Fediverse: @AnachronistJohn@zia.io (@AnachronistJohn) August 15, 2020
Mit der Veröffentlichung von Version 2.8 war im Dezember 2000 die Portierung von OpenBSD auf DECs VAX-Architektur abgeschlossen und die Weiterentwicklung begonnen. OpenBSD selber ist von dem ehemaligen NetBSD-Mitinitiator und -entwickler Theo de Raadt im Jahr 1995 gegründet worden, nachdem dieser von seiner ehemaligen Community ausgeschlossen wurde. Nach der Veröffentlichung von Version 5.8 im Jahr 2015 wurde dann die Weiterentwicklung von OpenBSD auf die VAX-Reihe wieder aufgegeben.
