5 puntos por GN⁺ 2025-07-23 | 1 comentarios | Compartir por WhatsApp
  • Para fabricar un cartucho de Game Boy desde cero, el autor pasó por años de investigación y diseño
  • Este artículo organiza de forma sistemática la información técnica clave necesaria para crear cartuchos personalizados de Game Boy desde la perspectiva de un principiante
  • Game Boy es una plataforma atractiva para la comunidad de desarrollo de juegos retro y hacking de hardware gracias a una arquitectura simple pero muy expandible
  • Los cartuchos pueden integrar datos del juego y hardware adicional (por ejemplo, RTC, sensores, etc.), lo que permite agregar nuevas funciones a la Game Boy
  • A través de circuitos de controlador de bancos de memoria (MBC), es posible ampliar la capacidad y acceder selectivamente a la memoria, habilitando distintas formas de ejecutar juegos

Introducción y objetivos

  • El autor se propuso como meta personal fabricar un cartucho de Game Boy completamente desde cero
  • Reunió y publicó como open source el conocimiento sobre la estructura interna y el funcionamiento de los cartuchos de Game Boy
  • El objetivo del texto es reorganizar información técnica compleja para que cualquiera pueda seguirla desde una mirada de principiante
  • La explicación se centra no en el funcionamiento interno del hardware, sino en el comportamiento (behavior) observable desde fuera
  • La explicación toma como referencia el SoC de la DMG (la Game Boy original), aunque la interfaz básica de cartuchos es similar en toda la familia Game Boy

Qué hace especial a la plataforma Game Boy

  • Gracias a su simplicidad y diseño intuitivo, es fácil entender mentalmente la estructura de hardware y software de la Game Boy
  • Sus características de portabilidad y bajo consumo, junto con una arquitectura sin protecciones complejas ni bloqueo regional, permiten que cualquiera desarrolle para ella
  • Existe una gran acumulación de documentación técnica, esquemas de hardware y materiales creados por la comunidad
  • Hay una biblioteca enorme de juegos oficiales y no oficiales, y se mantienen activamente toolchains open source y herramientas de scripting visual
  • Se ha formado un ecosistema muy expandible, con drivers de hardware, además de emuladores precisos e implementaciones en FPGA

Estructura básica de un cartucho de Game Boy

  • En las consolas antiguas, la frontera entre software y hardware era difusa
  • La Game Boy no tiene sistema operativo ni almacenamiento no volátil interno. Todo el código ejecutable y el hardware adicional están integrados en el cartucho
  • Por eso, el cartucho debe funcionar correctamente para que la Game Boy pueda arrancar y operar
  • El conector de borde de 32 pines en la parte inferior del cartucho es la interfaz principal para intercambiar señales con la consola
  • Las señales entre cartucho y consola se clasifican en alimentación, control (lectura/escritura/selección de chip), bus de direcciones (16 bits) y bus de datos (8 bits)

Bus y principio de funcionamiento

  • Un bus es una estructura en la que varios componentes comparten una misma línea de señales para transferir datos
  • La CPU de la Game Boy coloca la dirección deseada en el bus de direcciones y los datos en el bus de datos
  • Como la estructura del bus es paralela (parallel), existen pines físicos correspondientes a cada bit
  • Esto favorece la velocidad, pero al ser un bus compartido también existe riesgo de colisiones o contención (escritura simultánea)
  • Si varios IC intentan sacar datos al mismo tiempo, puede producirse un cortocircuito (con riesgo de sobrecalentamiento y falla), por lo que siempre debe haber un solo IC activo

Principales tipos de memoria en la Game Boy

  • La Game Boy puede incorporar hasta 4 tipos de IC de memoria (RAM interna, video RAM, ROM del cartucho y RAM del cartucho)
  • En la práctica, la video RAM usa un bus independiente, por lo que suele excluirse de la explicación general
  • La RAM interna, la RAM del cartucho y la ROM del cartucho comparten el mismo bus de direcciones y el mismo bus de datos
  • En cada momento, solo un chip debe realizar operaciones de lectura o escritura sobre el bus de datos
  • En términos prácticos, también se les llama RAM interna (WRAM), RAM del cartucho (SRAM), video RAM (VRAM) y RAM de alta velocidad (HRAM)

