Arquitectura de la Game Boy / Game Boy Color

Un análisis práctico por Rodrigo Copetti

Edición clásica - Última actualización: 14 de septiembre de 2024

Idiomas disponibles: 🇬🇧 - English, 🇫🇷 - Français, 🇵🇱 - Polski, 🇪🇸 - Español, 🇨🇳 - 简体字, 🇹🇷 - Türkçe, 👋 - Añadir traducción


Acerca de esta edición

La edición 'clásico' es una versión alternativa a la contraparte 'moderna'. No requiere Javascript, CSS de última generación o HTML convoluted para trabajar, lo que lo hace ideal para lectores que utilizan herramientas de accesibilidad o navegadores de Internet heredados. Por otra parte, los usuarios de eBooks ahora pueden consultar la edición eBook.

Esta edición es idéntica en cuanto al contenido. Sin embargo, los widgets interactivos han sido simplificado para trabajar con HTML puro. De cualquier manera, esto ofrecerá un enlace al artículo original en caso de que el lector quiera comprobar la "versión completa".

Como siempre, este artículo está disponible en Github para permitir a los lectores reportar errores o proponer cambios. También hay una lista de lectura de apoyo disponible para ayudar a entender la serie. El autor también acepta donaciones y traducciones para ayudar a mejorar la calidad de los artículos actuales y próximos.


Tabla de Contenidos

  1. Imágenes de apoyo
  2. Una introducción rápida
    1. El análisis variado
  3. CPU
    1. El núcleo de la CPU
      1. El efecto Color
    2. Acceso al hardware
    3. Memoria Disponible
  4. Gráficos
    1. Organizando el contenido
    2. Construyendo el frame
      1. Tiles
      2. Capa de fondo
      3. Ventana
      4. Sprites
      5. Resultado
    3. Secretos y limitaciones
      1. Efecto de tambaleo (‘Wobble’)
    4. Las adiciones de color
      1. Modos de operación
      2. Organizando el (nuevo) contenido
        1. Los visuales
        2. El espacio extra
  5. Audio
    1. Funcionalidad
      1. Pulso
      2. Onda
      3. Ruido
    2. Secretos y limitaciones
  6. Sistema operativo
    1. La secuencia revisada
  7. Juegos
    1. Tipos de cartuchos
    2. Comunicación externa
  8. Antipiratería
  9. Eso es todo amigos
  10. Copyright and permissions
  11. Fuentes / Sigue leyendo
  12. Contribuir

Imágenes de apoyo

Modelo

Image
La Game Boy original.
Lanzada el 21/04/1989 en Japón, el 31/07/1989 en Estados Unidos y el 28/09/1990 en Europa.
Image
La sucesora de nueva generación llamada Game Boy Color.
Lanzada el 21/10/1998 en Japón, 18/11/1998 en América del Norte, 23/11/1998 en Europa.

Motherboard

Image
Motherboard
Mostrando la revisión '04'. Ten en cuenta que 'DMG' es el identificador del modelo original de Game Boy.
Image
Motherboard con partes importantes etiquetadas

Diagrama

Image
Diagrama de arquitectura
Basada en la Game Boy original.

Una introducción rápida

La Game Boy puede ser entendida como una versión portátil de la NES con potencia limitada, pero pronto se verá que incluye nueva funcionalidad muy interesante.

El análisis variado

La inmensa popularidad de esta consola resultó en una variedad de revisiones (es decir, la Game Boy Pocket, Light, e incluso en forma de cartuchos para la Super Nintendo). De hecho, la marca Game Boy cubre dos generaciones. Dentro de la cuarta generación encontramos la Game Boy monocroma y sus revisiones, y en la siguiente generación reside la Game Boy Color (lanzada después de la desaparición de la Virtual Boy). La buena noticia es que este artículo cubre ambos extremos. Entonces, al final, tendrás una buena comprensión de cómo funciona la Game Boy y cómo su tecnología evolucionó para convertirse en la Game Boy Color.


