semu-c64 - Exécuter Linux sur un Commodore C-64

• Projet de portage pour C-64 de semu, un émulateur RISC-V32 minimaliste, afin d’exécuter Linux sur un Commodore C-64
• Comme les seuls 64 Kio de mémoire ne suffisent pas à contenir l’ensemble de la configuration, une RAM Expansion Unit (REU) est nécessaire, et la vitesse d’exécution est extrêmement lente, au point d’être décrite comme « extremely slowly »
• L’exécutable semu généré est un émulateur RISCV32 générique, qui suppose que la REU est mappée sur la plage d’adresses allant de 0x00000000 à 0x01000000
• L’exécution de Linux utilise une émulation de mémoire virtuelle et une MMU, tandis que l’UART émulé gère la conversion des majuscules/minuscules entre PETSCII et ASCII
• La compilation se fait avec make et nécessite mos-c64-clang
• Pour l’exécuter dans VICE, il faut utiliser un fichier .d64 contenant l’exécutable semu compilé ainsi que reufile.linux, activer le RAM Expansion Module, puis choisir une taille de 16 Mio
• Côté C-64, l’exécution se fait en saisissant LOAD "SEMU",8,1, puis run ; d’après le README, le démarrage nécessite une longue attente
• Le binaire semu pour PC peut charger reufile.linux avec l’option -k et servir à obtenir une séquence de démarrage déterministe jusqu’à la première frappe clavier
• La fonctionnalité de persistance consiste à enregistrer l’état de l’émulateur afin de recharger plus rapidement un Linux déjà démarré ; elle charge les registres du CPU RISC-V ainsi que l’état de l’UART et du contrôleur d’interruptions depuis l’adresse REU 0xfff000
• Les releases sont considérées comme « highly experimental » et il est explicitement indiqué qu’elles ne conviennent pas à des tâches de production

[GN⁺]

Commentaires sur Hacker News

• Onno Kortman a cross-compilé semu, un émulateur RISC-V minimaliste, avec llvm-mos, le port LLVM pour MOS 6502, afin de faire tourner Linux sur un Commodore 64
  Kortman écrit : « Il a fallu plusieurs heures pour produire la capture d’écran, même avec le “warp mode” de VICE. En l’état, un vrai C64 pourrait probablement démarrer Linux en une semaine environ »

  • Le 6502 est notoirement mauvais comme cible de compilation C, surtout quand le C en question ne tient pas compte des contraintes du 6502
    Écrire un émulateur RISC-V en 6502 natif permettrait peut-être de démarrer Linux en moins d’une journée sur une vraie machine, plutôt qu’en une semaine. On se demande combien de vies cela sauverait
    https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
  • Cette méthode de bootstrap rappelle un autre projet Linux sur microcontrôleur 8 bits
    https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi... utilisait un émulateur ARMv5 sur un AVR 8 bits, mais celui-ci va encore plus loin en matière de classe geek
  • J’aimerais le voir tourner sur du vrai matériel, et j’espère que quelqu’un y arrivera

