Emulation einer VAX mit SIMH: Die Hardware

Der Host – Der Computer auf dem SIMH ausgeführt wird

Nachdem ich meine ersten Gehversuche in der Emulation der (Micro-) VAX unter SIMH unternommen habe um in DEC’s Betriebssysteme ULTRIX und OpenVMS hineinschnuppern zu können, sowie auch bereits der Gedanke in mir aufkeimte, gleich eine Artikel-Serie daraus zu stricken, hatte ich die Möglichkeit für lau einen Laptop zu übernehmen. Dabei handelt es sich um einen Acer Aspire 7530, welcher vermutlich im Mai 2008 auf den Markt gebracht wurde. Ausgestattet ist das Gerät mit einem AMD Athlon X2 Dual Core QL-60, welcher mit 1,9 GHz getaktet wird und der zwei mal 64 KB Level 1 Cache, sowie 512 KB Level 2 Cache für jeden der beiden Kerne besitzt. Damit ist die CPU-Leistung für diesen dicken, schweren 17″-Laptop (von den Maßen und der Tastatur eigentlich schon eine Mobile-Workstation) laut der damaligen Fachpresse recht mager. Zur sonstigen Ausstattung gehörten 3 GB DDR2 RAM, von dem bis zu 256 MB Video-RAM für die auch eher seinerzeit schwache nVidea GeForce 9400M abgezweigt werden können, und eine 320 GB Festplatte. Die weiteren technischen Merkmale habe ich in meinem Wiki in der Auflistung meiner PC-Familie aufgelistet, waren aber seinerseits bei Marktstart des Gerätes alle marktüblich, spielen dennoch aber für meinen Einsatzzweck keine Rolle.

Nach Erhalt des Gerätes bin ich erst einmal hingegangen und habe für etwas mehr als 20,- Euro noch ein 2 GB Speichermodul gekauft und eingebaut, weil ich der Überzeugung bin, dass ein Computer Arbeitsspeicher nicht genug haben kann. So hat das Gerät nun 4 Gigabyte statt der ursprünglichen etwas krummen 3 Gigabyte. Beim Betrieb dann mit Linux unter Verwendung von LXDE als Window-Manager hat sich dann deutlich heraus gestellt, dass die CPU-Leistung der deutlich limitierender Leistungsfaktor ist, und weniger die Menge des Arbeitsspeichers. Da ich auf meinen Apple-Macs leider die Treiber für TUN/TAP und vde2 nicht korrekt installieren konnte, bin ich doch froh einen separaten Computer zu haben, den ich in erster Linie nur für das Ausführen von SIMH nutzen kann. Von daher ist es erstmal nicht so schlimm, dass modernere Betriebssystem wie ein aktuelles NetBSD unter einer emulierten Digital VAX auf dem Acer-Laptop recht träge gegenüber meinen leistungsfähigeren Macs laufen. Auf dem Acer-Laptop habe ich Debian-Linux als Host-Betriebssystem installiert, wo der TUN/TAP-Treiber vernünftig läuft und die Programm-Pakete auch besser aufeinander abgestimmt sind.

Links:

Die MicroVAX 3900 von DEC als emulierte Computer

Die VAX im allgemeinen (kurz für Virtual Address eXtension) ist eine von der Digital Equipment Corporation entwickelte 32 Bit Rechnerarchitektur. Die 32 Bit VAX-Prozessoren besitzen einen CISC-Befehlssatz. Für die VAX-Reihe hatte DEC auch passend zu der Architektur das Betriebssystem VMS (kurz Virtual Memory System, später OpenVMS) mitentwickelt und auf den Markt gebracht. – Inzwischen wurde und wird auch das Betriebssystem OpenVMS durch die Firma Hewlett Packard Enterprise zu einem 64 Bit System weiter entwickelt. – Auch lässt sich inzwischen auf den Computern der VAX-Reihe NetBSD und Linux betreiben. Es wurde von OpenBSD auch eine Portierung für die VAX-Computer entwickelt, aber diese wurde in ihrer Weiterentwicklung mit OpenBSD 5.9 im Jahr 2016 wieder eingestellt. Ich bin mir aber auch nicht sicher, ob inzwischen die Weiterentwicklung der Portierung von Linux auf die VAX-Architektur wieder bereits eingestellt wurde.