CPU

En lugar de colocar chips estándares en la placa base, Nintendo optó por un único chip para alojar (y ocultar) la mayor parte de los componentes, incluyendo la CPU. Este tipo de chip se llama System On a Chip (SoC) y, en este caso, ha sido específicamente diseñado para esta consola, permitiendo a Nintendo adaptarlo a sus necesidades (eficiencia energética, anti-piratería y E/S extra, entre otras cosas). Al mismo tiempo, este chip no se encuentra en ningún catálogo comercial, lo que significa que a los competidores de entonces les resultaba más difícil clonarlo.

Dicho esto, el SoC que se encuentra en la Game Boy se conoce como DMG-CPU o Sharp LR35902 [1] y, como indica el nombre, es fabricado por Sharp Corporation. Esta empresa, junto con Ricoh (el proveedor de CPU de NES), disfrutaba de una estrecha relación con Nintendo.

El núcleo de la CPU

Dentro del DMG-CPU, el procesador principal es un Sharp SM83 [2] y es una mezcla entre el Z80 (la misma CPU utilizada en la Sega Master System) y el Intel 8080. Funciona a ~4.19 MHz, que es más rápido que la CPU promedio de 1 MHz, pero recuerda que las velocidades de reloj pueden ser engañosas.

Image
El DMG-CPU, encontrado en la placa base de la Game Boy.

Ahora, cuando hice el análisis de la Master System, expliqué que el Z80 es en sí mismo un superconjunto del 8080. Entonces, ¿qué tiene y qué le falta al SM83 de esos dos? [3]

Para finalizar, también se añadieron nuevas instrucciones que no están presentes ni en el Z80 ni en el 8080. Optimizan ciertas operaciones relacionadas con la forma en que Nintendo/Sharp organizó el hardware. Un ejemplo es la nueva instrucción LDH (que significa ‘cargar desde la memoria alta’ [5]), que ha sido específicamente incluida para operar en los últimos 256 bytes del mapa de memoria (donde las direcciones comienzan en $ff00) y, lo más importante, ocupa un byte menos (y, por lo tanto, es ligeramente más rápida).

El efecto Color

Image
Placa base de la Game Color [6].
Image
La misma imagen con las partes importantes marcadas.

Casi 10 años después, tras el abandono de la Virtual Boy y su hardware de vanguardia, llegó una humilde sucesora: la Game Boy Color. Dentro de ella, hay un nuevo SoC denominado CPU CGB que lleva algunas adiciones. Sin embargo, su núcleo de CPU SM83 sigue siendo el mismo, excepto por su velocidad de reloj duplicada (ahora funcionando a ~8.38 MHz).

Es difícil pensar que después de una década Nintendo aún incluiría la misma CPU, pero tal decisión viene con las siguientes ventajas:

Sin embargo, esto viene a costa de adoptar tecnología obsoleta para los estándares de finales de los 90. Solo tienes que mirar el estado del mercado de CPU para notar las capacidades que Nintendo se estaba perdiendo (para ser justos, Nintendo lo intentó con el Virtual Boy).

Acceso al hardware

El SM83 mantiene un bus de datos de 8 bits y un bus de direcciones de 16 bits, por lo que se puede direccionar hasta 64 KB de memoria. El mapa de memoria está compuesto principalmente por los siguientes puntos finales [7]:

Esto se explicará a lo largo de este artículo.

Memoria Disponible

Image
Arquitectura de memoria del DMG (Game Boy original). La PPU arbitra el acceso a la VRAM.

Nintendo instaló 8 KB de RAM en la placa base, esto es para uso general (que llamaron Work RAM o ‘WRAM’) [8]. Fíjese que es cuatro veces más que la cantidad incluida en la NES.