• C’est impressionnant, mais ma première pensée a été : « impossible que ça tienne dans 64 Ko de RAM ! », et en effet, ça ne tient pas
  Il faut une REU de 16 Mo. À l’époque, les REU pour C64 faisaient 256 Ko et 512 Ko, et comme les schémas étaient publics, les clones fabriqués sont surtout de ce type
  À la fin des années 90, il existait aussi une « extension » pour C64 intégrant un nouveau CPU compatible avec le code d’origine, la SuperCPU (65816), et cet appareil pouvait probablement monter jusqu’à 16 Mo
  Plus tard, des réimplémentations à base de FPGA sont apparues, ainsi que des REU de 16 Mo. Les schémas originaux de la SuperCPU ont disparu, et même si l’on dit que des cartes d’extension à base de FPGA s’achètent aujourd’hui pour quelques centaines d’euros, je ne connais personne qui en ait réellement acheté une
  Donc, même si c’est une belle réussite technique, dire que « ça tourne sur C64 » me donne un peu l’impression de dire « on a fait tourner Doom 3 sur un 386, sauf que ce 386 est une carte PCI dans un PC moderne »
  Si je ne peux pas l’exécuter sur mon C64 avec du matériel disponible à l’époque, ou réalistement constructible à l’époque, c’est délicat de dire que « ça tourne sur C64 »
  Pour revenir aux REU, je me demande aussi pourquoi il n’existe toujours pas de schéma ouvert. On trouve beaucoup de puces SRAM bon marché sur eBay, donc cela semblerait facile à fabriquer, mais en pratique ce n’est pas simple : il faut émuler deux composants, la SuperCPU et le contrôleur DMA, avec un FPGA assez gros
  Si des FPGA moins chers, ou des microcontrôleurs aux capacités proches d’un FPGA, apparaissent, quelqu’un finira peut-être par créer une SuperCPU open source. Jusqu’ici, tous les utilisateurs dont j’ai entendu parler semblent passer par l’émulation. L’émulation est très utile pour le développement, mais dans mon hobby rétro, le vrai plaisir vient surtout du fait de faire tourner les choses sur le matériel d’origine

  • Si le critère est « du matériel disponible à l’époque ou réalistiquement constructible à l’époque, sinon on peut difficilement dire que ça tourne sur C64 », alors une REU de 16 Mo aurait bel et bien pu être construite dans les années 80
    Son prix aurait été astronomique, mais il n’y avait aucune raison technique l’empêchant. Vous semblez confondre la SuperCPU et une REU classique
    Une REU n’est qu’un bloc de RAM avec un ASIC qui communique avec le C64 pour stocker ou rapatrier des banques mémoire ; il n’y a pas de CPU. Comme le 6502 ne peut pas adresser directement plus de 64 Ko, on lui demande de remplacer la RAM système
    La SuperCPU (65816), elle, peut effectivement adresser directement 16 Mo, mais c’est un appareil distinct. Le projet d’origine tourne sur un C64 de base avec le CPU de base du C64 ; il nécessite simplement une énorme quantité de RAM qui aurait coûté le prix d’une maison à l’époque
  • Je me demande s’il ne serait pas possible, au lieu d’un FPGA, de faire faire la même chose en logiciel par un SoC ARM généraliste intégré à une carte comme un RPi Pico/Nano, par exemple
    Ou bien peut-être que cela dépasse déjà les limites du purisme en matière d’émulation
  • « Mon 386 est en fait une carte PCI dans un PC moderne » : maintenant, j’en veux une
    De nos jours, on pourrait probablement mettre un 386, un 486, un Pentium et d’autres SoC sur une seule carte PCIe, avec refroidissement passif en prime
  • S’il faut ajouter 16 Mo de mémoire, dire que c’est « sur Commodore 64 » est tout de même assez limite

• Ce n’est pas à propos de Linux, mais j’essaie ces derniers temps des accessoires récents pour C64
  J’ai essayé Kung Fu Flash : c’est une cartouche logicielle définie par logiciel, bon marché, basée sur un STM32, et elle sait presque tout faire. Je l’ai achetée pour retrouver l’expérience de développement que je voyais dans “8-bit show and tell” ; elle peut émuler “Super Snapshot”, mais pas la REU. C’est excellent pour tester rapidement beaucoup de logiciels et de jeux C64
  https://8bithardware.wixsite.com/website/post/kung-fu-flash
  https://github.com/KimJorgensen/KungFuFlash
  J’ai aussi un SD2IEC, mais j’ai appris que j’aurais dû acheter une variante avec une prise DIN supplémentaire. C’est correct, mais je n’ai jamais aimé le DOS d’origine du C64, et cet appareil renforce cette impression. Pour monter une image disque D64, il faut taper OPEN1,8,15,"CD:MYIMAGE.D64":CLOSE1, ce qui n’est pas terrible
  JiffyDOS, une ROM de remplacement pour C64, améliore cela, va plus vite et inclut en permanence un DOS wedge. J’en ai commandé une, et j’ai hâte de l’essayer avec un vrai lecteur 1541
  Ce qui m’a fait me lancer là-dedans récemment, c’est la cartouche “Penultimate +2” pour VIC-20
  https://www.youtube.com/watch?v=eNGyneXHKJQ
  En fait, j’ai acheté un VIC-20 essentiellement pour pouvoir essayer cette cartouche

• C’est une démonstration de l’équivalence de Turing. Si le temps n’est pas un problème, n’importe quel ordinateur Turing-complet peut faire ce que fait n’importe quel autre ordinateur Turing-complet.

  • Il faut aussi du temps et de la mémoire.
  • Comment fait-on tourner Linux dans le lambda-calcul ?