In der stabilen SIMH-Version 3.x wurde die von Digital Equipment Corporation als ersten Computer der VAX-Reihe auf dem Markt eingeführte VAX 11/780 aus dem Jahr 1977 und das im Jahr 1989 wesentlich kleinere Model, die MicroVAX 3900 implementiert. Da die VAX 11/780 das erste Modell der VAX-Familie war, hat Digitial im Laufe der Jahre einen eigenen Benchmark für die hinzugekommenen Modell (-Reihen) geschaffen.: den VUP. VUP steht für VAX Unit of Performance, bei dem das Urmodel als Referenz definiert ist. Der bei den nachfolgenden Modellen angegebenen VUP gibt also den Faktor der Leistung zum Urmodell an. So hat die bereits erwähnte MicroVAX 3900 einen VUP von 3,8 oder die im Jahr 1991 eingeführte VAXStation 4000 M60 einen VUP von 12.

Im vorherigen Beitrag habe ich bereits dargestellt, dass die aktuelle Beta-Version von SIMH gegenüber den stabilen, prekompilierten Versionen in den Linux- sowie BSD-Distributionen für mich die bessere Wahl ist. Ein wesentlicher Punkt von der Beta-Version ist, dass neben den bereits in der stabilen SIMH-Version 3.x verfügbaren VAX 11/780 und der MicroVAX 3900 weitere Computer der VAX-Reihe emuliert werden können. In einer Tabelle in meinem Wiki habe ich mal die neu hinzugekommenen Modelle tabellarisch aufgeführt, die einen sichtlichen Leistungszuwachs gegenüber die MicroVAX 3900 vorweisen können – sofern der Host-Computer für die Verarbeitungsgeschwindigkeit entsprechend leistungsfähig ist. So hatte ich zum Beispiel mal den Versuch unternommen gehabt, auf einem Raspberry Pi Model 1 B mit einem mit 700 MHz getakteten 1-Kern ARM11-Prozessor und NetBSD 7 als Host-Betriebssystem, die MicroVAX 3900 zu emulieren. Als Betriebssystem kam die VAX-Portierung von NetBSD 7 wieder zum Einsatz. Die Verarbeitungsgeschwindigkeit des Raspberry Pi war dabei so langsam, dass auf dem emulierten System der Login-Prozess während diesem bereits wieder Timeouts geworfen hatte. Aber ohne Login ist natürlich auch nur im Ansatz kein Arbeiten mit dem System möglich. Andere User hatten zu dem Zeitpunkt sich mit dem Raspberry Pi der ersten Generation bereits erfolgreich OpenVMS-Cluster gebaut gehabt.

Bei meinen Experimenten, eine der hinzugefügten VAX-Modelle in der Beta-Version zu emulieren, bin ich auf zahlreiche Fehler gestoßen und ich konnte bisher nicht die passenden Geräte-Komponenten (Harddisk-Controller, Festplatten- und CD-ROM Modell) für einen Betrieb zusammenstellen. Andere User haben beim Emulationsversuch – beispielsweise einer VAXStation – nicht die Netzwerkschnittstelle aktivieren können. Es kann natürlich auch sein, dass im Code für die in der aktuellen Beta-4 neu hinzugekommen VAX-Modelle noch Fehler sind. Deswegen beschränke ich mich momentan auf die bereits in stabilen Version vorhandene MicroVAX 3900.

Quelle: The NetBSD Foundation, VAX Hardware Reference (www.netbsd.org)

Noch ein paar Fakten und Informationen zu der Hardware der MicroVAX 3900 selber.:

Der Computer wurde durch DEC mit dem Codenamen Mayfair III im April 1989 im Markt eingeführt. Sie war High-End-Modell der MicroVAX-Familie, welche die MicroVAX 3600 ersetzte, und sollte mit der AS/400-Serie von IBM konkurrieren. Bei der Einführung betrug der Startpreis der MicroVAX 3900 120.000,- US-Dollar. Dieses System verwendete das KA655-CPU-Modul, das einen CVAX-Chipsatz mit 16,67 MHz (60 ns Zykluszeit) enthielt.

