🎮 Gaming
Un hacker logró que Linux funcione en un Sega 32X de 1994 — y lo hizo con 2 CPUs
Imaginá esto: correr Linux en un aparato que Sega lanzó en 1994, con dos CPUs que no pueden sincronizarse entre sí porque el bus del cartucho no tiene el ciclo de lectura-modificación-escritura necesario. Suena imposible, ¿no?
Pues un desarrollador conocido como cakehonolulu lo hizo. Y no solo logró que Linux arrancara en el Sega 32X — el add-on más fallido y extraño de la historia de Sega — sino que consiguió que usara ambos procesadores SH2 al mismo tiempo. Sin hardware de sincronización. Solo con ingenio puro.
¿Qué es el Sega 32X y por qué es tan raro?
Lanzado en noviembre de 1994 en América y Europa (diciembre en Japón), el 32X era un add-on que se conectaba al slot de cartuchos del Genesis/Mega Drive. Prometía ser un puente entre la era de 16 bits y la futura Saturn de 32 bits.
En la práctica, era un monstruo de Frankenstein:
- 2 procesadores Hitachi SuperH SH2 a 23 MHz cada uno
- 256 KB de SDRAM (en doble buffer)
- 256 KB de framebuffer
- Renderizado 3D por software (polígonos planos, Gouraud y texturizados simples)
- 3 fuentes de poder separadas (Genesis + 32X + Sega CD opcional)
El problema es que salió casi al mismo tiempo que la PlayStation 1 de Sony, que era más barata, más potente y mucho más fácil de programar. Encima, la Saturn de Sega estaba a punto de llegar. Los consumidores no sabían qué comprar. El 32X fue un fracaso rotundo.
El desafío: correr Linux donde ni Sega pudo
Treinta años después, cakehonolulu decidió hacer algo que nadie había intentado seriamente: portar Linux al 32X. Su motivación no era solo nostalgia — quería mejorar sus habilidades de board bringup (hacer que un silicon funcione desde cero).
El problema inmediato: el 32X tiene 3 CPUs que deben coordinarse: los dos SH2 y el Motorola 68000 del Genesis base. El 68000 actúa como árbitro del bus, pero los SH2 no tienen acceso directo al UART (puerto serie). Todo el output tiene que pasar por el 68000.
Pero el problema real era mucho más profundo.
El talón de Aquiles: sincronización SMP sin hardware
Para que Linux funcione en múltiples CPUs, necesita primitivas de sincronización atómicas — operaciones como test-and-set o compare-and-swap que el hardware garantiza que son indivisibles. Sin eso, dos CPUs pueden leer y escribir la misma variable al mismo tiempo, y todo explota.
Los SH2 del 32X no tienen primitivas de sincronización hardware. La documentación técnica de Sega advertía explícitamente que no se usara la instrucción TAS.B porque el bus del adaptador no tiene el mecanismo de locked read-modify-write.
¿La solución? El algoritmo de Peterson.
Sí, el mismo algoritmo de exclusión mutua por software que aprendés en el primer año de la facultad de ciencias de la computación. Cakehonolulu implementó spin_lock y todas las primitivas SMP usando el algoritmo de Peterson completamente en software. No es rápido — el mismo autor admite que "el rendimiento es pésimo" — pero funciona.
4 MB de RAM gracias a un flashcart moderno
Otro obstáculo: el 32X solo tiene 256 KB de SDRAM. Linux no cabe ahí ni de broma. La solución vino de un lugar inesperado: el Mega EverDrive Pro de Krikzz, un flashcart FPGA que permite jugar ROMs en hardware real.
Krikzz había implementado un Extended SSFv2 Mapper que permite usar la ROM del cartucho como RAM (configurando ciertos bits). Con eso, cakehonolulu consiguió 4 MB de RAM — suficiente para alojar un Linux mínimo con BusyBox.
Tuvo que poner Linux y el initramfs a dieta constante para no morir de OOM (out of memory), pero logró un punto dulce de ~540 KB de ROM y el resto como RAM.
La zanahoria: cómo funciona la sincronización de CPUs
El 68000 del Genesis no solo maneja el UART — también actúa como árbitro de interrupciones entre los dos SH2. Cuando un SH2 necesita enviar una IPI (Inter-Processor Interrupt), manda un comando al 68000, que decide qué línea de interrupción activar basándose en un bit del word de datos (0 para primario, 1 para secundario).
Para identificar qué CPU es cuál (necesario para hard_smp_processor_id()), se usó el registro de división de hardware privado de cada SH2 — un registro que no tenía otro uso — como identificador de CPU.
El resultado después de semanas de trabajo, noches persiguiendo bugs, y toolchains rotas:
smp: Bringing up secondary CPUs ...
MARS SMP: released secondary SH2 to 22082000
smp: Brought up 1 node, 2 CPUs
¿Para qué sirve tener Linux en un Sega 32X?
Prácticamente para nada útil. Y ese es exactamente el punto.
Esto es ingeniería por amor al arte. Cakehonolulu lo hizo por la experiencia, por el desafío técnico, y porque podía. Porque cuando te apasiona la tecnología, a veces la mejor pregunta no es "¿para qué sirve?" sino "¿se puede hacer?"
Y la respuesta es sí: se puede ejecutar Linux en un accesorio de Sega de 1994 con dos CPUs, cero sincronización hardware, 256 KB de RAM base, y un montón de ingenio.
Lo que esto nos enseña
La historia del 32X corriendo Linux es un recordatorio de que el hardware no es una barrera si tenés las habilidades correctas. La sincronización SMP por software — que muchos consideran una curiosidad académica — resultó ser la solución a un problema real en hardware real, 30 años después de que Peterson publicara su algoritmo.
En un mundo donde todo es "usá la API", "usá la librería", "no reinventes la rueda", este proyecto demuestra que entender los fundamentos — cómo funciona realmente un sistema operativo, cómo se sincronizan los procesos, cómo trabaja el hardware al nivel del bus — sigue siendo la diferencia entre alguien que usa herramientas y alguien que crea herramientas.
Compartí esto con ese amigo que dice que "los juegos retro son una pérdida de tiempo". La tecnología retro es el mejor laboratorio de ingeniería que existe.
¿Qué otra consola vieja te gustaría ver corriendo Linux? Dejalo en los comentarios.