semu-c64 - Ejecutar Linux en una Commodore C-64

• Un proyecto que porta el emulador minimalista RISC-V32 semu a la C-64 para ejecutar Linux en una Commodore C-64
• Como los 64 KiB de memoria no alcanzan para contener la configuración completa, se necesita una RAM Expansion Unit (REU), y la velocidad de ejecución es extremadamente lenta, al punto de describirse como “extremely slowly”
• El archivo ejecutable semu generado es un emulador RISCV32 de propósito general y asume que la REU está mapeada en el rango de direcciones de 0x00000000 a 0x01000000
• Para ejecutar Linux se usan emulación de memoria virtual y una MMU, y la UART emulada maneja la conversión entre mayúsculas y minúsculas de PETSCII y ASCII
• La compilación se realiza con make y requiere mos-c64-clang
• Para ejecutarlo en VICE, se usan el archivo .d64 que contiene el ejecutable compilado semu y reufile.linux, y después hay que activar el RAM Expansion Module y seleccionar un tamaño de 16MiB
• En la C-64, la ejecución se hace ingresando LOAD "SEMU",8,1 y luego run, y según el README el arranque requiere un largo tiempo de espera
• El binario semu para PC puede cargar reufile.linux con la opción -k, y puede usarse para obtener una secuencia de arranque determinista hasta la primera pulsación de tecla
• La función de persistencia guarda el estado del emulador para cargar más rápido un Linux ya iniciado, y carga desde la dirección REU 0xfff000 los registros de CPU RISC-V, la UART y el estado del controlador de interrupciones
• Las releases se consideran “highly experimental” y se indica explícitamente que no son aptas para trabajo en producción

[GN⁺]

Comentarios en Hacker News

• Onno Kortman compiló de forma cruzada semu, un emulador RISC-V minimalista, para MOS 6502 usando llvm-mos, un port de LLVM para 6502, y logró ejecutar Linux en una Commodore 64
  Kortman escribió: “Incluso en el ‘warp mode’ de VICE, sacar la captura de pantalla tomó horas. En el estado actual, una C64 real probablemente podría arrancar Linux en alrededor de una semana”

  • El 6502 es famosamente pésimo como objetivo de compilación para C, y más aún si el C no fue escrito teniendo en cuenta las limitaciones del 6502
    Si se escribiera un emulador de RISC-V en 6502 nativo, quizá Linux podría arrancar en hardware real en menos de un día y no en una semana. Uno se pregunta cuántas vidas salvaría eso
    https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
  • Este enfoque de bootstrap recuerda a otro proyecto de Linux sobre un microcontrolador de 8 bits
    https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi... usó un emulador ARMv5 sobre un AVR de 8 bits, pero este le gana en rareza genial
  • Me gustaría verlo funcionando en hardware real, y ojalá alguien lo logre