RangeServer
IntroducedApril 1989
CPUKA655, CVAX+ Chip
Taktfrequenz16,67 MHz
FPUCFPA
Cycle in ns60
Level 1 Cache1 KiB
Level 2 Cache64 KiB mit von 120 ns Cycle
Arbeitsspeicher16 – 64 MiB ECC
BUS Storage1 x QBUS und 1 x DSSI
Bandbreite3,3 MB/s
HDD Kapazitätmax. 9,7 GB
GehäuseH9642 (19″ breit)
VUP3,8
Einführungspreis in $120.000,-
Supportet OSVMS, ULTRIX, VAXELN
FPU DatentypenF, D, G, H
Netzwerkmax. 2 Ethernet-Ports

Links:

Emulation einer VAX mit SIMH: Der SIMH-Simulator

SIMH (History Simulator) des Computer History Simulation Project ist eine Sammlung von Simulatoren für historisch bedeutende oder einfach nur interessante Computerhardware und -software aus der Vergangenheit. Ziel des Projekts ist es, hoch portable Systemsimulatoren zu erstellen und diese als Freeware im Internet mit frei verfügbaren Kopien bedeutender oder repräsentativer Software zu veröffentlichen.
Das Projekt soll zudem dazu dienen, älterer Software weiterhin eine Umgebung zu bieten, auch wenn die Original-Hardware nicht mehr zur Verfügung steht. Auch wird es verwendet, um Betriebssysteme wie OpenVMS, RSTS, RSX-11, RT-11, TOPS-10 oder TOPS-20 auf PCs laufen zu lassen.

Unter der Liste der emulierten Hardware sind folgende Computer vertreten:

  • einige der PDP-und VAX-Reihe von Digital Equipment Corporation
  • Nova und Eclipse von Data General
  • Großrechner von IBM der 700er-/7000er-Serie
  • Minicomputer von Hewlett-Packard und Honeywell
  • die CDC 1700 von Control Data Corporation
  • den Microcomputer Altair 8800 von MITS (wahlweise mit Zilog Z80 oder Intel 8080 Prozessor)
  • und viele andere

Die aktuelle, stabile Version vom SIMH ist die 3.x. Diese ist auch in allen aktuellen und namenhaften Linux-Distributionen, sowie BSD-Systemen als vorkompiliertes Paket in den Repositories enthalten. Ich aber hingegen bevorzuge lieber den aktuellen Beta-Zweig v4.0 – 19-01 Current von der GitHub Projektseite. Dies hat auch mehrere Gründe.:

  • In der aktuellen Beta 4 ist bereits USE_NETWORK als Teil der Kompilierungsbefehlszeile definiert, damit die PDP-11- und VAX-Simulatoren die Ethernet-Emulation unterstützen.
  • Neben der Emulation von DECs VAX11/780 und MicroVAX3900 aus dem SIMH-Zweig 3.x, wurden in dem Beta-Zweig 4.x Current weitere VAX-Modelle implementiert. – Allerdings muss ich dazu sagen, dass bei meinen Internetrecherchen ich festgestellt habe, dass andere User von fehlerhafter Netzwerkunterstützung berichteten. Ich selber habe bei einigen neu hinzugefügten VAX-Modellen das Problem gehabt, die Datenträger korrekt zu definieren und der Emulator konnte die virtuellen Geräte nicht ansprechen.
  • Von allen (neuen) VAX-Modellen sind die Boot-ROMs mit den eventuellen Patch-Dateien enthalten. Gerade bei Linux-Distributionen wie Debian-Linux, welche den Fokus haben, im Wesentlichen ein System aus freier Software zu bestehen, fehlen die Boot-ROM-Dateien, da sie proprietären Bytecode enthalten.

Um den aktuellen Beta-Release des SIMH-Emulators nun auf dem Computer installieren zu können, ist es wichtig folgende Pakete vorher zu installieren, sofern noch nicht geschehen. (als Benutzer root unter Debian-Linux):