Hay un adicional de 127 B de RAM en el SoC. Se llama High RAM o ‘HRAM’, y proporciona un pequeño espacio para datos que se puede acceder más rápido a través de la instrucción LDH única del SM83. Esto es muy similar al modo ‘Zero Page’ del 6502 [9], que también optimizó el rendimiento basado en la ubicación de la memoria. Ahora, la High RAM no es técnicamente más rápida de acceder que la RAM general, pero es un área priorizada para la CPU. Verás lo que esto significa cuando llegues a la sección ‘Gráficos’, donde hablo del componente DMA.

Image
Arquitectura de memoria ampliada del CGB (Game Boy Color). De nuevo, la PPU arbitra el acceso a la VRAM.

Más tarde, con la variante Color, Nintendo amplió la WRAM a 32 KB. Sin embargo, dado que la CPU se mantuvo sin cambios (particularmente sus capacidades de direccionamiento), no es posible conectar toda la nueva memoria sin desbordar primero el espacio de direcciones disponible. Para solucionar esto, los ingenieros de Nintendo implementaron cambio de banco. Originalmente encontrado en los cartuchos de NES, la Game Boy Color utiliza el mismo principio para acceder a esos 32 KB utilizando solo 8 KB de espacio de memoria. El truco es simple: los últimos 4 KB se pueden intercambiar utilizando siete bancos diferentes. En consecuencia, la CPU agrupa un registro adicional (llamado SVBK) que actúa como el cambiador de banco, esto es lo que los desarrolladores deben usar para examinar la memoria extendida.


Gráficos

Todos los cálculos relacionados con los gráficos son realizados por la CPU. Una vez finalizados, la Picture Processing Unit (‘PPU’ o Unidad de procesamiento de imágenes) los renderiza. Este es otro componente encontrado dentro del DMG-CPU y podría describirse como una versión mejorada del chip de gráficos del predecesor (con el mismo nombre).

La imagen se muestra en una pantalla integrada de tipo LCD a una resolución de 160×144 píxeles y, en el caso del Game Boy monocromo, muestra 4 tonos de gris (blanco, gris claro, gris oscuro y negro). Dado que la Game Boy original tiene una pantalla LCD verde, la imagen se verá verdosa.

Si has leído el artículo de la NES con anterioridad, puede que recuerdes que la PPU fue diseñada a partir del funcionamiento del tubo de rayos catódicos (CRT). Sin embargo (y por razones obvias), tenemos una pantalla LCD en la Game Boy. Pues bien, la nueva PPU también sigue esa metodología ya que los LCDs requieren ser refrescados también. Al hacerlo, esta consola disfrutará de efectos basados en CRT que anteriormente permitieron a los desarrolladores de NES crear contenido imaginativo.

Organizando el contenido

Image
Arquitectura de memoria de la PPU.

La PPU está conectada a 8 KB de VRAM o ‘Display RAM’. Al hacerlo, también proporciona acceso arbitrado a la CPU. Esos 8 KB contendrán la mayor parte de los datos que la PPU necesitará para renderizar los gráficos. El resto de materiales se almacenarán dentro de la PPU, ya que requieren tasas de acceso más rápidas.

El juego se encarga de rellenar las diferentes áreas con el tipo de dato correcto. Además, la PPU expone registros para que el juego pueda instruir a la PPU sobre cómo se organiza esos datos. No obstante, hay muchas reglas a seguir (lo verás en las siguientes secciones).

Construyendo el frame

Veamos cómo la PPU logra dibujar cosas en pantalla. Para fines de demostración, se utilizará como ejemplo Super Mario Land 2.

Tiles

Image
Múltiples mosaicos.
Image
Múltiples mosaicos separados en una cuadrícula.
Image
Un único mosaico.
Tiles encontrados en la Tabla de Patrones (o ‘Tile pattern table’).

La PPU utiliza mosaicos como ingrediente principal para renderizar gráficos, especialmente, sprites y fondos [10].

