Zum Hauptinhalt Zur Navigation

Bootet fast fünf Tage: Entwickler bringt Linux auf Intel 4004 zum Laufen

Zwei selbst entwickelte Emulatoren , ein Decoder für einen Logic-Analyzer und ein Haufen alter Chips: Mehr braucht es nicht, um Linux auf Intels 4004 laufen zu lassen.
/ Johannes Hiltscher
19 Kommentare News folgen (öffnet im neuen Fenster)
Der Großteil der Chips auf der Platine sind echte und teure Antiquitäten. (Bild: Dmitry Grinberg)
Der Großteil der Chips auf der Platine sind echte und teure Antiquitäten. Bild: Dmitry Grinberg

Dmitry Grinberg hat ein Faible dafür, Linux auf möglichst eingeschränkten Plattformen zum Laufen zu bringen: 2012 schaffte er das auf einem AVR-Mikrocontroller von Atmel(öffnet im neuen Fenster) , andere Entwickler zogen etwa mit Linux auf dem C64 nach. Grinberg wollte seinen selbst verliehenen Rekord für die spartanischste Linux-Plattform zurückerobern und setzte sich als neues Ziel den ersten Mikroprozessor: Intels 4004 (g+) .

Tatsächlich gelang es dem Entwickler, wie er in einem umfangreichen und sehr lesenswerten Blog-Post(öffnet im neuen Fenster) beschreibt, ein Debian-Abbild mit abgespecktem Linux-Kernel 4.4.292+ auf dem 4-Bit-Prozessor zu booten. Da der 4004 dafür viel zu simpel ist, läuft darauf ein Emulator. Emuliert wird ein MIPS R3000(öffnet im neuen Fenster) , der etwa in der DECstation 2100 verbaut war. Grinberg entschied sich für diese Architektur, da sie die wenigsten Sonderfälle aufweist und damit am einfachsten zu emulieren sein sollte.

Trotz Übertaktung auf 790 kHz macht die aufwendige Emulation Linux auf dem 4004 allerdings zum Geduldspiel: Der Boot-Prozess dauert 4,81 Tage, Grinberg hat ihn in einem Video dokumentiert. Allein den Kernel über SPI (Serial Peripheral Interconnect) von einer SD-Karte zu laden, dauert fast vier Stunden.

Ein Computer als Kunstobjekt

Grinberg hat dabei versucht, so weit wie möglich ohne moderne Chips auszukommen. Den Zustand des emulierten R3000 speichern originale 4002 DRAMs von Intel, sie erzeugen auch Takt und Ausgabesignale für die verbauten SPI-Komponenten.

Damit kommt das Design ohne moderne Komponenten wie FPGAs oder Mikrocontroller zur Übersetzung des 4004 Bus aus: Intels Schnittstellenchip 4289 bindet einen EEPROM-Chip an und wandelt die Pegel der von den SPI-Geräten zurückgelieferten Signale. Er gehört, wie auch die 4002 und diverse andere Chips, zu Intels MCS-04 Portfolio (kurz für Micro Computer System). Der 4289 wandelt zwischen den beim 4004 verwendeten ungewöhnlichen Spannungspegeln von -15 und 0 V und den üblicheren 0 und 5 V, mit denen sich auch modernere EEPROMS ansprechen lassen.

Da das System keinen praktischen Sinn hat, sieht Grinberg es als Kunstobjekt. Unter diesem Gesichtspunkt hat er auch eine Platine für seinen Computer entworfen: mit Durchsteckkomponenten, rechtwinklig verlaufenden Leiterbahnen und einlagig. Bei einigen Komponenten entschied er sich allerdings für pragmatische Lösungen: Sowohl die als Arbeitsspeicher genutzten Pseudo-SRAMs (PSRAMs) als auch der RS-232-Schnittstellenchip sind SMD-Komponenten. Auch die SD-Karte für das Dateisystem sowie die Spannungsversorgung über USB-C passen nicht ganz in den angestrebten 1970er-Look – das Vakuum-Floureszenz-Display für die Konsolenausgabe hingegen ist da schon näher dran.

Interessierte können den von Grinberg entworfenen Computer nachbauen, der Entwickler überlegt, ihn als Kit anzubieten. Allerdings müssten die alten Intel-Chips selbst beschafft werden. Und die sind, wie Grinberg schreibt, nicht günstig: Für einen 4004 würden bei Ebay etwa 250 US-Dollar fällig, der ebenfalls nutzbare Nachfolger 4040 liegt bei lediglich 60 US-Dollar. Insgesamt würden für die Intel-Chips aber mehrere Hundert US-Dollar fällig.

Bis zur Platine war es allerdings ein weiter Weg.

Entwicklung mit Rückschlägen

Bevor er eine Platine entwarf, probierte Grinberg erst einmal aus, ob sein Projekt überhaupt machbar ist. Dazu entwickelte er erst einmal einen Emulator für das System, das er im Kopf hatte. Der läuft auf einem normalen PC und diente dem Entwickler dazu, den R3000-Emulator in Assembler zu programmieren und zu testen.

Sein ursprüngliches Ziel, den Emulator in die 4.096 Byte zu packen, die der 4004 als ROM einfach adressieren kann, erreichte er allerdings nicht. Die ROM-Menge zu verdoppeln, bedeutete zwar einigen Aufwand, eröffnete aber auch neue Möglichkeiten: So konnte der Entwickler etwa Funktionen für die Emulation boolescher Operationen oder der Multiplikation über Look-up-Tabellen realisieren. Hier kann direkt das Ergebnis aus dem Speicher gelesen werden, anstelle es aufwendig zu berechnen, was die Emulation deutlich beschleunigte.

Ein Prozessor mit Eigenheiten

Grinberg gibt zudem einen knappen, aber umfassenden Überblick über die Funktionalität des 4004. Der weist, verglichen mit moderneren Prozessoren, einige Besonderheiten auf: So gibt er etwa bei Speicheroperationen einen Teil des Befehlscodes (Op-Code) auf den lediglich vier Bit breiten Bus aus. Speicherbausteine können dabei eigene Logik enthalten, um anhand des übertragenen Teils des Op-Codes zu entscheiden, was zu tun ist. Nur so erfahren etwa RAM-Bausteine, ob Daten gelesen oder geschrieben werden sollen.

Zugriffe auf den RAM sind beim 4004 auch deutlich komplexer als bei moderneren Prozessoren. Bei der Ausführung von Befehlen sind keine Zyklen für eine Ausgabe von Adressen vorgesehen. Daher muss über einen Befehl erst einmal ein Teil der Adresse an einen zuvor ausgewählten Speicherbaustein übertragen werden, der ihn intern puffert. Erst danach kann mit einem weiteren Befehl gelesen oder geschrieben werden.

Der Bus wird zudem für jegliche Interaktion mit externen Chips, wie RAM und ROM, genutzt, überträgt also Adressen, Daten und die 8-Bit-Befehle. Interessant ist auch, dass Intel die Register des 4004 mit dynamischen anstatt statischem RAM implementiert hat. Grinberg rechnet vor, dass eine SRAM-Implementierung für die insgesamt 112 Bit 672 Transistoren benötigt hätte – insgesamt kommt der Prozessor nur auf 2.300. DRAM-Zellen hingegen benötigen nur einen Transistor pro Bit.

Die aufwendige Speicheradressierung beschreibt Grinberg als größte Herausforderung bei der Emulation. Jeder Zugriff benötigt nicht nur oft mehr als einen Befehl, es gibt auch noch einige Randbedingungen zu beachten.


Relevante Themen