apt-get update && apt-get install git build-essential

Quellcode des aktuellen Beta-Releases laden und den Emulator – zum Beispiel einer MicroVAX3900 von DEC – kompilieren.

$make {simulator-name (i.e. vax)}

git clone https://github.com/simh/simh.git
cd simh
make vax

Die so erstellte Binärdatei wird im SIMH-Verzeichnis in dem Unterverzeichnis BIN/vax gespeichert.

Damit das emulierte System auch Teil des heimischen IPv4 Netzwerkes ist, habe ich bereits in meinem Blog-Artikel „Netzwerk-Bridge unter Linux mit TUN/TAP“ beschrieben, wie unter einem Debian-basierten Linux eben diese einzurichten ist.

Start-Konsole
Start-Konsole mit Hilfe Übersicht

Um die Simulation der MicroVAX3900 nun starten zu können, muss lediglich die erstellte Binärdatei noch ausgeführt werden. SIMH startet dann immer erst in den Kommandomodus. Diese Konsole ist sehr mächtig und beinhaltet eine sehr umfangreiches Hilfesystem in dem alle Parameter zur Ausführung der Simulation, sowie die unterstützten Hardwarekomponenten des emulierten Computersystems aufgeführt werden. Ferner kann über die Konsole auch ein Log über die Simulation erstellt werden.

SIMH-Hilfe show-Befehl
SIMH-Hilfe show-Befehl
Zusätzliche Informationen der Hilfe
Zusätzliche Informationen der Hilfe
Informationen der Specifikationen
Informationen der Specifikationen

Mit der Konsole können auch dann direkt die Maschinen-spezifischen Parameter gesetzt werden und zur Ausführung für ein Betriebssystem der Hardware die Emulation gestartet werden.

Parameter und Boot
Parameter setzen und Boot

Es sei nochmal darauf hingewiesen, dass SIMH neben der VAX-Reihe von DEC auch andere Computerarchitekturen (anderer Hersteller) simuliert. Daher ist die Konsole von SIMH auch bei den anderen Simulatoren ähnlich umfangreich. – Zum Beispiel habe ich die Altair-Emulation mit dem Zilog Z80 Prozessor mal kurz ausprobiert gehabt.

Links:

iSH für Apple iOS – Das iPhone wird Linux-tauglich

Apple hat sein Smartphone-Betriebssystem iOS – in den ersten drei Majorreleases noch unter dem Namen iPhone OS vermarktet – von Anfang an so abgeschottet, dass es einem als User und Entwickler nicht möglich ist, mit Dateien in einem Dateisystem App-übergreifend arbeiten zu können, sowie mit einer Applikation weitere Programme sich auf das Gerät installieren zu können. – Auch unter dem Begriff Sideloading bekannt. – Jede Applikation soll ausschließlich separat über den Apple-eigenen iOS App Store auf iPhone oder iPad bezogen und installiert werden. Dies ist von Apple auch in den Regularien für App-Entwickler vorgeschrieben und wird vor der Veröffentlichung in einem Review-Prozess kontrolliert. Apple begründet dies damit, dass Nutzer so vor schädlicher Malware geschützt werden sollen. Der Nachteil dabei ist aber, dass die Smartphones und Tablets von Apple in der Nutzungsmöglichkeit weitaus unflexibler als die Geräte für Googles Android oder den Apple-eigenen Laptops, also Computern sind. Besonders ärgerlich ist dies am größten bei den iPads, weil selbst Apple diese spätestens seit dem iPad Pro auch inzwischen als Computer-Kategorie vermarktet, die einem klassischen Laptop – also Apples eigene MacBook (Air/Pro) ersetzen können sollen. Mit den Smart-Keybords bietet Apple selber auch Peripherie für ihre Tablets an, die das Handling eines klassischen Laptops ermöglicht – dazu aber zusätzlich ein Touch-Display für die Bedienung mit Fingergesten und Stift direkt auf das Display.
Apple hat mit der eigenen Files-Apps für iOS und iPadOS ein Programm für den Umgang mit Dateien inzwischen implementiert, aber an die Möglichkeiten die der Finder auf den Macs oder der Datei-Explorer unter Windows bietet, kommt diese App nicht im Ansatz heran.
Apple hatte aber bereits nun vor über sechs Jahren das Unternehmen Burstly übernommen gehabt, mit deren App Testflight einem es möglich war, auch Apps im Rahmen von Beta-Tests von Entwicklern außerhalb des Apple-eigenen App Stores sich auf iPhone oder iPad installieren zu können. Das machte es sehr interessant, eine iOS-Applikation für einen wirklich sehr begrenzten Umfang an Benutzern entwickeln und ausrollen zu können, ohne die App durch Apples Review-Prozess hindurch in den App Store veröffentlichen zu müssen. Zum Beispiel für eine selbstgebaute Smarthome-Steuerung für weniger als 100 iOS-Usern in einem Verein oder MakerSpace. Die angenommenen 100 User hätte man einfach als die Beta-Tester deklariert.

