semu-c64 - Linux auf dem Commodore C-64 ausführen

 (github.com/onnokort)
1 Punkte von GN⁺ 2023-08-28 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Projekt, das den minimalistischen RISC-V32-Emulator semu auf den C-64 portiert, um Linux auf dem Commodore C-64 auszuführen
  • Da 64 KiB Arbeitsspeicher nicht ausreichen, um die vollständige Konfiguration unterzubringen, wird eine RAM Expansion Unit (REU) benötigt; die Ausführung ist zudem so langsam, dass sie als „extremely slowly“ beschrieben wird
  • Die erzeugte ausführbare Datei semu ist ein allgemeiner RISCV32-Emulator und geht davon aus, dass die REU auf den Adressbereich von 0x00000000 bis 0x01000000 gemappt ist
  • Für die Linux-Ausführung werden virtuelle Speicheremulation und eine MMU verwendet; die emulierte UART verarbeitet die Umwandlung der Groß-/Kleinschreibung zwischen PETSCII und ASCII
  • Der Build erfolgt mit make, benötigt wird mos-c64-clang
  • Für die Ausführung in VICE werden die .d64-Datei mit der kompilierten semu-Binärdatei und reufile.linux verwendet; außerdem muss das RAM Expansion Module aktiviert und die Größe auf 16 MiB gesetzt werden
  • Auf dem C-64 erfolgt der Start mit LOAD "SEMU",8,1 und anschließend run; laut README ist für den Bootvorgang eine lange Wartezeit nötig
  • Die semu-Binärdatei für den PC kann mit der Option -k reufile.linux laden und eignet sich dazu, bis zur ersten Tasteneingabe eine deterministische Boot-Sequenz zu erhalten
  • Die Persistenzfunktion speichert den Emulatorzustand, um ein bereits gebootetes Linux schneller zu laden; RISC-V-CPU-Register sowie der Zustand von UART und Interrupt-Controller werden aus der REU-Adresse 0xfff000 geladen
  • Die Releases werden als „highly experimental“ eingestuft und ausdrücklich als ungeeignet für Produktivarbeit bezeichnet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-28