Los tiles son sencillamente mapas de bits de 8x8 pixeles almacenados en VRAM en una región llamada Tile Set o ‘Tile pattern table’, cada pixel corresponde con uno de los cuatro tonos de gris disponibles. En la práctica, sin embargo, los tonos de gris se seleccionan a través de una paleta de ‘color’. Los Game Boys monocromos contienen registros que definen estas paletas. Como se explicó antes, solo hay cuatro colores/tonos de grises para elegir, por lo que un único registro de 8 bits puede contener una paleta de cuatro tonos sin problema. Dicho esto, el sistema proporciona tres registros (por lo tanto, tres paletas programables) con uso restringido (más sobre esto se explica más adelante).

Además, los mosaicos se agrupan en dos tablas de patrones.

Para construir la imagen, los mosaicos se referencian en otro tipo de tabla llamada Mapa de mosaico. Esta información le dirá a la PPU donde renderizar estos tiles. Dos mapas son almacenados para construir diferentes capas de un frame.

Las siguientes secciones explican como son utilizados los ‘Tile maps’ para construir las capas.

Capa de fondo

Image
Mapa de fondo asignado en la VRAM.
Image
Área seleccionada del mapa de fondo. Nótese que la parte seleccionada incluye una porción de la parte superior, esta será superpuesta por la Capa de ventana.
Image
Mapa de fondo mostrado.
Proceso de renderización del mapa de fondo.

La capa de fondo es un mapa de 256x256 píxeles (32x32 tiles) que contiene tiles estáticos. Sin embargo, recuerda que sólo 160x144 píxeles son visible en pantalla, por lo que el juego decide qué parte es seleccionada para mostrarse. Los juegos pueden también mover el área visible durante el gameplay, así es como se consigue el Efecto de desplazamiento (Scrolling effect).

Uno de los dos ‘Tile maps’ puede ser utilizado para proyectar la capa de fondo. Además, solo hay una paleta disponible para esta capa.

Ventana

Image
Mapa de ventana asignada.
Image
Mapa de ventana mostrada. El juego la activa durante la última línea escaneada (scan-line). Por lo tanto, sólo las primeras filas se renderizan en la parte inferior de la pantalla.
Proceso de renderización del mapa de ventana.

La ventana es una capa de 160x144 píxeles que contiene tiles mostrados encima del fondo y sprites. Esta capa no se desplaza.

El mapa de mosaicos restante se puede asignar a la capa de ventana, también comparte la misma paleta con la capa de fondo.

En definitiva, esto puede sonar como una característica tonta. Dado que la Ventana no tiene transparencia y por lo tanto oscurece completamente el Fondo, te puedes preguntar ‘¿Para qué sirve?’. Pues bien, tanto el fondo como la ventana se pueden utilizar simultáneamente en diferentes partes de la pantalla. Esto está destinado a mostrar información principalmente en la parte inferior de la pantalla, pero mientras que en la NES esto requería realizar escrituras complejas y sincronizadas, la PPU del Game Boy puede manejarlo automáticamente.

Por lo tanto, los juegos lo utilizan normalmente para mostrar estadísticas del jugador, puntuaciones y otra información “siempre activa”.

Sprites

Image
Capa de sprite renderizado.

Los sprites son tiles que pueden moverse de forma independiente alrededor de la pantalla. También pueden superponerse entre sí y aparecer detrás del fondo, el gráfico visible se decidirá basándose en el atributo de prioridad.

Esta capa también tiene un color extra disponible: Transparente. Inicialmente, esto significa que solo pueden mostrar tres grises diferentes en lugar de cuatro. Afortunadamente, esta capa en particular está provista de dos paletas dedicadas para elegir.

La Memoria de Atributo de Objeto o ‘OAM’ es un mapa almacenado dentro de la PPU que especifica los mosaicos que serán utilizados como sprites. En lugar de usar un mapa de mosaico, los sprites se definen en la OAM. Los juegos típicamente llenan esta región llamando a la unidad OAM DMA localizada dentro del chip, la DMA obtiene datos de la RAM principal o de la ROM del juego y los envía a la OAM. Ahora, mientras la DMA está trabajando, la CPU no puede acceder a la memoria externa (de ahí la importancia de usar HRAM durante ese período).