Alpine Linux

Vor zwei Jahren hatte dann der Softwareentwickler Theodore Dubois das Projekt iSH auf GitHub veröffentlicht gehabt, mit dessen es dann möglich war, sich ein emuliertes Linux auf das iDevice installieren zu können. Bei iSH handelt es sich dabei um eine iOS-App, in der im Usermode des Darwin-Systems – also der Betriebssystemunterbau von iOS auf Basis des BSD-Unix von Apple – ein Emulator zu Ausführung von Maschinenbefehlen der x86_32 Architektur läuft mit einem Alpine-Linux. Alpine-Linux ist wiederum eine auf BusyBox basierende Linux-Distribution, die in erster Linie für „Power-User entwickelt wurde, die Sicherheit, Einfachheit und Ressourceneffizienz schätzen“. Das Alpine-Linux verwendet als eigenes Paketverwaltungssystem apk-tools. Somit ließ sich weitere quelloffene Software aus der GNU-Linux-Welt mit zum ersten mal außerhalb Apples App Store auf iPhone beziehungsweise iPad installieren. Möglich war dies, weil Apple vor rund zwei Jahren selber mit der Swift-Playground App für iOS eine einfache und spielerische Möglichkeit geschaffen hat, auf iPhone und iPad anhand ihrer eigenen Programmiersprache Swift das Programmieren zu erlernen. Und es ist in Testflight für Entwickler möglich, für App-Tester Programmteile aus dessen Quellen nachinstallieren zu können. Über die Testflight-App musste man sich automatisch zu einem Beta-Tester für iSH aktivieren und schon konnte man für jede „Testversion“ von iSH für einen vorher definierten Zeitraum die Testversion benutzen. Allerdings war aber die Anzahl der Beta-Tester auf maximal 10.000 User begrenzt.

Vor 3 Tagen ging dann die Meldung durch die IT-Tech-Presse, dass von iSH die Version 1.0 von Apple im App Store zum Download freigegeben wurde. Die Frage ist aber, wie ist das möglich, wenn die Regularien des App Stores das Sideloading von weiteren Programmen aus einer App verbietet? Die Antwort ist: Das Kommandozeilenprogramm apk ist nicht mehr Teil von iSH, so dass keine weiteren Programmpakete erst einmal nachgeladen werden können. Dass es aber über einen kleinen Umweg möglich ist, werde ich am Ende noch kurz dokumentieren.

Zuvor aber noch ein paar Worte zu iSH, wie es bereits seit der zuvor zweijährigen Testflight-Beta gibt und verhält.:
Das Alpine-Linux in iSH enthält bereits eine Reihe gängiger Kommandozeilenprogramme wie wget, curl und den Texteditor vi. Alpine setzt nach wie vor auf das einfache und leichte OpenRC als Init-System. Allerdings funktionieren nicht alle Pakete. Darunter zum Beispiel nicht ifconfig, ip, nmap, arp, dpkg, lighthttpd und weitere andere.
Die Linux-Umgebung mitsamt Kernel ist nur wenige Megabyte groß. Über eine File-Provider-Extension lässt sich iSH auch in Apples vorinstallierte Dateien-App integrieren und erlaubt so einen Zugriff auf das eigene Dateisystem – um das Kopieren von Dateien in andere iOS-Apps zu ermöglichen.

