- Debian Linux bootet auf einem realen Board, das den 4-Bit-Intel 4004 von 1971 als einzige CPU verwendet, und zeigt damit sowohl die Grenzen alter Mikroprozessoren als auch das Extrem softwareseitiger Schichtung
- Linux läuft nicht direkt auf dem 4004, sondern bootet auf einem in 4004-Assembler geschriebenen MIPS-R3000/DECstation-2100-Emulator; Festplatte und Teile der Konsole werden durch Hypercalls und paravirtualisierte Treiber vereinfacht
- Wegen des 4-KB-ROM-Limits, 4-Bit-Operationen, fehlender Logikoperationen, eines flachen Call-Stacks und der ungewöhnlichen Adressierung des 4002-RAMs waren Umgehungen wie ROM-Banking, Lookup-Tabellen, Status-Nibbles und PSRAM-basiertes virtuelles RAM nötig
- Nach der Optimierung beträgt die geschätzte Linux-Bootzeit auf einem echten 4004 mit 740 KHz 4,76 Tage; das gebaute Board ist auf 790 KHz übertaktet, wodurch der virtuelle MIPS mit etwa 74,73 Hz läuft
- Das Ergebnis wurde als an die Wand hängbares Retro-Art-Board entworfen und bietet ein 40x2-VFD, 32 PC-LEDs, SD-Karte, SPI-PSRAM und UART; Quellcode und Disk-Images werden unter einer nicht-kommerziellen Nutzungsbedingung veröffentlicht
Debian Linux auf einem echten 4004 booten
- Linux/4004 ist ein Projekt, das Debian Linux auf einem realen Board bootet, das den Intel 4004 von 1971 als einzige CPU verwendet
- Der 4004 wird als weltweit erster in Serie produzierter Mikroprozessor vorgestellt, und im Projekt kommen echte Intel-4004-Chips aus den 1970er-Jahren zum Einsatz
- Das Demo-Video wurde abschnittsweise mit variabler Geschwindigkeit versehen, damit es weniger langweilig ist; Uhr und Kalender im Bild sind korrekt
- Zusätzlich wird ein separates, originalgetreues Video bereitgestellt, das mit konstanter Geschwindigkeit abgespielt wird
Warum der 4004?
- 2012 wurde Linux auf einem 8-Bit-AVR-Mikrocontroller ausgeführt und damit der Rekord „Linux auf der niedrigsten Spezifikation ausführen“ aufgestellt; später folgte auch das praktischere Projekt LinuxCard
- 2023 erschienen ein Versuch, den AVR-basierten Rekord zu brechen, sowie ein Projekt, Linux auf einem MOS 6510 zu booten, wodurch eine noch niedrigere CPU-Klasse zum Ziel wurde
- Um noch weiter zurückzugehen als die Kandidaten Intel 8080 und 8008, fiel die Wahl auf den Intel 4004 von 1971
- Der 4004 ist ein 4-Bit-Chip und setzt damit klar eine niedrigere Messlatte als 8-Bit-CPUs
Einschränkungen des Intel 4004
- Der 4004 arbeitet in 4-Bit-Einheiten, und die meisten Befehle sind 1 Byte groß und werden in 8 Taktzyklen ausgeführt
- Einige 2-Byte-Befehle benötigen 16 Zyklen
- FIN ist ein Ausnahmefall: ein 1-Byte-Befehl, der dennoch 16 Zyklen braucht
- Im Befehlssatz fehlen Logikoperationen wie AND, OR, XOR; im Kern ist er auf ADD und SUB ausgerichtet
- Das Carry-Flag verhält sich auf ungewöhnliche Weise: bei SUB-Eingaben wie Borrow, nach SUB wie Not-Borrow; das wurde auf echter Hardware verifiziert
- Intern gibt es 16 Register mit 4 Bit, der PC ist 12 Bit breit, und der Hardware-Return-Stack hat 4 Ebenen
- Da der aktuelle oberste Stack-Eintrag als PC verwendet wird, sind effektiv nur maximal 3 verschachtelte Funktionsaufrufe möglich
- Interrupts gibt es nicht; dem Umgang mit externen Ereignissen kommt am nächsten, den TEST-Pin in bedingten Sprüngen per Polling abzufragen
Speicher- und I/O-Struktur
- Der 4004 verarbeitet Speicherbefehle nicht selbst direkt; stattdessen dekodieren und führen Chips wie 4001/4002/4289/4265/4308, die am Bus hängen, diese aus
- Der 4001 ist ein ROM-Chip mit 256 Byte Mask-ROM und einem 4-Bit-I/O-Port; ROM-Inhalt und I/O-Port-Konfiguration werden bei der Herstellung festgelegt
- Der 4002 ist ein RAM-Chip mit 320 Bit DRAM, Refresh-Schaltung und einem 4-Bit-Ausgabeport
- Eine RAM-Bank kann aus 4 Stück 4002 bestehen
- Jede RAM-Bank hat 256 direkt adressierbare Nibbles und zusätzlich 64 separat zugängliche Status-Nibbles
- Der 4289 ist ein ROM-Controller, der die Funktionen von 4008 und 4009 kombiniert und den 4004 relativ einfach mit 5V-EEPROM/EPROM verbindet
- Speicherzugriffe erfordern ein mehrstufiges Verfahren wie Bank-Auswahl, Laden der Adresse in ein Registerpaar, Übertragung der Adresse auf den Bus mit SRC und Ausführung von RDM/WRM
- Die Status-Nibbles waren nützlich, um häufig genutzte Daten schnell zu erreichen, und trugen zu einer Leistungssteigerung des MIPS-Emulators um etwa 30 % bei
Entwicklungsboard und Vorbereitung des Emulators
- Das frühe Entwicklungsboard zur Verifikation bestand aus einem 4201-Clock-Generator, einer 4004-CPU, 4002-1-RAM, einem 4289-ROM-Controller und einem ATMEGA48 in der Rolle des ROMs
- Die Stromversorgung beginnt bei 5 V; durch Erdung des positiven Pols eines isolierten 5V-zu-10V-Boost-Converters wurde eine -10V-Versorgung für die MCS-04-Chips erzeugt
- Das erste 4004-Programm war Code, der eine an 4002 Output Pin 0 angeschlossene LED blinken ließ, und funktionierte nach Anhebung der Strombegrenzung
- Vor dem Bau des eigentlichen Boards wurde ein 4004-Emulator namens u4004 geschrieben
- Er emuliert nicht nur den 4004-Kern, sondern auch eine virtuelle SD-Karte, SPI-UART, VFD, die 4002-Anordnung und PC-LEDs
- Er diente dazu, Zustände der SPI-Pins und das Verhalten der Peripherie vorab zu prüfen, die sich auf echter Hardware nur schwer debuggen lassen
MIPS emulieren statt Linux direkt auszuführen
- Linux kann nicht direkt auf dem 4004 ausgeführt werden
- Es gibt keinen C-Compiler für den 4004, und aufgrund der Architekturgrenzen wurde entschieden, dass sich der Linux-Kernel nicht direkt darauf portieren lässt
- Verschachtelte Aufrufe, ROM/RAM-Adressraum und die Grenzen von 4-Bit-Operationen verhindern eine direkte Ausführung
- Stattdessen wurde ein MIPS R3000-Emulator auf dem 4004 geschrieben, auf dem anschließend Linux für die DECstation 2100 bootet
- MIPS wurde gewählt, weil sich die Architektur im verfügbaren 4004-Code-Raum leichter emulieren ließ als andere Kandidaten
- ARM hat viele beliebige Shift-Operanden
- Bei RISC-V wurde wegen der Adressierungsart mit geringerer Geschwindigkeit gerechnet
- Bei x86 könnte allein das Dekodieren der Befehle 4 KB überschreiten
- PPC ist zu komplex
- Das anfängliche Ziel war, den kompletten Emulator in das vom 4004 grundsätzlich adressierbare 4-KB-ROM zu packen
Umgehungen bei der Implementierung des MIPS-Emulators
- Schon das Dekodieren der MIPS-Befehle verbraucht beträchtlichen ROM-Speicher
- Eine Dispatch-Tabelle mit 64 Top-Level-Opcodes benötigt 128 Byte
- Einschließlich zusätzlicher Sub-Tabellen wurden für das wesentliche Dekodieren 359 Byte benötigt
- Die 32 Register von MIPS mit jeweils 32 Bit ergeben 1024 Bit, also aus Sicht des 4004 256 Nibbles, und belegen damit eine ganze RAM-Bank
- Die MIPS-TLB hat ursprünglich 64 Einträge, wurde aber auf 16 Einträge reduziert, da Linux nicht exakt 64 verlangt
- Die Zahl der TLB-Einträge wurde so ausgelegt, dass auch Konfigurationen mit 4, 8, 12 oder 16 Einträgen möglich sind
- Da dem 4004 Logikoperationen fehlen, werden AND/OR/XOR/NOR mit Addition und Carry, Shifts und Schleifen umgesetzt
- Später wurde dies nach Vergrößerung des ROM-Speichers mit einer Lookup-Tabelle mit 256 Einträgen optimiert
- Auch Shifts mussten zunächst nur mit den 1-Bit-Rotationsbefehlen des 4004 über Carry umgesetzt werden und wurden später durch Kopieren auf Nibble-Ebene plus bis zu 3 Bit-Shifts verbessert
- Die Behandlung des MIPS-Registers
$zerospart ROM-Speicher, indem die zirkuläre Return-Stack-Eigenschaft des 4004 genutzt wird- Wenn das Ziel
$zeroist, wird nicht zurückgesprungen, sondern direkt zur Verarbeitung des nächsten Befehls übergegangen; das spart pro Callsite 3 Byte und 3 Zyklen
- Wenn das Ziel
ROM-Banking und Leistungsverbesserungen
- In 4 KB ROM ließ sich nicht auch noch der Code für SD-Karte, PSRAM, VFD und UART unterbringen, daher wurde ein 8-KB-ROM in zwei Bänke aufgeteilt verwendet
- Der Wechsel der ROM-Bank wird über einen 4002-Output-Pin gesteuert; für Calls und Returns zwischen den Bänken wurden Veneers eingesetzt
- Mit dem zusätzlichen ROM-Speicher wurden Leistungsoptimierungen möglich
- AND/OR/XOR werden jeweils über eine Lookup-Tabelle mit 256 Einträgen umgesetzt
- Mit einer Lookup-Tabelle für Nibble-Multiplikation wurde die Multiplikation gegenüber der früheren bitweisen Implementierung um das Achtfache beschleunigt
- Die Lookup-Tabelle für Logikoperationen nutzt die Eigenschaft des 4004, dass JIN am Ende einer ROM-Seite relativ zur nächsten Seite springt
- Die Multiplikationstabelle wurde durch die Kombination aus dem Lesen von Byte-Daten aus dem ROM per FIN und dem Umgehen der Verarbeitung von 0-Einträgen umgesetzt
Endgültige Hardware-Konfiguration
- Die finale Platine wurde als Art-Board mit Fokus auf Through-Hole-Bauteile im Stil der 1970er Jahre entworfen
- mit dicken rechtwinkligen Leiterbahnen, ohne Vias, mit Löchern zur Wandmontage und einer VFD-Anzeige
- Die Hauptkomponenten sind:
- 4004- oder 4040-CPU
- 4201 clock generator
- 4002-RAM-Chips
- 4289 ROM controller
- EEPROM
- ein oder zwei SPI-PSRAMs
- SD-Karten-Slot
- SC16IS741A SPI UART
- 40x2 VFD
- 32 PC-Status-LEDs
- Das SPI-PSRAM wird als virtueller MIPS-RAM verwendet
- Das erste PSRAM muss mindestens 4 MB groß sein, da der Kernel fortlaufend geladen werden muss
- Das zweite PSRAM kann leer bleiben oder in beliebiger Größe ab 128 KB bestückt werden
- Als VFD wurde ein Futaba M402SD10FJ verwendet; als kompatibel wurde auch ein Noritake CU40025-UW6J genannt
- Als UART wurde das SMD-Bauteil SC16IS741A gewählt, da der als Through-Hole-SPI-UART infrage kommende MAX3100 Einschränkungen bei der Flusskontrolle hatte
Stromversorgung und Level Shifting
- MCS-04-Bauteile verwenden ungewöhnliche Spannungen im -15V-Bereich und inverted logic
- Systemseitig ist es einfacher, das als Versorgung mit -10V und +5V zu betrachten
- Die Platine erhält +5V über einen USB-C edge connector und erzeugt zusätzlich +3.3V sowie -10V
- Der +3.3V-Step-down-Regler basiert auf einem LM2574
- Die -10V-Versorgung wurde geändert, weil der im ersten Revision verwendete MAX764 nicht genug Strom liefern konnte; stattdessen kam ein MAX774 mit externem FET, großer diode und großer inductor zum Einsatz
- Am Ende lieferte die Schaltung mehr als 700 mA bei -10V, bei weniger als 200 mV ripple
- Das Level Shifting der 4002-Ausgänge in die 3.3V-Domäne war schwierig und wurde mit einer Kombination aus 10K-pulldown, 2.7K-Widerstand, TVS-clamp und Widerstands-Spannungsteiler gelöst
Debugging-Werkzeuge und tatsächlicher Defekt
- Da der 4004 keine integrierten Debugging-Funktionen hat, wurde der MCS-04-Bus über längere Zeit mit Saleae Logic aufgezeichnet
- Es wurde ein MCS-04-Busdecoder geschrieben, der Buszustand, ROM-Adresse, ROM-Lesewert, Disassembly sowie RAM-/I/O-Lese- und Schreibwerte analysiert
- Später wurde er zu Saleae beigetragen und in die allgemeine Saleae-Software aufgenommen
- Auf der Platine in Revision 1.1 gab es ein Problem, bei dem ausgegebene Zeichen gelegentlich beschädigt wurden
- Zum Beispiel erschien
ialshundCalsB, also verschwand jeweils das niederwertigste Bit
- Zum Beispiel erschien
- Die Analyse zeigte einen Defekt in dem 4002-Chip, der während des Kernel-
memcpy()den emulierten$t1speicherte: Das unterste Bit eines bestimmten nibble fiel gelegentlich von 1 auf 0 - Nach dem Austausch dieses 4002 war die Textausgabe wieder korrekt
Boot-Pfad
- Die Firmware prüft zunächst die Anzahl der Speicherchips in der dritten RAM-Bank, um die Zahl der TLB-Einträge zu bestimmen
- Danach initialisiert sie VFD, UART und SD-Karte
- Falls die Initialisierung der SD-Karte fehlschlägt, wird
"Failed to init SD card. Halting here and now!"angezeigt - Dieser String ist der einzige String in der gesamten Firmware
- Falls die Initialisierung der SD-Karte fehlschlägt, wird
- Die Firmware verwendet kein virtuelles ROM, sondern lädt den ersten Sektor der SD-Karte in den RAM bei
0x80000000und springt dann dorthin - Der 446-Byte-Loader im ersten Sektor sucht in der Partitionstabelle nach einer Partition vom Typ
0xBB, liest sie nach0x80001000und springt dorthin - Der zweite Loader ist etwa 14 KB groß und in C geschrieben
- er mountet die aktive Partition als FAT12/16/32
- er parst
vmlinuxals ELF, lädt es in den RAM und springt zum entrypoint - er übergibt machine type, magic value, RAM-Mapping und eine Callback-Tabelle für frühe Konsolenausgaben
Datenträger- und SD-Kartenzugriff
- Für den Datenträgerzugriff wird derselbe PVD-paravirtualisierte Festplattentreiber wie im LinuxCard-Projekt verwendet
- Statt einen SII-SCSI-Chip und eine SCSI-Festplatte in 4004-Assembly zu emulieren, arbeiten Hypercalls für Sektor-Lese- und Schreibzugriffe aus Sicht der virtuellen MIPS wie DMA
- Der gesamte RAM des Linux/4004-Boards umfasst 440 Byte einschließlich status nibble, beziehungsweise 352 Byte ohne diese
- Da MIPS-Registerzustand und TLB jeweils viel Platz belegen, bleibt kein Raum für einen 512-Byte-Sektorpuffer der SD-Karte
- SD-Sektordaten werden nicht im 4004-RAM abgelegt, sondern über einen separaten SPI-Bus von der SD-Karte direkt ins PSRAM gelesen oder vom PSRAM zur SD-Karte geschrieben
- Das Lesen oder Schreiben eines einzelnen SD-Sektors dauert etwas mehr als 1 Sekunde
- Die Timing-Anforderungen der SD-Spezifikation für die Initialisierung mit ACMD41 ließen sich mit bit-banging-SPI nicht einhalten, aber die getesteten SD-Karten wurden auch bei 5 KHz und Abständen von mehr als 200 ms initialisiert
Ausführungsgeschwindigkeit und Optimierungsergebnisse
- Nach der Emulation echter SD-Karten und SPI-PSRAMs lag die ursprünglich geschätzte Bootzeit bei 8,9 Tagen für einen 4004 mit 740 KHz
- Die wichtigsten Optimierungsergebnisse waren:
- logische Operationen und multiplication lookup table: 8,4 Tage
- Entrollen der PSRAM-Schleifen für nibble-Senden und -Empfangen: 7,25 Tage
- spezialisierte Speicherkopie und Schleifenentrollung: 6,63 Tage
- Entfernung des aktuellen Instruktionsspeicherbereichs und liveness tracking: 6,50 Tage
- Verbesserung von shift: 6,19 Tage
- Entrollen der Schleife zum Senden von PSRAM-Adressen: 6,01 Tage
- reduzierte Linux-kernel-config, dummy console 1x1 und tiny init: 5,33 Tage
- Entfernen der Unterstützung für Blockgeräte über 2 TB und Deaktivieren des ext4-Features
huge_files: 4,81 Tage - Fast Path nur für instruction fetch: 4,76 Tage
- Ein Boot in 4,76 Tagen entspricht bei einem 4004 mit 740 KHz ungefähr einer MIPS-Maschine mit 70 Hz
- Die gebaute Platine ist auf 790 KHz übertaktet; dafür wird der 4201 im divide-by-7-Modus mit einem 5.5296MHz-crystal betrieben
- Der 4004 instruction mix des Linux/4004-Boards besteht zu 8,8 % aus 16-cycle-Befehlen und zu 91,2 % aus 8-cycle-Befehlen; die effektive Geschwindigkeit liegt bei 90.640 instructions/s
- Der virtuelle timer interrupt läuft mit 16 Hz und liefert alle 65.536 virtuellen Instruktionen einen IRQ, sodass die virtuelle CPU 1.05MHz wahrnimmt
- Der tatsächlich emulierte MIPS-Gast läuft bei 740 KHz mit etwa 70 Hz und bei 790 KHz mit etwa 74,73 Hz
- Die Zeit wird um den Faktor 14.030 gedehnt; 1 virtuelle Sekunde entspricht in der Realität etwa 3 Stunden und 54 Minuten
Linux-Konfiguration und Nutzungserfahrung
- Der Linux-kernel wurde durch Entfernen unnötiger Subsysteme, Dateisysteme, TCP/IP und anderer nicht benötigter Einstellungen auf etwa 2,5 MB reduziert
- Wenn nur
init=/bin/shverwendet wird, fehlen Session,$PATH,/proc,/sysund anderes; deshalb wurde mit/sbin/uMIPSinitein tiny init geschrieben- Es mountet
/procund/sys - Es setzt Hostname und
$PATH - Es startet
shjedes Mal neu, wenn es beendet wird
- Es mountet
- Schon mit 4,5 MB RAM, etwa einem 4-MB-Chip plus einem 512-KB-Chip, lässt sich ohne Swap bis zur Shell-Eingabeaufforderung booten
- Mit aktiviertem Swap kann auf dem Gerät selbst der Kernel-Sourcecode gebaut werden
- Der Build des Kernel-Sourcecodes wird voraussichtlich Jahre dauern
- Dank des ext4-Journals ist geplant, nach Stromausfällen das Dateisystem nach dem Neustart zu reparieren und die Kompilierung fortzusetzen
Ziel als Art-Board
- Dieses Projekt verfolgte von Anfang an teilweise ein künstlerisches Ziel
- Die Platine wurde für die Wandmontage entworfen und besitzt ein VFD, ein PCB-Layout im Retro-Stil und PC-LEDs
- Enthalten ist ein Programm, das auf dem VFD und über den seriellen Port die Mandelbrot-Menge im Textmodus zeichnet
- Die Gleitkomma-Version
/root/mandelbrotbraucht etwa 30 Tage für ein 13-Zeilen-x-40-Spalten-Bild, da Linux die Gleitkommaoperationen emulieren muss - Die rein ganzzahlige Version
/root/mandelbrot_nofpist in weniger als 9 Stunden fertig
- Die Gleitkomma-Version
Kosten der Bauteile und Reproduzierbarkeit
- Da ein wichtiges Ziel war, dass andere das System nachbauen können, wurde der schwer zu beschaffende 4265 vermieden
- Der 4201 wurde gewählt, weil er einfacher als alternative Clock-Schaltungen ist, und der 4289, weil er leichter zu bekommen ist als die Kombination aus 4008+4009
- Die Platine wurde so entworfen, dass statt des 4004 auch ein 4040 eingesetzt werden kann; da die Zusatzfunktionen des 4040 nicht genutzt werden, bleibt die 4004-Kompatibilität erhalten
- Für den TLB können 1, 2, 3 oder 4 Chips vom Typ 4002 bestückt werden, sodass sie sich jeweils als TLB mit 4, 8, 12 oder 16 Einträgen nutzen lassen
- Eine geringere Zahl an TLB-Einträgen verschlechtert die Leistung
- Die betreffende Bank ist auch für die oberen 16 Bits der PC-Display-LEDs zuständig; bei nur teilweiser Bestückung funktionieren daher einige LEDs nicht
- Bauteile aus den 1970er-Jahren sind teuer
- 4004: etwa $250
- 4040: etwa $60
- 4201: etwa $50
- 4002-1: etwa $7
- 4002-2: etwa $25
- 4289: etwa $70
- Moderne Bauteile sind vergleichsweise günstig; das SPI-VFD kann zwar schwer zu bekommen sein, wurde in einem Fall aber für $15 bei eBay beschafft
- Es wird auch eine Konfiguration unterstützt, die ohne VFD auskommt und nur über den serial port bedient wird
Entstehung des Videos
- Die eigentliche Boot-Sequenz wurde über rund 9 Tage hinweg fotografiert und daraus ein Video erstellt
- Bei 1920x1080-Fotos alle 2 Sekunden entstehen etwa 1,76 GB pro Stunde; 9 Tage Aufnahme ergeben etwa 379 GB und rund 388.000 Dateien
- Android-Geräte hatten bei langen Aufnahmen Probleme mit Hängern oder Überhitzung, und ein iPhone SE3 war zwar beim Fotografieren selbst stabil, hatte aber Probleme mit Speicherplatz und dem Offload der Fotos
- Letztlich wurde ein iPhone 12 Pro Max mit 512 GB verwendet, um alles durchgehend aufzunehmen; anschließend wurde es unter Linux per ifuse gemountet und mit
cp -Rvfüber mehr als 10 Stunden rund 400.000 Dateien kopiert - Das fertige Video wurde mit ffmpeg-Befehlen erstellt, und langweilige Abschnitte wurden mit variabler Geschwindigkeit verarbeitet
- Die Wiedergabegeschwindigkeit reicht von 5 FPS, also 10x Echtzeit, bis 960 FPS, also 1920x Echtzeit
- Eine separate ungeschnittene Version läuft mit 0,5 FPS Aufnahme und 60 FPS Wiedergabe, also mit 120x Echtzeit
Veröffentlichte Materialien und Lizenz
- Ein disk image für die SD-Karte wird als separater Download bereitgestellt
- Der Hauptdownload enthält Folgendes
- MCS-04-Bus-Analyzer für die Saleae-Software
- i4004 DECstation 2100 emulator source
- MIPS-MBR- und Second-Stage-Bootloader-Source
- kernel config und Versionsinformationen
- u4004 emulator source für das Linux/4004-Board
- Die Lizenz ist für nichtkommerzielle Nutzung kostenlos; für kommerzielle Nutzung ist eine separate Lizenz erforderlich
- Bei jeder Nutzung muss der ursprüngliche Ersteller sowohl in Source- als auch in Binary-Form genannt werden
2 Kommentare
Der Autor des Originalbeitrags ist also jener Typ, der diesmal auf der DEF CON wegen der Badge-Sache von der Bühne geholt wurde. Ich will mich auf keine Seite schlagen, aber seine Fähigkeiten sind trotzdem wirklich beeindruckend.
Hacker-News-Kommentare
Wow, ich dachte schon, modernes NetBSD sei auf einem 15-MHz-m68030 mit 16-Bit-Speicherbus und 10 MB RAM langsam, aber das hier ist wirklich irre.
Das zeigt sehr gut, dass Computer Ende der 80er bis Anfang der 90er im Grunde beim modernen Computing angekommen waren, als sie dauerhaften Speicher, offene Adressräume und MMUs bekamen.
Ein Amiga 3000 oder ein i80486-Rechner kann ebenfalls dieselben Dinge ausführen wie moderne Computer; heute läuft alles viel schneller oder es gibt Dinge wie GPUs, die es damals nicht gab, aber funktional ist der Unterschied nicht groß.
Schön zu sehen, wie locker Dmitry das Wort funktional auslegen kann.
Die Züge wurden tatsächlich per Post verschickt, und eine Partie konnte Monate oder Jahre dauern.
Bis die Antwort kam, konnte man die ursprüngliche Strategie vergessen haben, was dem Schach noch eine weitere Schwierigkeitsebene hinzufügte; dieses Projekt ist im Grunde Fern-Linux.
Bis die Ausgabe eines Befehls erscheint, hat man vielleicht vergessen, warum man ihn ausgeführt hat.
Nicht erst Ende der 80er bis Anfang der 90er, sondern eigentlich schon gegen Ende der 1960er wäre das möglich gewesen.
Linux auf ein IBM Model 67 [1] zu portieren, scheint mir ebenfalls möglich; da GCC diese Befehlssatzarchitektur bereits als Ziel haben kann, könnte es sogar einfach sein.
Die MMU reicht aus, und die Beschränkung auf maximal 2 MB schnellen Kernspeicher wäre zwar hart, aber ungefähr in derselben Klasse wie diese 68030-Maschine, nur etwas langsamer.
Vollständige Virtualisierung und durch Hardware erzwungene Grenzen für Speicher und Ein-/Ausgabe wurden ebenfalls früh erfunden, aber es dauerte, bis solche Funktionen in Minicomputer und Mikrocomputer hinunterwanderten, und noch viel länger, bis verbreitete Software sie nutzte.
[1] https://en.wikipedia.org/wiki/IBM_System/360_Model_67
Jedes turing-vollständige System kann alles ausführen; es kann extrem langsam sein, aber es läuft.
Mit genug Zeit könnte man auch ChatGPT auf einem 4004 laufen lassen.
Das ist etwa so, als würde man ein Auto an ein Rad hängen und bekäme dadurch drei weitere Räder.
Das Teilnehmer-Badge der Hackaday Supercon 2002 (https://hackaday.com/2022/10/12/the-2022-supercon-badge-is-a...) implementierte eine virtuelle 4-Bit-CPU und ein Bedienpanel, über das man Befehle direkt eingeben, ausführen und schrittweise ausführen konnte.
Auf dem Bedienpanel gab es eine Anzeige, auf der man eine Speicherseite bitweise sehen konnte; darauf einen Weltraum-Shooter zu implementieren, hat wirklich Spaß gemacht.
Die Voya4-Architektur mit dem 4004 zu vergleichen, war ebenfalls interessant; es gab ähnliche Kompromisse, aber Voya4 profitiert von 50 Jahren Erfahrung mit CPU-Befehlssätzen.
Allerdings würde dimitygrs Ansatz auf diesem Badge nicht funktionieren, weil Speicher und RAM beide in den PIC24 integriert sind, der den CPU-Emulator implementiert.
Nebenbei: 4-Bit-CPUs werden immer noch hergestellt und verwendet. Viele in Massenproduktion gefertigte Infrarot-Fernbedienungen sind mit 4-Bit-MCUs programmiert. Das Datenblatt findet man unter https://www.emmicroelectronic.com/sites/default/files/produc....
Wenn ich gefragt wurde, ob man auf einer zu schwachen Maschine etwas zum Laufen bringen kann, habe ich oft das AVR-Beispiel genannt; jetzt habe ich ein neues Beispiel zum Verlinken.
Angesichts der Frequenz und des Stromverbrauchs frage ich mich, wie viel HF das abstrahlt und ob man es im Wasserfall eines SDR erkennen und dekodieren könnte.
Ich lese noch, aber bis zu diesem Punkt sehe ich das Wort „soubroutine“, was wohl ein Tippfehler ist.
Wow, das dürfte kein billiges Projekt gewesen sein. eBay-Sammlern sei Dank.
Und das ist vermutlich die einzige Situation, in der ich LCD statt VFD gewählt hätte.
Wenn man einen mehrjährigen Compile laufen lässt, wäre das VFD am Ende wohl völlig eingebrannt.
Leider scheinen Uni-Mitarbeiter nicht allzu viel HN zu lesen.
Wow, beeindruckend.
An den hohen PC-Bits sieht man, was gerade ausgeführt wird.
PS: Immer noch schneller, als über das Internet auf dem miesen IPMI eines Servers per virtuellem ISO einen Kernel zu laden ;D
nmaufvmlinuxausführt, kann man sie leicht Kernel-Funktionen zuordnen.Nach dem Wechsel in den Userspace kann man auch das Haupt-Binary (weit unter 0x01000000) von Shared Libraries unterscheiden (die nahe den hohen Adressen um 0x77000000 geladen werden).
Sowohl das Booten als auch die Ausführung waren quälend langsam.
Das war ein wirklich faszinierender Artikel.
Ich hatte ein wenig über den 4004 gelesen und wusste, dass er ein seltsamer Chip ist, aber das Ausmaß der Obskurität übertrifft jede Vorstellung.
Jetzt würde ich gern sehen, wie gut man mit derselben Transistorzahl heute eine CPU bauen könnte.
So viel weniger als beim 6502 sind es gar nicht, und 8 Bit würden die Programmierung wohl deutlich einfacher machen.
Die Videoaufnahme dauerte 9 Tage, und es brauchte 4 Stunden pro Sekunde Emulation.
Außerdem frage ich mich, warum Windows 95 verwendet wird.
Für das Video brauchte ich einen Laptop mit echtem seriellen Port, nicht über USB.
Dieser Laptop erfüllte die Anforderungen und kostete 20 Dollar auf eBay.
Persönlich finde ich Windows 2000 das schönste Windows, deshalb habe ich es für das Demo-Video installiert.
Wirklich großartig
Ich wünschte, mein Wissen wäre inzwischen groß genug, um den Großteil dieses Projekts verstehen zu können, aber mit meinen derzeit begrenzten Informatikkenntnissen war es mir zu schwierig
Das Highlight, das ich immerhin vollständig verstehen konnte, war „Section 14.b & 14.c - Getting the data...“
Nur 400.000 Dateien und etwa 275 Fotos pro Tag über vier Jahre hinweg reichten aus
Wir leben wirklich in einer seltsamen Zeit: Obwohl Verarbeitungs-, Speicher- und Netzwerkleistung so üppig vorhanden sind, bleiben die offenbar meistgenutzten Apps zur Mediensynchronisierung hängen oder synchronisieren langsam, AirDrop schlägt fehl, und nicht einmal eine UI-Funktion „Alles auswählen“ gibt es :)
Für solche Dinge braucht es so etwas wie einen Nobelpreis
Man könnte vielleicht eine Kategorie zur Anerkennung merkwürdiger und ungewöhnlicher Anwendungen der Informatik hinzufügen
Im Abschnitt „Why MIPS?“ hieß es, „manche müssen wegen schrecklicher Adressierungsarten langsam sein (RISCV)“ — was ist denn an der RISC-V-Adressierung problematisch?
Bei einigen RISC-V-Instruktionen sind die Bits von Immediate-Werten nicht zusammenhängend gespeichert
In MIPS-Instruktionen werden die Wertbits für Immediate-Addition, Laden von Konstanten, Branches usw. immer der Reihe nach gespeichert
Bei RISC-V sind die Bits manchmal durcheinandergewürfelt
Bei einem bedingungslosen Sprung werden die Bits des Ziel-Offsets zum Beispiel in der Reihenfolge bit 19, bits 9-0, bit 10, bits 18-11 gespeichert
In Hardware muss man nur die Verdrahtung korrekt anschließen, daher kostet die Umordnung praktisch nichts; in Software sind dagegen viele Bit-Manipulationen nötig, um das zu korrigieren
RISC-V macht das, um das Hardwaredesign zu vereinfachen