Aparte del índice de mosaicos, cada entrada contiene los siguientes atributos: posición X-Y, paleta elegida, prioridad y ‘flip flags’ (permitiendo girar el mosaico vertical y horizontalmente).

La PPU está limitada a renderizar hasta diez sprites por escaneo de línea y hasta 40 por frame, sobrecargar esto hará que no se muestren algunos sprites.

Resultado

Image
Resultado final ¡Tachán!

Una vez finalizado el frame… ¡Es hora de pasar al siguiente! Sin embargo, la CPU no puede modificar las tablas mientras la PPU está leyendo la VRAM, por lo que el sistema proporciona un conjunto de interrupciones que se activan cuando la PPU está inactiva. Tal vez recuerdes este comportamiento por la NES.

Cuando se completa una sola línea de exploración, comienza el período de Horizontal Blank. Esto permite manipular la parte del frame que aún no se ha dibujado.

Cuando se completan todas las líneas de exploración, comienza el período de Vertical Blank y se llama a una interrupción dedicada. En ese momento, el juego puede actualizar los gráficos para el siguiente frame.

Hay un estado extra llamado ‘OAM search’ que se activa al inicio del escaneo de línea, en ese momento la PPU está procesando qué sprites se mostrarán en esa línea de escaneo, así que el juego puede actualizar cualquier región excepto la OAM.

Secretos y limitaciones

La inclusión de la Capa de ventana y las interrupciones adicionales permitieron nuevos tipos de contenido y efectos.

Efecto de tambaleo (‘Wobble’)

The Legend of Zelda: Link’s Awakening (1993). ¡Spoilers!

Las interrupciones horizontales permitieron alterar el frame antes de completarse. Lo que significa que se podría aplicar un valor de desplazamiento diferente a cada línea, de tal manera que cada fila del frame se desplazara a diferentes intervalos.

Esto resultó en un Efecto de tambaleo (Wobble) (aunque no estoy seguro de que ese sea su nombre oficial).

Las adiciones de color

El PPU de la Game Boy Color se comporta como un superconjunto del original. Verás ahora cuáles son las adiciones del modelo denominado ‘Color’ de esta marca.

Modos de operación

Image
The Legend of Zelda: Link’s Awakening DX (1998).
Un juego híbrido de Game Boy Color ejecutándose en modo CGB.
Image
Super Mario Land 2, visto desde una Game Boy Color. Este último añade una paleta colorizada y se ejecuta en modo DMG.

Para empezar, por razones de compatibilidad, el nuevo PPU tiene dos modos de operación. Sin embargo, Nintendo quería que los usuarios de Color vieran mejoras incluso con los juegos únicamente monocromáticos. Por consiguiente, los dos modos de operación son los siguientes:

Organizando el (nuevo) contenido

La placa madre del CGB ahora alberga 16 KB de VRAM en su lugar, lo cual es el doble de la cantidad original de VRAM. Debido a las limitaciones de direccionamiento de la CPU, este nuevo arreglo se implementa en forma de dos bancos de 8 KB, con un nuevo registro (llamado VBK) actuando como un conmutador. Por otro lado, el PPU puede acceder a los dos bancos al mismo tiempo. Al final del día, esto significa que los programadores solo necesitan llenar los bancos VRAM con la ayuda de VBK, y luego especificar en el mapa de mosaicos el banco donde se encuentra el mosaico, para que el PPU pueda encargarse del resto.

Dicho esto, ¿qué puedes hacer con la VRAM extra? Muchas cosas:

Los visuales

Gracias al nuevo PPU, los programadores ahora pueden definir paletas de colores con 32,768 colores a elegir.

En primer lugar, los desarrolladores ahora deben poblar una nueva área llamada Memoria de Paleta, que almacena hasta dieciséis paletas de colores (la mitad para el Fondo y la Ventana, la otra mitad para los sprites) que codifican cuatro colores [11]. Cada entrada cabe en un valor de 16 bits (2 bytes) y solo se usan 15 bits. La Memoria de Paleta no es direccionada por la CPU, sin embargo, se utiliza un nuevo registro como un búfer para escribir sobre esta memoria (una metodología encontrada en la Super Nintendo). En general, así es como la CPU define paletas.