Da ich derzeit ein iPhone 8 mit 256 Gigabyte Flssh-Speicher besitze, steht also der gesamte noch verfügbare Flash-Speicher für die Erweiterung des Linux mit Programmen, Bibliotheken und Daten zur Verfügung. Das heißt aber auch im Umkehrschluss, dass in das Alpine Linux nachinstallierte Programmpakete und Bibliotheken seitens des iOS als Nutzer-Daten und Dokumente angesehen werden. Der Nachteil: Mein iPhone-Backup fällt auch entsprechend im Laufe der Nutzung größer auf meinen Backup-Medien aus. Der Vorteil ist aber, dass im Fall eines iPhone-Wechsels das gesamte System auf das neue Gerät mit der Migration des iPhone-Backups in einem Rutsch mit kopiert wird. – Allerdings sofern die Gesamtkapazität des neuen Gerätes nicht die Größe des Backups unterschreitet.

Midnight Commander in iSH

Die Neben-Story meines derzeitigen iPhones ist ja, dass ich vor genau drei Jahren bei dem Wechsel von meinem bis dahin genutzten iPhone 5 mit 32 GB Flashspeicher nicht abschätzen konnte, welche Speicherkonfiguration des damals neu angebotenen iPhone 8 für mich die richtige ist. Mein Ziel seit damals ist ja, dass ich das Gerät auch wieder mindestens 5 Jahre durchgängig nutzen möchte. Voraussetzung war aber, dass ich alle Apps und Daten des restlos vollen 32 Gigabyte Gerätes mit auf das damals neue iPhone 8 migriere und übernehme. Das Problem bestand aber darin, dass ich dachte, die weiteren 32 Gigabyte auf die 64 Gigabyte in der kleinsten Konfiguration könne für die immer größer werdenden Apps nicht für die 5 kommenden Jahre reichen. Apple hat cleverer weise dann kein 128 Gigabyte Modell angeboten, weil sie genau wussten, dass der unsichere Kunde wie ich im Zweifel sowieso gleich auf die nächsthöhere Speicherkonfiguration zurückgreifen wird, und haben für weitere 170,- Euro dann nur noch die 256 Gigabyte-Variante angeboten. – Um nun auf den Punkt zu kommen: Von den unterschätzten 64 Gigabyte sind nun nach drei Jahren noch 6,4 Gigabyte frei, und die insgesamt noch verfügbaren 198,4 Gigabyte machen nun für mich endlich richtig Sinn.
Anstatt furchtbarer HTML-WebApps um Audio-/Video-Dateien bearbeiten und konvertieren zu können, jetzt die Kraft von FFmpeg auf der Shell. Statt herumfummeln mit Browser und Apps wie Documents, Dateien mit wget herunterladen. Oder anstatt Geld für eine grafische App zahlen zu müssen, um Python-Code in einem Interpreter ausführen zu können, mit der Gefahr, dass numerische Ergebnisse ungewöhnlich ausgegeben werden, der originale Interpreter wie ich ihn von jeder Unix-Konsole her kenne.

Apple! – Dafür dass Ihr berechtigterweise es tatsächlich geschafft habt, mich für 192 Gigabyte zusätzlichen Flashspeicher um weitere 170,- Euro über den Tisch zu ziehen, verzeihe ich euch dafür ein wenig, weil ihr euch bezüglich des Sideloading-Verbotes von Theodore Dubois austricksen habt lassen. – Ich hoffe, ihr überlegt es euch nicht noch einmal anders und schmeißt iSH eben nicht wieder dafür aus dem App Store!

Jetzt noch zum Schluss das kurze HowTo, wie sich nach dem Download von iSH weitere Linux-Pakete installieren lassen.:

  1. wget http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86/apk-tools-static-2.10.5-r1.apk
  2. tar xf apk-tools-static-2.10.5-r1.apk sbin/apk.static
  3. ./sbin/apk.static add apk-tools
  4. rm sbin/apk.static