• Está genial, pero mi primera reacción fue: “¡No hay forma de que eso quepa en 64 KB de RAM!”, y en efecto no cabe
  Hace falta una REU de 16 MB. En esa época las REU para C64 eran de 256 KB y 512 KB, y como los esquemas están publicados, las réplicas suelen ser de ese tipo
  A fines de los 90 también hubo una “expansión” para C64 con una CPU nueva, la SuperCPU (65816), compatible en código con la CPU original, y probablemente ese dispositivo sí permitía hasta 16 MB
  Después aparecieron reimplementaciones basadas en FPGA y también REU de 16 MB. Los esquemas originales de la SuperCPU se perdieron, y aunque dicen que hoy se pueden comprar placas de expansión basadas en FPGA por varios cientos de euros, no conozco a nadie que realmente haya comprado una
  Así que, aunque es un logro técnico muy pulcro, decir que “corre en una C64” se siente un poco como decir “corrí Doom 3 en una 386, salvo que esa 386 es una tarjeta PCI de una PC moderna”
  Si no puedo ejecutarlo en mi C64 con hardware que existía en esa época o que razonablemente se podía construir en ese entonces, me cuesta llamarlo “corriendo en una C64”
  Volviendo a la REU, también me pregunto por qué todavía no hay esquemas abiertos. En eBay abundan chips SRAM baratos, así que parecería fácil de hacer, pero en la práctica no es tan simple porque hay que emular dos componentes —la SuperCPU y el controlador DMA— en una FPGA bastante grande
  Si aparecen FPGA más baratas o microcontroladores con capacidades parecidas a una FPGA, quizá alguien haga una SuperCPU open source. Por ahora, todos los usuarios que he visto parecen usar emulación. La emulación es muy útil para desarrollo, pero la diversión de mi hobby retro está sobre todo en correr las cosas en hardware original

  • Si el criterio es que “si no es hardware disponible en esa época o razonablemente construible entonces es difícil decir que corre en una C64”, una REU de 16 MB sí se podría haber construido en los 80
    Habría costado una fortuna, pero no había ningún impedimento técnico. Creo que estás confundiendo la SuperCPU con una REU común
    Una REU no es más que un bloque de RAM y un ASIC que se comunica con la C64 para guardar o restaurar bancos de RAM; no tiene CPU. Como la 6502 no puede direccionar directamente más de 64 KB, lo que hace es indicarle al sistema que reemplace la RAM
    La SuperCPU (65816) sí puede direccionar directamente 16 MB, pero es otra cosa. El proyecto del post original corre en una C64 base y con la CPU base de la C64; solo que necesita una cantidad descomunal de RAM que en esa época habría costado lo mismo que una casa
  • Me pregunto si, en vez de FPGA, no se podría hacer que un ARM SoC de propósito general integrado en una placa como una RPi Pico/Nano hiciera lo mismo por software
    O si incluso eso ya choca con los límites del purismo de la emulación
  • “Mi 386 en realidad es una tarjeta PCI de una PC moderna”... ahora quiero una de esas
    Hoy en día parece que se podría meter una 386, una 486, una Pentium y otros SoC más en una sola tarjeta PCIe, incluso con refrigeración pasiva
  • Si hace falta agregar 16 MB de memoria, decir “en una Commodore 64” ya queda bastante en el límite

• No es sobre Linux, pero últimamente he estado probando accesorios recientes para C64
  Probé Kung Fu Flash, que es un cartucho barato definido por software hecho con un STM32 y puede hacer casi de todo. Lo compré para intentar recrear la experiencia de desarrollo que veía en “8-bit show and tell”; puede emular “Super Snapshot”, pero no la REU. Es muy bueno para probar rápido mucho software y juegos de C64
  https://8bithardware.wixsite.com/website/post/kung-fu-flash
  https://github.com/KimJorgensen/KungFuFlash
  También tengo un SD2IEC, aunque aprendí que debí haber comprado una variante con un socket DIN adicional. Está bien, pero nunca me gustó mucho el DOS original de la C64, y este dispositivo refuerza esa sensación. Para montar una imagen de disco D64 hay que escribir OPEN1,8,15,\"CD:MYIMAGE.D64\":CLOSE1, lo cual no está muy bueno
  JiffyDOS, una ROM de reemplazo para C64, mejora esto, además de ser más rápida e incluir un wedge de DOS siempre disponible. Ya pedí una y tengo curiosidad por probarla con una unidad 1541 real
  Lo que me metió en todo esto recientemente fue el cartucho “Penultimate +2” para VIC-20
  https://www.youtube.com/watch?v=eNGyneXHKJQ
  Básicamente compré una VIC-20 solo para probar este cartucho

• Es una demostración de la equivalencia de Turing. Si el tiempo no fuera un problema, cualquier computadora Turing-completa puede hacer lo que hace cualquier otra computadora Turing-completa.

  • También hacen falta tiempo y memoria.
  • ¿Cómo ejecutas Linux en cálculo lambda?