Chip Select y configuración del circuito

  • Cada chip de memoria tiene un pin de señal de selección de chip (CS/CE, Chip Select/Chip Enable)
  • Según el estado de esa señal, solo un chip específico puede acceder al bus de datos
  • Para la selección de chip, la Game Boy reutiliza los 3 bits más altos del bus de direcciones (A15, A14, A13) y el pin _CS de la CPU
  • Esta conexión garantiza que no se activen dos o más chips al mismo tiempo
  • Por ejemplo, el chip ROM solo se activa cuando A15 es 0, mientras que la RAM se activa mediante una lógica distinta

Mapa de memoria y perspectiva del programador

  • Los estados físicos de direcciones y pines se abstraen, así que el programador solo percibe el mapa lógico de memoria
  • Dentro del espacio de direcciones de 16 bits, el rango 0x0000–0x7FFF se asigna a la ROM del cartucho, 0xA000–0xBFFF a la RAM del cartucho y 0xC000–0xDFFF a la RAM interna
  • Al acceder a una dirección específica, se activa automáticamente el rango de memoria correspondiente y se desactivan los demás
  • La documentación del mapa de memoria es una referencia fundamental dentro de la documentación de Game Boy

Controlador de bancos de memoria (MBC; Memory Bank Controller)

  • El MBC es el circuito clave que permite en los cartuchos de Game Boy usar más de 32 KB de ROM y conectar RAM adicional o periféricos
  • Se comercializaron varios tipos de MBC, pero aquí la explicación toma como base el MBC5, que es relativamente simple y de uso general
  • El MBC5 soporta hasta 8 MB de ROM y 128 KB de RAM de cartucho mediante técnicas de banking
  • También permite controlar el acceso a la RAM y manejar hardware adicional como sensores externos o RTC
  • Entre los pines de dirección de la ROM del cartucho, los bits altos (A22~A14) son controlados dinámicamente por el MBC5, mientras que solo los bits bajos se conectan directamente al bus de direcciones de la consola

Principio del ROM banking

  • La CPU de la Game Boy tiene un espacio de direcciones máximo de 64 KB, pero en la práctica solo usa 32 KB (16 KB + 16 KB) para acceder a la ROM
  • El MBC5 controla directamente las direcciones altas de la ROM (selección de banco) para mapear en el espacio de la CPU el bloque deseado en unidades de 16 KB
  • A nivel de hardware, los 14 bits bajos del bus de direcciones de la CPU (A0~A13) se conectan directamente al chip ROM, y el resto proviene del MBC5
  • Durante la ejecución real del juego, cuando el software escribe un valor en una dirección de memoria específica, el MBC detecta eso y actualiza internamente el valor del banco seleccionado

Protocolo y mecanismo del MBC

  • El MBC5 detecta combinaciones específicas de direcciones y señales de control para realizar tareas como selección de banco ROM, selección de banco RAM y activación o desactivación de otras funciones
  • Por ejemplo, si se realiza una escritura en la región A15=0, A13=1, A14=0 (0x2000~0x3FFF), el valor presente en el bus de datos se registra como número de banco ROM
  • En la práctica, el programador codifica el cambio de banco como si solo estuviera escribiendo datos en una dirección específica, en lugar de controlar directamente circuitos de bajo nivel
  • El uso de la RAM del cartucho, sensores, RTC y otros elementos también se controla con patrones similares
  • Esta técnica de reutilización del bus reduce la cantidad de componentes y baja el costo

Conclusión y uso en la comunidad

  • Lo distintivo de la estructura de los cartuchos de Game Boy es su combinación de bajo costo, alta confiabilidad y expandibilidad
  • Para fabricar un cartucho directamente, es indispensable una comprensión precisa de esta estructura y de sus protocolos
  • Si se aprovechan activamente la comunidad y la abundante documentación, es posible reducir mucho la barrera de entrada al desarrollo integrado de hardware y software