Meinungen auf Hacker News

  • Onno Kortman hat semu, einen minimalen RISC-V-Emulator, mit llvm-mos, einem LLVM-Port für den MOS 6502, cross-kompiliert und Linux auf dem Commodore 64 zum Laufen gebracht.
    Kortman schrieb: „Das Erstellen des Screenshots dauerte selbst im ‚warp mode‘ von VICE mehrere Stunden. Im jetzigen Zustand könnte wohl auch ein echter C64 Linux in etwa einer Woche booten.“

    • Der 6502 ist als Ziel für C-Compiler berüchtigt schlecht, besonders wenn es sich um C handelt, das die Einschränkungen des 6502 nicht berücksichtigt.
      Wenn man den RISC-V-Emulator als nativen 6502 schreibt, ließe sich Linux auf echter Hardware vielleicht nicht in einer Woche, sondern innerhalb eines Tages booten. Man fragt sich, wie viele Leben das retten würde.
      https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
    • Diese Bootstrap-Methode erinnert an ein anderes Linux-Projekt auf einem 8-Bit-Mikrocontroller.
      https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi... verwendete einen ARMv5-Emulator auf einem 8-Bit-AVR, aber dieses hier ist in Sachen nerdigem Coolness-Faktor noch eine Stufe darüber.
    • Ich würde es gern auf echter Hardware laufen sehen, und hoffe, dass jemand das schafft.

  • Cool ist es schon, aber mein erster Gedanke war: „Das passt doch niemals in 64 KB RAM!“ Und tatsächlich passt es nicht.
    Es braucht eine 16MB REU. Die damaligen REUs für den C64 hatten 256 KB und 512 KB, und weil die Schaltpläne offen waren, werden Nachbauten meist in diesen Größen gefertigt.
    Ende der 90er gab es auch eine „Erweiterung“ für den C64 namens SuperCPU (65816), mit einer neuen CPU, die codekompatibel zur ursprünglichen war; dieses Gerät konnte vermutlich bis zu 16 MB adressieren.
    Später kamen FPGA-basierte Reimplementierungen, und auch 16MB-REUs tauchten auf. Die ursprünglichen SuperCPU-Schaltpläne sind verloren gegangen, und FPGA-basierte Erweiterungsboards soll man heute zwar für ein paar hundert Euro kaufen können, aber ich kenne niemanden, der tatsächlich eines gekauft hat.
    Daher ist es zwar eine saubere technische Leistung, aber die Aussage „läuft auf dem C64“ fühlt sich ähnlich an wie „Doom 3 auf einem 386 ausgeführt — nur dass dieser 386 eine PCI-Karte in einem modernen PC ist“.
    Wenn ich es nicht mit damals verfügbarer Hardware oder mit damals realistisch baubarer Hardware auf meinem C64 ausführen kann, ist es schwierig, das als „läuft auf dem C64“ zu bezeichnen.
    Zurück zur REU: Ich frage mich auch, warum es dafür noch keinen offenen Schaltplan gibt. Auf eBay gibt es viele günstige SRAM-Chips, also scheint es leicht baubar, aber in Wirklichkeit muss man zwei Komponenten, SuperCPU und DMA-Controller, in einem ziemlich großen FPGA emulieren, also ist es nicht trivial.
    Wenn günstigere FPGAs oder Mikrocontroller mit FPGA-ähnlichen Fähigkeiten erscheinen, baut vielleicht jemand eine Open-Source-SuperCPU. Nach allem, was ich bisher von Nutzern gehört habe, verwenden sie alle Emulation. Für die Entwicklung ist Emulation sehr nützlich, aber der größte Spaß an meinem Retro-Hobby entsteht, wenn es auf Originalhardware läuft.

    • Wenn der Maßstab lautet: „Wenn es keine damals verfügbare oder damals realistisch baubare Hardware war, kann man kaum sagen, dass es auf dem C64 läuft“, dann hätte man eine 16MB REU auch in den 80ern bauen können.
      Sie wäre nur astronomisch teuer gewesen; technisch gab es keinen Grund, warum sie unmöglich gewesen wäre. Du scheinst SuperCPU und normale REU zu verwechseln.
      Eine REU ist nur ein RAM-Block plus ein ASIC, das mit dem C64 kommuniziert und RAM-Banks speichert oder zurückholt; eine CPU hat sie nicht. Da der 6502 nicht mehr als 64 KB direkt adressieren kann, weist man ihn an, den System-RAM auszutauschen.
      Die SuperCPU (65816) kann tatsächlich 16 MB direkt adressieren, ist aber etwas anderes. Das Projekt aus dem Originalbeitrag läuft auf einem Standard-C64 und der Standard-C64-CPU; es braucht nur enorm viel RAM, der damals wohl so viel wie ein Haus gekostet hätte.
    • Ich frage mich, ob man statt eines FPGA nicht zum Beispiel ein Board mit einem universellen ARM-SoC wie RPi Pico/Nano dazu bringen könnte, dasselbe in Software zu erledigen.
      Oder ob selbst das schon an die Grenzen des Emulations-Purismus stößt.
    • „Mein 386 ist in Wirklichkeit eine PCI-Karte in einem modernen PC“ — jetzt will ich so etwas haben.
      Heutzutage könnte man vermutlich einen 386, 486, Pentium und noch andere SoCs auf eine einzige PCIe-Karte packen und sogar passiv kühlen.
    • Wenn 16 MB zusätzlicher Speicher nötig sind, ist „auf dem Commodore 64“ schon ziemlich grenzwertig.

  • Nicht direkt zu Linux, aber ich probiere in letzter Zeit C64-Zubehör aus.
    Ich habe Kung Fu Flash ausprobiert; das ist ein günstiges softwaredefiniertes Cartridge auf Basis eines einzelnen STM32 und kann fast alles. Ich habe es gekauft, um die Entwicklererfahrung nachzubilden, die man bei „8-bit show and tell“ sieht. „Super Snapshot“ kann es emulieren, aber REU nicht. Es ist sehr gut, um viele C64-Programme und Spiele schnell auszuprobieren.
    https://8bithardware.wixsite.com/website/post/kung-fu-flash
    https://github.com/KimJorgensen/KungFuFlash
    Ich habe auch ein SD2IEC, und habe gelernt, dass ich wohl die Variante mit zusätzlicher DIN-Buchse hätte kaufen sollen. Es ist okay, aber ich mochte das DOS des ursprünglichen C64 nie, und dieses Gerät verstärkt dieses Gefühl. Um ein D64-Disk-Image zu mounten, muss man OPEN1,8,15,"CD:MYIMAGE.D64":CLOSE1 eintippen, was unschön ist.
    JiffyDOS, ein Ersatz-ROM für den C64, verbessert das, ist schneller und enthält dauerhaft einen DOS-Wedge. Ich habe eines bestellt und bin gespannt, es mit einem echten 1541-Laufwerk auszuprobieren.
    Was mich kürzlich dazu gebracht hat, mit all dem anzufangen, war das „Penultimate +2“-Cartridge für den VIC-20.
    https://www.youtube.com/watch?v=eNGyneXHKJQ
    Im Grunde habe ich mir einen VIC-20 gekauft, um dieses Cartridge auszuprobieren.

  • Eine Demonstration von Turing-Äquivalenz. Wenn Zeit keine Rolle spielt, kann jeder Turing-vollständige Computer alles tun, was ein anderer Turing-vollständiger Computer tut.

    • Zeit und Speicher braucht man allerdings auch.
    • Wie führt man Linux im Lambda-Kalkül aus?

  • Da fragt man sich: Was ist die älteste Hardware, die aktuelles Linux booten und trotzdem noch alltagstauglich genutzt werden kann?

    • Die zentrale Einschränkung für Alltagstauglichkeit dürften wohl die kryptografischen Operationen sein, die nötig sind, um auf die meisten modernen Websites zuzugreifen.
      Man kann zwar ein möglichst leichtgewichtiges und schnelles System bauen, das auch auf langsamen Maschinen gut läuft, aber das heutige Internet ist gnadenlos.
    • Wenn „alltagstauglich“ bedeutet, einen aktuellen Webbrowser und aktuelle Web-Produktivitäts-Apps auszuführen, würde ich die Untergrenze ungefähr bei Core 2 Duo und 4 GB Arbeitsspeicher sehen.
      Es wäre nicht besonders schnell, aber mit etwas Geduld würde man wohl nicht an der Hardware scheitern. Mit einer GPU, die Hardware-Videodekodierung beherrscht, könnte YouTube vielleicht sogar in besserer Qualität als Kartoffelauflösung laufen.
    • Nehmen wir der Diskussion halber einen Computer, auf dem sich Debian 12 installieren lässt, der einen Window Manager und einen Browser ausführen kann und der nicht schmerzhaft langsam ist.
      Ich würde gern etwa auf die Ära Pentium 4 / Athlon XP zielen. Laut Dokumentation wird der ursprüngliche Pentium nicht unterstützt; wenn man wirklich leiden will, könnte man vielleicht bis zum Pentium II zurückgehen.
    • Wahrscheinlich wäre es irgendetwas mit Core 2 Duo. Natürlich kann auch eine 230-MHz-CPU Linux mit Desktop „ausführen“.
    • Definitiv kein aktuelles Linux, aber als ich im Sommer 1995 Slackware 2.0 bekam, nutzte ich einen Pentium mit 75 MHz, 8 MB RAM, eine Trident-Karte mit 1024x768-Unterstützung (unter X nur 800x600), ein IDE-CD-ROM-Laufwerk und eine HDD.

  • Ist das etwas anderes als LUnix?
    https://en.wikipedia.org/wiki/LUnix

    • LUnix ist ein natives Betriebssystem für den C64, für das man Apps schreiben und direkt auf der C64-Hardware ausführen kann.
      Hier läuft auf dem C64 ein RISC-V-Emulator, und auf diesem Emulator wird das Booten von Linux emuliert.

  • Streng genommen läuft Linux nicht direkt auf dem C64.
    Der C64 emuliert eine RISC-V-Umgebung, und darauf läuft Linux. Natürlich ist das trotzdem beeindruckend, aber die Unterscheidung ist wichtig.

  • Ich frage mich, ob man das statt mit einer REU auch mit Dutzenden Disketten zum Laufen bringen könnte, die man wie RAM verwendet.
    Man könnte den Nutzer jedes Mal auffordern, die Diskette zu wechseln, wenn es nötig ist. Wenn jemand ein paar Monate oder Jahre Freizeit übrig hat, würde ich das gern als Zeitraffer auf echter Hardware sehen.

  • Ist es noch ein Commodore 64, wenn man mehr RAM daran anschließt?

    • Wenn man eine REU verwendet, würde ich sagen: ja. Es ist ein zeitgenössisches Speicher-Upgrade für den C64.
    • Um johnwbyrds Erklärung hier in der Nähe zu erweitern: Commodore verkaufte eine RAM Expansion Unit namens „1764“, die den C64 auf 256 KB RAM erweiterte, und mit der „1750“, der REU für den C128, konnte man den C64 auch auf 512 KB RAM erweitern.
      Außerdem ist auch eine Erweiterung bis zu einer 2-MB-REU für den C64 möglich. Siehe https://www.neperos.com/article/rlut8ce90fbb7701
      2 MB im C64 kann man ziemlich „legal“ haben.
    • Nein, das ist dann ein Commodore 16384.
      Der maximal adressierbare Speicher mit einer C64-REU beträgt 16 MB.

  • Ich habe vor Kurzem einen vollständig funktionsfähigen TRS-80 Model 4 bekommen und stelle mir häufig vage vor, darauf irgendetwas Unix-Ähnliches laufen zu lassen.
    Diese Vorstellung bleibt.

    • Man dürfte ihn auf 128 KB aufrüsten können. Ab da stehen die Chancen ziemlich gut, Fuzix auszuführen.
      Wenn man an diesem Punkt anfängt, findet man ein ordentlich tiefes Kaninchenloch.