• Entonces surge la duda: ¿cuál sería el hardware más antiguo que aún puede arrancar Linux moderno y seguir siendo usable en el día a día?

  • La limitación clave para el uso diario probablemente sean las operaciones criptográficas necesarias para acceder a la mayoría de los sitios web modernos.
    Se puede armar el sistema más liviano y rápido posible para que funcione bien incluso en una máquina lenta, pero el internet actual no perdona.
  • Si “usable en el día a día” significa ejecutar un navegador web moderno y apps web modernas de productividad, yo pondría el mínimo más o menos en un Core 2 Duo con 4 GB de memoria.
    No sería muy rápido, pero con un poco de paciencia no parecería que el hardware te esté frenando. Si además le pones una GPU con decodificación de video por hardware, tal vez hasta YouTube se pueda ver a una calidad mejor que la de papa.
  • Para fines de la discusión, digamos que es una computadora en la que puedes instalar Debian 12, ejecutar un gestor de ventanas y un navegador, y que no sea dolorosamente lenta.
    Me gustaría apuntar a algo de la era Pentium 4 / Athlon XP. Según la documentación, el Pentium original ya no tiene soporte, así que si de verdad quieres sufrir, quizá podrías retroceder hasta un Pentium II.
  • Probablemente sería algo con Core 2 Duo. Claro, incluso un CPU de 230 MHz aún podría “ejecutar” Linux con escritorio.
  • Definitivamente no era Linux moderno, pero cuando bajé Slackware 2.0 en el verano de 1995, usaba un Pentium de 75 MHz, 8 MB de RAM, una tarjeta Trident capaz de 1024x768 (aunque en X solo podía 800x600), además de CD-ROM IDE y disco duro IDE.

• ¿Esto es distinto de LUnix?
  https://en.wikipedia.org/wiki/LUnix

  • LUnix es un sistema operativo nativo para C64, así que puedes escribir apps y ejecutarlas directamente sobre el hardware del C64.
    Esto, en cambio, consiste en ejecutar un emulador de RISC-V en el C64, y sobre ese emulador simular el arranque de Linux.

• Estrictamente hablando, Linux no corre directamente en el C64.
  El C64 está emulando un entorno RISC-V, y Linux se ejecuta sobre eso. Sigue siendo impresionante, por supuesto, pero la distinción conceptual importa.

• Me pregunto si sería posible hacerlo funcionar no con una REU, sino usando decenas de disquetes como si fueran RAM.
  ¿Qué tal si se le pide al usuario que cambie el disco cada vez que haga falta? Si a alguien le sobran unos meses o unos años, me gustaría ver eso en hardware real como un timelapse.

• Si le agregas más RAM a una Commodore 64, ¿sigue siendo una Commodore 64?

  • Si usas una REU, yo diría que sí, porque es una ampliación de memoria acorde a la época del C64.
  • Ampliando la explicación de johnwbyrd por aquí cerca, Commodore vendía una RAM Expansion Unit llamada “1764” para llevar la C64 a 256 KB de RAM, y también se podía usar la REU “1750”, pensada para la C128, para ampliar una C64 a 512 KB de RAM.
    Además, también es posible expandirla hasta una REU de 2 MB para C64. Ver https://www.neperos.com/article/rlut8ce90fbb7701.
    Tener 2 MB en una C64 es bastante “legítimo”.
  • No, eso sería una Commodore 16384.
    La memoria máxima direccionable con una REU de C64 es de 16 MB.

• Hace poco conseguí una TRS-80 Model 4 completamente funcional y seguido me imagino poniéndole algo vagamente parecido a Unix.
  Esa fantasía sigue viva.

  • Debería poder subirse hasta 128 KB. Si llegas a eso, ya habría bastantes chances de correr Fuzix.
    Si empiezas por ahí, seguro encuentras una madriguera de conejo bastante profunda.