Referencias y rutas de aprendizaje adicionales

  • El artículo Game Boy/Game Boy Color Architecture de Rodrigo Copetti
  • La documentación técnica de gbdev.io y Pan Docs
  • Diversos diseños open source de cartuchos y toolchains (por ejemplo, GBDK, RGBDS, etc.)
  • Ejemplo de proyecto hecho desde cero: abc.decontextualize.com

(En la segunda mitad del artículo original también se tratan elementos adicionales más complejos, como variaciones de diseño de MBC, memoria EEPROM/flash, IC de entrada/salida e integración de periféricos, pero los puntos anteriores corresponden al contenido central sobre el funcionamiento de los cartuchos de Game Boy)

1 comentarios

 
GN⁺ 2025-07-23
Opiniones en Hacker News
  • Quiero compartir mi experiencia usando el TXB0108 de TI. Por su función de autodetección de dirección parece que no hace falta agregar lógica de dirección aparte, pero en realidad no recomiendo usarlo. Si hay ruido eléctrico, puede invertirse la dirección y una entrada terminar comportándose como salida. A veces el dispositivo lo aguanta, y en casos peores aparece el fenómeno del llamado "humo mágico". Con muy mala suerte, incluso podría causar un accidente en un entorno industrial. Creo que este tipo de componentes, pensados para expertos, tienen demasiados riesgos ocultos como para promocionarse tanto. Solo deberían usarse si se conocen exactamente sus modos de falla o no hay otra alternativa.

    • Estos componentes de verdad son impredecibles. Con solo una o dos pulgadas de traza en la salida, o incluso solo un conector, el ringing de salida puede provocar con frecuencia una inversión automática de dirección. Están a un nivel prácticamente imposible de usar si no eres especialista. Justo en las situaciones donde más dan ganas de usarlos es donde más difícil resulta hacerlo.

    • De hecho me pasó que la dirección cambiaba constantemente a una velocidad enorme, generando ruido y oscilación graves. También tienen bastantes restricciones relacionadas con pull-downs, pero cuando ambos lados se llevaban en la misma dirección era más o menos manejable.

  • Mientras sigo posponiendo otras cosas, anoté algunas impresiones iniciales sobre el diseño de abc-pcb.pdf

    • Hacen falta capacitores de desacoplo alrededor de U6 y U8; la lógica LVC consume bastante al conmutar, así que deben colocarse cerca de las compuertas.
    • En el level translator WideBus de 16 bits hay que poner un capacitor en cada pin de alimentación; esos múltiples pines de alimentación están ahí por una razón.
    • La dirección del bus de salida de U6 parece estar mal; por mi experiencia uso casi siempre Altium y no conozco mucho KiCad, así que quizá no sea un problema.
    • VBUS no debería usarse como señal lógica si se busca confiabilidad; cuando la velocidad de subida es lenta cambia el timing de conmutación y puede haber comportamientos extraños. Recomiendo limpiar la señal con un Schmitt trigger.
    • El puerto USB no tiene protección ESD. Si quieres que dure mucho, sugeriría probar con una pieza como ECMF02-4CMX8, aunque soldarla puede ser un poco molesto.
    • El esquemático de Q1 no es intuitivo. Sería mucho más claro dibujar simplemente los dos MOSFET de forma normal y ponerles sus designadores.
    • En el chip IC2 (¿por qué IC2 y no U2?), las líneas 4, 5, 6 y 7 están en accionamiento cruzado. No se debe poner a tierra ambos lados: solo el lado de entrada. La salida debe dejarse sin conectar o hacerse pull con una resistencia.
    • El pin SENSE de U7 casi no consume corriente, así que no hace falta desperdiciar energía en un divisor resistivo.
    • También vendría bien agregar uno o dos capacitores electrolíticos grandes para amortiguar la PDN (red de distribución de energía).
  • Ojalá este artículo hubiera existido cuando yo estaba haciendo cartuchos personalizados.
    En mi juego Cubeat conecté un chip OPL3-L al pin de audio in del GB para implementar música FM, y la lógica MBC usa solo chips lógicos discretos de la serie 7400.
    Algún día de verdad quiero terminarlo y lanzarlo; probar este tipo de trucos curiosos en GB también es una experiencia muy divertida.
    Información sobre Cubeat

  • Este es exactamente el nivel de detalle que quería sobre la estructura de los cartuchos de Game Boy.

  • Me parece novedosa la idea de que los cartuchos de Game Boy proporcionen RAM y espacio de disco junto con la app; pensándolo bien, también tiene lógica.
    Si los teléfonos funcionaran así, quizá cada ciertos años, cuando mejorara la tecnología de chips, podrías comprar un cartucho nuevo para ejecutar apps más potentes o incluso actualizar conectando una nueva antena.

    • Los teléfonos modulares se han propuesto desde hace tiempo, pero no han resultado prácticos ni especialmente útiles. Si conectas todo por sockets, aumenta la latencia entre chips y baja la confiabilidad, y eso es todavía peor en un producto que pasa el día entero sacudiéndose dentro del bolsillo.
      Además, en un teléfono no suele quedar obsoleta una sola cosa: normalmente quieres actualizar al mismo tiempo la cámara, la pantalla, el CPU, la RAM, la batería y casi todo lo demás. En ese caso conviene más comprar un teléfono nuevo que ir cambiando piezas sueltas; lo único que realmente ahorras es, más o menos, el costo de la carcasa.

    • Se está discutiendo un sistema de hotpatch para la ROM de microcontroladores, y por eso se ve claramente la ventaja de una estructura donde toda la app va cargada en el chip y se ejecuta de inmediato. Pero como las necesidades de los usuarios cambian cada vez más, parece que todo se vuelve más complejo.

    • Sin duda es una buena idea, pero me preocupa si el límite no terminaría siendo el rendimiento del hardware del dispositivo donde se inserta.
      Puedes poner RAM más rápida en el cartucho, pero no está claro si la placa original realmente podría aprovecharla.
      Aunque fuera posible agregar almacenamiento más rápido, si el hardware de soporte sigue siendo el mismo, no es seguro cuánto efecto práctico tendría.

    • Incluso me imagino conectar también una cámara.

  • Sobre la afirmación de que al hacer software personalizado para Game Boy no hace falta saltarse hardware antipiratería o region lock, preguntan si en la práctica no hay que pasar de todos modos la verificación del logo.

    • Probablemente eso quiere decir que no hace falta modificar ni hackear el hardware, sino solo incluir cierto blob específico en el encabezado ROM. Si usas la toolchain RGBDS (RGBFIX), puede insertarse automáticamente.
      Y además, después del fallo Sega v. Accolade, en la práctica este método de verificación de títulos ya no tiene fuerza como exigencia legal, así que no hay una barrera real de evasión.
  • Da pena que devrs.com, un sitio de referencia sobre desarrollo para GB que visitaba mucho antes, ya no esté activo. La mayoría de los enlaces ya estaban caídos, pero era un lugar con muchos proyectos inspiradores.

  • También vale la pena revisar el video de la charla Ultimate Game Boy Talk (presentación de 33c3).
    Ultimate Game Boy Talk - 33c3

  • Mi copia de Pokemon Blue pasó por la lavadora y hasta por la secadora hace 20 años, y todavía funciona bien. De verdad era hardware muy resistente. Me pregunto si una tarjeta SD aguantaría algo así.

    • Creo que el calor de la secadora sería un problema mayor que el agua.
  • Este mes empecé con KiCad y diseño de PCB por diversión, y me pregunto si existe algún caso en que alguien haya recreado por completo un PCB original de Game Boy y luego lo haya publicado como open source.

    • Una empresa llamada FunnyPlaying fabrica y vende sus propios PCB de GBC y GBA, pero es difícil encontrar versiones open source.
      En el GitHub de nataliethenerd está el proyecto de ingeniería inversa de CGB, pero la licencia es no comercial.
      Explica: "Usando una placa CGB-CPU-04, la escaneé, la lijé y la redibujé para ordenar el esquemático de CGB; para los valores y demás consulté el circuito original".

    • También me interesa saber si recomiendan materiales útiles como referencia para diseño de PCB.