Dicho esto, los mosaicos de fondo y ventana pueden referenciar cualquiera de esas ocho paletas. Lo mismo ocurre con los mosaicos de Sprites, excepto que están restringidos a paletas de tres colores, ya que una entrada está reservada para el color ‘transparente’.

El espacio extra

Continuando, los conjuntos de mosaicos ahora son el doble de grandes. Por lo tanto, los programadores pueden almacenar el doble de mosaicos en VRAM. Los mapas de mosaicos de fondo/ventana se han extendido también, resultando en metadatos extra siendo codificados. Por consiguiente, expandiendo las capacidades de estas capas. Por ejemplo, sus mosaicos ahora pueden ser invertidos horizontal y verticalmente, ahorrando al juego de almacenar gráficos duplicados en VRAM (lo cual, a su vez, puede ser explotado para dibujar más contenido único).

Además, la CPU CGB también incluye una unidad de DMA adicional, que puede copiar el contenido del Game Pak o WRAM a VRAM. Opera en dos modos [12]:

Una vez más, esta unidad ofrece a los programadores nuevas posibilidades para proporcionar contenido más enriquecido, aprovechando períodos originalmente destinados a la inactividad.


Audio

El sistema de audio lo lleva a cabo la Unidad de Procesamiento de Audio (APU), un chip PSG con cuatro canales [13].

Curiosamente, esta es una de las pocas secciones que no ha evolucionado entre modelos. De hecho, ni siquiera puede acelerarse, ya que si cambias la velocidad de los osciladores, no escucharás sonidos ‘mejores’, sino un tono más alto.

Funcionalidad

Cada uno de los cuatro canales está reservado para un solo tipo de forma de onda:

Pulso

Osciloscopio del canal de pulso 1.
Osciloscopio del canal de pulso 2.
Osciloscopio de todos los canales de audio.
Pokémon Rojo/Azul (1996).

Las ondas de pulso tienen un sonido beep distintivo y son utilizadas para melodía o efectos de sonido.

La APU reserva dos canales para cada onda de pulso. Estos producen uno de cuatro tonos diferentes, resultante de variar la anchura del pulso. El primer canal tiene disponible un control de ‘Sweep’ exclusivo.

Debido al número limitado de canales, la melodía a menudo será interrumpida, especialmente cuando ciertos efectos se reproduzcan durante el gameplay. Esto es muy notable en juegos como Pokémon Rojo/Azul cuando durante un combate, el grito del Pokémon se superpone por encima de todos los canales de música; esta es también la razón por la cual ninguna música de batalla Pokémon usa percusión.

Onda

Osciloscopio del canal de onda.
Osciloscopio de todos los canales.
Pokémon Rojo/Azul (1996).

La APU permite definir una forma de onda personalizada para ser escuchada desde su tercer canal. La onda está compuesta de 32 muestras de 4 bits que se almacenan en una tabla de ondas.

Este canal también permite controlar su frecuencia (permitiendo producir diferentes notas musicales de la misma muestra) y volumen.

Ruido

Osciloscopio del canal de ruido.
Osciloscopio de todos los canales de audio.
Pokémon Rojo/Azul (1996).

El ruido es básicamente un conjunto de formas de onda aleatorias que suenan como estática blanca. Se reserva un canal para ello.

Los juegos lo utilizan para percusión o efectos de ambiente.

Este canal solo tiene disponibles 2 tonos para usar, uno produce estática limpia y el otro produce estática robótica. Su frecuencia también se puede controlar.

Secretos y limitaciones

El mezclador (mixer) produce sonido estéreo, por lo que los canales pueden asignarse al lado izquierdo o derecho ¡pero esto sólo se puede escuchar con auriculares! El altavoz es monofónico.