• Du coup, je me pose la question : quel est le matériel le plus ancien qui puisse démarrer un Linux moderne tout en restant utilisable au quotidien ?

  • La contrainte principale pour un usage quotidien, ce sont probablement les opérations cryptographiques nécessaires pour accéder à la plupart des sites web modernes.
    On peut concevoir le système le plus léger et le plus rapide possible pour qu’il tourne bien sur des machines lentes, mais l’Internet d’aujourd’hui est impitoyable.
  • Si « usage quotidien » signifie exécuter un navigateur web moderne et des applications web de productivité modernes, je dirais que le minimum se situe autour d’un Core 2 Duo avec 4 Go de mémoire.
    Ce ne serait pas très rapide, mais avec un peu de patience, le matériel ne devrait pas être un blocage. Avec en plus un GPU capable de décoder la vidéo matériellement, YouTube pourrait peut-être être regardable dans une qualité supérieure à celle d’une patate.
  • Pour fixer les termes du débat, disons un ordinateur sur lequel on peut installer Debian 12, lancer un gestionnaire de fenêtres et un navigateur, et qui ne soit pas douloureusement lent.
    J’aimerais viser quelque chose de l’époque Pentium 4 / Athlon XP. D’après la documentation, le Pentium original n’est pas pris en charge, donc si l’on accepte vraiment de souffrir, on pourrait peut-être remonter jusqu’au Pentium II.
  • Ce serait probablement quelque chose avec un Core 2 Duo. Bien sûr, un CPU à 230 MHz peut aussi « faire tourner » Linux avec un bureau.
  • Ce n’est absolument pas un Linux moderne, mais à l’été 1995, quand j’ai reçu Slackware 2.0, j’utilisais un Pentium 75 MHz, 8 Mo de RAM, une carte Trident capable de 1024x768 (seulement 800x600 sous X), un lecteur CD-ROM IDE et un disque dur.

• En quoi est-ce différent de LUnix ?
  https://en.wikipedia.org/wiki/LUnix

  • LUnix est un système d’exploitation natif pour C64 : on peut écrire des applications et les exécuter directement sur le matériel du C64.
    Ici, il s’agit de faire tourner un émulateur RISC-V sur le C64, puis d’émuler le démarrage de Linux au-dessus de cet émulateur.

• À strictement parler, Linux ne tourne pas directement sur le C64.
  Le C64 émule un environnement RISC-V, et Linux s’exécute par-dessus. Cela reste bien sûr impressionnant, mais la distinction est importante.

• Je me demande si, au lieu d’une REU, on pourrait faire fonctionner ça en utilisant des dizaines de disquettes comme de la RAM.
  Et si l’on demandait à l’utilisateur de changer de disque à chaque fois que nécessaire ? Si quelqu’un a quelques mois ou quelques années de libre, j’aimerais voir ça en timelapse sur le vrai matériel.

• Si l’on ajoute de la RAM à un Commodore 64, est-ce toujours un Commodore 64 ?

  • Si l’on utilise une REU, je dirais que oui. C’est une extension mémoire correspondant à l’époque du C64.
  • Pour développer l’explication de johnwbyrd un peu plus loin, Commodore vendait une RAM Expansion Unit appelée « 1764 » qui portait le C64 à 256 Ko de RAM, et l’on pouvait aussi utiliser la REU « 1750 » du C128 pour porter le C64 à 512 Ko de RAM.
    Il est également possible d’étendre une REU pour C64 jusqu’à 2 Mo. Voir https://www.neperos.com/article/rlut8ce90fbb7701
    Avoir 2 Mo sur un C64 peut être considéré comme assez « légitime ».
  • Non, dans ce cas c’est un Commodore 16384.
    La mémoire maximale adressable par la REU du C64 est de 16 Mo.

• J’ai récemment récupéré un TRS-80 Model 4 parfaitement fonctionnel, et j’imagine souvent y installer quelque chose de vaguement proche d’Unix.
  Cette idée ne me lâche pas.

  • On devrait pouvoir le pousser jusqu’à 128 Ko. À ce stade, il y a de vraies chances de pouvoir faire tourner Fuzix.
    En partant de là, tu trouveras un terrier de lapin assez profond.