Links:
https://ish.app
iSH auf GitHub
iSH im Apple iOS App Store
Alpine Linux (engl. Wikipedia)
Projektseite Alpine Linux
Übernahme von TestFlight durch Apple (TechCrunch)
FFmpeg (engl. Wikipedia)
Wget (engl. Wikipedia)
Python (engl. Wikipedia)

Netzwerk-Bridge unter Linux mit TUN/TAP

Seit längerem trage ich bereits das Projekt in meinem Kopf herum, einen Mainframe-Computer der VAX-Reihe von Digital Equipment Corporation (kurz DEC) zu emulieren und auf diesem emulierten System wiederum das auch von DEC dazu entwickelte ‚Virtual Memory System‘ (kurz VMS später OpenVMS) als Betriebssystem zu installieren um damit ein wenig herum zu spielen. Ich habe aber bereits NetBSD, das ebenfalls von DEC entwickelte und proprietäre Unix Ultrix, als auch OpenVMS auf die emulierte Maschine kurz installiert. Nur waren diese Unternhmungen eher halbherzig, denn eine wichtige Komponente hatte ich bisher nie mit einbezogen. Nämlich die Netzwerkfähigkeit eines dieser Systeme. Ohne Netzwerk ist so eine emulierte Maschine zwar schön zum anschauen und herum probieren, aber sie verharrt weiterhin als eine Art Insellösung, wie früher, als die Computer in den häuslichen Wohnstuben noch nicht mit einem (Drahtlos-) Netzwerk verbunden waren und selbst das Internet mittels eines Modemzugangs noch teuer und keine Selbstveständlichkeit waren. Erst die Kommunikation von Computern untereinander macht sie flexibel und nochmals interessanter. Mit einer Netzwerkanbindung lassen sich Betriebssystem und Programme updaten oder gar upgraden, Dateien und Nachrichten hin und her übertragen und eigene Dienste anbieten.

Die Möglichkeit der Netzwerkkonnektivität ist aus meiner Sicht zumindest bei der Desktop-Virtualisierung eine recht einfache Sache. Denn die VMWare’s, Parallels und VirtualBox’es dieser Welt richten während ihrer Installation eine Netzwerkbridge in Software für das Wirtssystems automatisch mit ein, da sie die nötigen Treiber bereits mitbringen. So kann für eine virtuelle Maschine der Bridge-Modus zum direkten Zugriff auf ein physikalisches Netz, ein geteiltes Subnet mit NAT für mehrere virtuelle Maschinen untereinander oder eine Peer-To-Peer Verbindung zum Wirtssystem angeboten werden.

Bei der Emulationssoftware simh ist das etwas anders. Das Programm bringt keinen eigenen Treiber für eine Netzwerkbridge mit. Das Programm selber ist zwar netzwerkfähig, aber es ist nötig einen virtuellen Netzwerk-Kernel-Treiber wie TUN/TAP zu installieren, um die Netzwerkgeräte zu simulieren.

TUN simuliert dabei ein Ende-zu-Ende-Netzwerkgerät (ISO OSI-Schicht 3) und kommuniziert mit IP-Paketen mit der Software, während TAP eine Punkt-zu-Punkt-Verbindung mittels Ethernet-Gerät simuliert (ISO OSI-Schicht 2) und über Ethernet-Frames mit der Software kommuniziert.

In meinem DokuWiki habe ich einen ersten Workaround zur Erstellung einer Netzwerk-Bridge unter Linux mit TUN/TAP erstellt.:
Netzwerk-Bridge mit TUN/TAP für eine Computer-Emulation

Links:
TUN/TAP (engl. Wikipedia)
TUN/TAP (Projektseite auf source forge)
SIMH (dt. Wikipedia)
DEC VAX (engl. Wikipedia)
DEC OpenVMS (engl. Wikipedia)
Ultrix (engl. Wikipedia)
NetBSD (dt. Wikipedia)

Teletext auf dem Raspberry Pi generieren