Además, el chip del mezclador también está conectado a un pin dedicado en el cartucho, permitiendo transmitir un canal adicional con la condición de que el cartucho tenga que producir realmente el sonido analógico (esto solo es posible con hardware extra). Sin embargo, ningún juego en el mercado terminó usando esta característica, y tampoco encontrarás este pin en el Game Boy Advance en su subsistema compatible con versiones anteriores.


Sistema operativo

A diferencia de la NES, que se iniciaba directamente en el juego, la Game Boy fue diseñada para arrancar siempre desde una ROM interna de 256 Bytes, y solo luego saltar al código del juego. El proceso de arranque es el siguiente [14]:

  1. Después de encender la consola, la CPU comienza leyendo en la dirección 0x0000 (ubicada en la ROM de la Game Boy).
  2. Se inicializan la RAM y la APU.
  3. El logotipo de Nintendo se copia del cartucho ROM a la Display RAM, después se dibuja en el borde superior de la pantalla. Si no hay cartucho insertado, el logo contendrá tiles basura. Lo mismo puede ocurrir si está mal insertado.
  4. El logotipo se desplaza hacia abajo y se reproduce el famoso sonido de po-ling.
  5. El logotipo del juego se compara con el que está almacenado en la ROM de la consola. Una suma de verificación (checksum) rápida se hace en la cabecera de la ROM del cartucho para asegurarse de que éste se ha insertado correctamente. Si alguna de estas verificaciones falla, la consola se congela.
  6. La ROM de la consola desaparece del mapa de memoria.
  7. La CPU comienza a ejecutar el juego.

Curiosamente, el logo de Nintendo que se está mostrado en pantalla no se borra de la VRAM, de tal manera que los juegos pueden aplicar alguna animación o efecto para añadir su propio logo.

La pantalla de inicio de la Game Boy junto con 20y, una demo casera que juega con el logo.

La secuencia revisada

Image
La pantalla de inicio de la Game Boy Color, el logo ya no se desliza pero tiene un efecto arcoíris.

Una vez más, en el caso de la Game Boy Color, encontramos cambios drásticos en el contenido de la ROM. Por ejemplo, el tamaño de la ROM ahora es de 2 KB [15] y las rutinas muestran un nuevo comportamiento:


Juegos

Los juegos están escritos en ensamblador y tienen un tamaño máximo de 32 KB, esto se debe al limitado espacio de direcciones disponible. Sin embargo, con el uso de un Banco controlador de memoria (mapeador), los juegos pueden alcanzar un mayor tamaño. El cartucho (Game Pak) más grande encontrado en el mercado tiene una ROM de 1 MB (o 8 MB, en el caso del Game Boy Color).

Los Game Pak pueden incluir un reloj en tiempo real y una batería externa junto con SRAM para guardar partidas, aunque todo esto es opcional.

Tipos de cartuchos

Debido a los dos modos de operación que soportaba la Game Boy Color, Nintendo enumeró tres tipos diferentes de juegos de Game Boy:

Comunicación externa

Image
Cable de enlace Game Boy para múltiples variantes de la consola [16]. Desde el lanzamiento de la consola original, las revisiones subsiguientes miniaturizaron el conector manteniendo el mismo número de pines.

Por primera vez, los juegos pueden comunicarse con otras Game Boys mediante el uso de un cable Game Boy Link, el cual proporciona funcionalidad multijugador, por ejemplo. La interfaz utiliza un protocolo bastante primitivo de conexión en serie.

La Game Boy original transfiere información a 8 Kbit/segundo (1 KB/seg), mientras que la variante Color puede alcanzar hasta 512 Kbit/segundo (64 KB/seg), esta última velocidad se conocía como modo ‘alta velocidad’.

La última variante también viene con un emisor y receptor de infrarrojos (compuesto por un LED y un fototransistor, respectivamente) [17]. Esto hizo posible intercambiar datos de forma inalámbrica entre Game Boy Colors, como se ve en juegos como Pokémon Oro y similares. Sin embargo, encontrarás que el sistema no implementa ningún protocolo de comunicación, solo un único registro (RP) que codifica la acción del sensor IR (emitir o recibir), el bit único (0 o 1) transferido y el último bit recibido. No obstante, para aliviar las cosas a los desarrolladores, Nintendo incluyó una implementación de referencia en el manual oficial del desarrollador de Game Boy [18].


Antipiratería

Como habéis visto en la sección ‘Sistema Operativo’, la consola nunca ejecutará un juego de inmediato, primero realiza una serie de verificaciones que impiden la ejecución de cartuchos no autorizados y también se asegura de que el cartucho ha sido insertado correctamente.

Para pasar estas comprobaciones, los juegos tuvieron que incluir una copia del logotipo de Nintendo (en forma de mosaicos) en la cabecera de su ROM [19], de esta manera Nintendo podía hacer uso de las leyes de Copyright y marca registrada para controlar la distribución. ¿Inteligente, verdad?

Por el contrario, Sega v. Accolade posteriormente otorgó a cualquier empresa el derecho de usar logotipos con copyright para este tipo de requerimiento, ya que se incluye en el uso justo.

Dicho esto, se pueden implementar más medidas antipiratería dentro de los juegos, por ejemplo, verificando el tamaño de la SRAM (normalmente, es mayor en copias piratas) y realizando sumas de verificación (checksum) de la ROM en puntos aleatorios del juego.


Eso es todo amigos


Contribuir

Este artículo forma parte de la serie de Arquitectura de consolas. Si te ha resultado interesante, por favor considere donar. Tu contribución se usará para tener mas herramientas y recursos que ayudarán a mejorar la calidad de los actuales artículos y próximos.

Donate with PayPal
Become a Patreon

También puedes comprar la edición eBook en inglés. Trato las ganancias como donaciones.

Image

Esta es la lista de herramientas adquiridas o interesantes a adquirir:

Interesting hardware to get (ordered by priority)

De alternativa, puedes ayudar sugiriendo cambios y/o agregando traducciones.


Copyright and permissions

This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But you have to respect the license and reference the article properly. Please take a look at the following guidelines and permissions:

Article information and referencing

For any referencing style, you can use the following information:

For instance, to use with BibTeX:

@misc{copetti-gameboy,
    url = {https://classic.copetti.org/writings/consoles/game-boy/},
    title = {Game Boy / Color Architecture - A Practical Analysis},
    author = {Rodrigo Copetti},
    year = {2019}
}

or a IEEE style citation:

[1]R. Copetti, "Game Boy / Color Architecture - A Practical Analysis", Copetti.org, 2019. [Online]. Available: https://classic.copetti.org/writings/consoles/game-boy/. [Accessed: day- month- year].

Special use in multimedia (Youtube, Twitch, etc)

I only ask that you at least state the author’s name, the title of the article and the URL of the article, using any style of choice.

You don’t have to include all the information in the same place if it’s not feasible. For instance, if you use the article’s imagery in a Youtube video, you may state either the author’s name or URL of the article at the bottom of the image, and then include the complete reference in the video description. In other words, for any resource used from this website, let your viewers know where it originates from.

This is a very nice example because the channel shows this website directly and their viewers know where to find it. In fact, I was so impressed with their content and commentary that I gave them an interview 🙂.

Appreciated additions

If this article has significantly contributed to your work, I would appreciate it if you could dedicate an acknowledgement section, just like I do with the people and communities that helped me.

This is of course optional and beyond the requirements of the CC license, but I think it’s a nice detail that makes us, the random authors on the net, feel part of something bigger.

Third-party publishing

If you are interested in publishing this article on a third-party website, please get in touch.

If you have translated an article and wish to publish it on a third-party website, I tend to be open about it, but please contact me first.


Fuentes / Sigue leyendo

Audio

CPU

Juegos

Gráficos

Sistema Operativo

Fotografía