Im Herbst 2018 veröffentlichte der Heise-Verlag zum ersten Mal das Sonderheft c’t-Retro. Neben den Themen zu alten Computern wie den ZX Spectum oder Commodore C64 sowie anderen Technik-Bereichen der IT aus der Sicht längst vergangener Tage, hatten die Redakteure ein Raspberry Pi Projekt vorgestellt, mit dem es möglich ist, selber den Fernseh-Teletxt zu erstellen und auszugeben.

Teletext, hier in Deutschland eher unter dem Begriff Videotext bekannt, ist ja das textuelle Zusatzangebot der Fernsehsender für die eigenen Programminformationen, sowie aktuelle Sportergebnisse und Nachrichten. Übertragen wird der Teletext mit dem PAL-Normsignal in der Austastlücke.

Zum Nachbau des Projektes braucht es nicht viel an Hardware. Glücklicherweise habe ich noch einen Raspberry Pi der ersten Generation mit einer Buchse für den Composite Video Cinchstecker. – Die neueren Generationen haben statt der Chinchbuchse nur einen GPIO-Pin für die analoge Videoausgabe. Mein elektronischer Aufbau ist daher recht übersichtlich.:

Am Composite-Ausgang des Raspberry Pi’s geht ein Chinchkabel auf den Adapter für S-Video und Composite meines Elgato TV-Hybrid DVB-T USB-Sticks. Der DVB-T Stick ist also der „Fernseher“, der mit seiner Fernseh-Software EyeTV das PAL-Signal wieder als Bild ausgibt.
Der Raspberry Pi selber besitzt in seiner jetzigen finalen Aufbaustufe eine SD-Karte mit einem Respbian-Linux für die Teletext-Software und einen kleinen USB-WiFi-Dongel, um sich auf ihn über W-LAN zu administrativen Zwecken mittels SSH verbinden zu können.

Ist der Raspberry Pi so konfiguriert, dass die Bildschirmausgabe über das PAL-Signal an den „Fernseher“ geht und eine USB-Tastatur direkt am Raspberry Pi angeschlossen ist, dann fällt direkt die enorme Latenz auf, die durch den analogen Umweg entsteht. Ist der Raspberry Pi über seinen HDMI-Ausgang an einem gewöhnlichen Computerbildschirm angebunden, besteht die enorme Latenz nicht.
Wird dann der Teletext-Dienst VBit2 gestartet, so ist über die Teletext-Taste des „Empfangsgerätes“ der Videotext, der aus den vorinstallierten Tafeln besteht, zu sehen und es lässt sich wie bei den klassischen Fernsehsendern durch ihn hindurch navigieren.
Es gibt aber bereits eine Teletext-Tafel, in der die Temperatur des ARM-Chips und die lokale IP-Adresse des Rasperry Pi’s ausgelesen und angezeigt werden.
Die c’t-Redaktion hatte sich dann entsprechende Tafeln erstellt, mit denen die Meldungen und Nachrichten aus dem Heise-Newsticker als Teletxt abgerufen werden können.

In meinem Wiki habe ich eine entsprechende Installationsanleitung erstellt, wie die Software VBit2 auf dem Raspbian zu installieren ist.
Link: http://sommteck.net/wiki/doku.php?id=linux:vbit2_teletext-generator

Sobald ich meine ersten eigenen Gehversuche bei dem Erzeugen eigener Teletext-Tafeln erfolgreich durchschritten habe, werde ich dazu ein Update schreiben.

Update 05. April 16:05 Uhr:

Von der genannten Teletext-Tafel, in der die Temperatur des ARM-Chips und die lokale IP-Adresse des Rasperry Pi’s ausgelesen und angezeigt werden kann, gibt es natürlich auch ein Foto. Ich habe alle Bilder in einer eigenem Album.:
Link Fotoalbum VBit2

Links:
Heise c’t-Artikel: Teletext auf dem Raspberry Pi generieren
Links Teletext auf dem Raspberry Pi generieren
Projekt Heise Raspi Newstext (Github)
Teletext Page Editor im Browser
Teletext (dt. Wikipedia)
Raspberry Pi (dt. Wikipedia)
Composite Video (dt. Wikipedia)
Geniatech EyeTV (ehemals Elgato)