Arquitectura Game Boy Advance

La mayoría de los componentes se combinan en un único paquete denominado CPU AGB. Este contiene dos CPU completamente diferentes:

• Un Sharp SM83 funcionando a 8,4 o 4,2 MHz: ¡Si es la misma CPU de Game Boy! Se usa para ejecutar juegos de Game Boy (DMG) y Game Boy Color (CGB). Mi artículo anterior ofrece un resumen de la predecesora.
• Un ARM7TDMI funcionando a 16,78 MHz: este es el nuevo procesador en el que nos centraremos; con toda seguridad ejecuta juegos de Game Boy Advance.

Ten en cuenta que ambas CPU nunca funcionarán al mismo tiempo ni realizarán ningún co-procesamiento extravagante. La única razón para incluir el muy antiguo Sharp es la retrocompatibilidad.

Dicho esto, adentrémonos en el chip ARM. Sin embargo, como es la primera CPU ARM que se trata en esta serie, déjame empezar por los antecedentes históricos de esta familia. ¡Prometo que vale la pena!

El milagro de Cambridge

La historia de los orígenes de la CPU ARM y su posterior ascenso a la fama es fascinante. Aquí encontramos una combinación de inversión pública, crecimiento exponencial, decisiones desacertadas y asociaciones de largo recorrido.

El auge de Acorn Computers

El BBC Micro (1981) con una caja de discos de 5¼ encima , el primer disco incluye el juego Elite (1984).

La placa ARM Evaluation Board (1986), un módulo 'Tube' con una CPU ARM1. La encontré en The Centre for Computing History (Cambridge, Reino Unido).

A finales de los años 70, Reino Unido vivía tiempos convulsos. La economía intervencionista construida sobre los ideales de posguerra había llegado a su fin, y el péndulo pronto osciló hacia las reformas de libre mercado. En medio de esta tormenta, iniciativas con sede en Cambridge como Acorn Computers, junto con Sinclair y otras similares, vendían kits de ordenador a laboratorios y aficionados. Al igual que las empresas estadounidenses y japonesas, los ordenadores de Acorn dependían de la CPU 6502 y un dialecto propietario de BASIC.

Al entrar en los años 80, los intereses ministeriales dentro del nuevo gobierno británico llevaron a la creación de un proyecto para mejorar la alfabetización en informática en las escuelas . Gracias al próximo 'Proton' de Acorn, la empresa obtuvo el contrato para construir un ordenador asequible que cumpliera con la visión del gobierno. El resultado fue el BBC Micro (apodado el 'Beeb'), que disfrutó de un éxito significativo entre escuelas, profesores y estudiantes. Dentro del Micro, Acorn incorporó una interfaz vanguardista 'Tube' que podía ampliar el ordenador con un segundo procesador. Esto allanaría el camino para la próxima gran inversión de Acorn.

Durante el desarrollo de su próximo producto, esta vez enfocado a empresas, Acorn no encontró una CPU adecuada para suceder a la 6502. La presión por innovar contra la competencia japonesa y estadounidense, combinada con una planificación desafortunada, colocó a Acorn en una situación financiera complicada. Por lo tanto, se encargó a una nueva división de Acorn la producción de una CPU convincente. Para sortear las restricciones recientes de Acorn, el equipo de CPU basó su arquitectura en las enseñanzas de un artículo de investigación llamado The Case for the Reduced Instruction Set Computer y su prototipo, el CPU RISC . Finalmente, en 1985, Acorn entregó la CPU ARM1 como un módulo Tube para el BBC Micro, pero solo se comercializó para fines de I+D. No sería hasta 1987, con la introducción del primer ordenador Acorn Archimedes, cuando los chips ARM (para entonces, la CPU ARM2) tomarían un papel central.

Una nueva empresa de CPU

Un modelo tardío del Newton... después de jugar con él.

Durante la comercialización del Acorn Archimedes, Apple se sintió cautivada por las CPUs energéticamente eficientes de Acorn, pero la empresa estadounidense aún no estaba convencida de que la última ARM3 de Acorn fuera adecuada para el nuevo proyecto estrella de Apple, el Newton. Sin embargo, en lugar de alejarse (después de todo, Acorn era un competidor), ambos exploraron la posibilidad de evolucionar la ARM3 para cumplir los requisitos de Apple , a saber, frecuencia de reloj flexible, MMU integrada y direccionamiento completo de 32 bits.

Esta colaboración pronto se convirtió en una asociación en la que Acorn, Apple y VLSI (fabricante de chips ARM) crearon una nueva empresa dedicada exclusivamente al desarrollo de CPUs ARM. Apple proporcionó la inversión (obteniendo el 43% de la participación), Acorn compartió su personal y VLSI se encargó de la fabricación. En 1990, Advanced RISC Machines (ARM) Ltd surgió con Robin Saxby como su presidente ejecutivo.

Años después, Apple finalmente lanzó el Newton MessagePad con un ARM610, perteneciente a la siguiente generación de chips ARM, moldeada por las aportaciones de Apple. Mientras tanto, Acorn también lanzó el RiscPC utilizando las nuevas CPUs.

Ahora, mientras Acorn y Apple seguían rezagados en el mercado de ordenadores y dispositivos portátiles, ARM ideó un modelo de negocio radical. Sin involucrarse en la fabricación, la visión de Saxby consistía en licenciar la propiedad intelectual de ARM, en forma de diseños de CPU y su set de instrucciones . Esto otorgó a ARM clientes más allá del ámbito de los ordenadores, como Texas Instruments , que más tarde conectó a la empresa con el emergente mercado móvil (culminando en el Nokia 6110) y las cajas decodificadoras. Los años siguientes verían la tecnología de ARM incorporada en miles de millones de dispositivos móviles .

La asociación con Nintendo

De vuelta en Japón, y gracias al análisis de Game Boy, aprendimos que la estrategia de hardware de Nintendo para sistemas portátiles favorece un modelo de System On a Chip (SoC). Esto ha permitido a la compañía camuflar tecnología de catálogo asequible y combinarla con desarrollos internos. Al hacerlo, la nueva consola podría ser única y competitiva. Afortunadamente, el modelo de licencias de ARM encajaba perfectamente con esas necesidades.

El chip CPU AGB, que integra la CPU ARM7TDMI (entre otros muchos componentes).

Ambas empresas mantuvieron conversaciones desde 1994 (un año antes del lanzamiento del Virtual Boy), probablemente en el marco del 'Proyecto Atlantis', durante el cual Nintendo estudió la ARM710 . Sin embargo, nada se materializó hasta muchos años después , y la razón era simple: los japoneses consideraban prohibitiva la densidad de código de ARM y la necesidad de 32 cables de datos (algo que la CPU del Virtual Boy ya había logrado evitar). No obstante, el nuevo diseñador de CPU de ARM — Dave Jaggar — respondió rápidamente con el ARM7TDMI, un nuevo diseño centrado en maximizar el rendimiento bajo restricciones de energía y almacenamiento. Este fue un punto de inflexión para ARM, ya que este nuevo producto no solo complació a Nintendo, sino que también atrajo la atención de Texas Instruments, Nokia y otros competidores en el ámbito de la telefonía móvil.

No es de extrañar que, al comenzar Nintendo a trabajar en el sucesor del Game Boy Color, su elección recayera en el ARM7TDMI.

El ARM7TDMI

Veamos ahora qué tiene para ofrecer este chip.

Comandando la CPU

Para empezar, el ARM7TDMI implementa el set de instrucciones ARMv4, el sucesor del ARMv3. Esto implica:

• Un diseño basado en RISC: Como se explicó antes, las CPUs ARM han sido influenciadas por un artículo de la Universidad de California, Berkeley llamado 'The Case for the Reduced Instruction Set Computer' . Su investigación describe una serie de directrices para el diseño de procesadores escalables y defiende el uso de una arquitectura de carga-almacenamiento, un tamaño de instrucción fijo y un gran archivo de registros. Muchos de estos rasgos estaban ausentes en el concurrido mercado de CPUs de la época (es decir, Intel 8086, MOS 6502, Zilog Z80 y el Motorola 68000), pero influirían en el diseño de nuevas líneas de CPUs a lo largo de las décadas de los 80 y 90.
• Ejecución condicional: Una característica peculiar del ISA de ARM. Esencialmente, casi todas las instrucciones incorporan una condición que indica si deben ejecutarse. Por lo general, otras CPUs siguen el proceso de 'comparar y saltar' (también llamado 'bifurcación') para controlar qué instrucciones debe ejecutar la CPU. Por el contrario, los programadores de ARM pueden insertar la condición en la propia instrucción. Esto es posible porque los primeros cuatro bits de los opcodes de ARM están reservados para una condición (es decir, igual, no igual, etc.). En resumen, esto reduce la complejidad del código ARM, ya que la ejecución condicional proporciona un diseño más limpio para las rutinas, a diferencia de las bifurcaciones y la división de subrutinas. Además, sirve como solución a los peligros de control (explicados en más detalle más adelante).
• Un segundo operando flexible, también conocido como 'Operand2' . Por lo general, las operaciones se componen de dos operandos (como suma 2 y 2). Sin embargo, las instrucciones de ARM también permiten incorporar una operación adicional de desplazamiento (shift) en el segundo operando. Por ejemplo, es posible calcular desplaza 2 cuatro bits y luego súmalo a 2 en una sola instrucción.
  • El desplazamiento de bits es también un recurso de bajo coste para realizar divisiones o multiplicaciones por potencias de 2, lo que abre la puerta a numerosas técnicas de optimización.
• Instrucciones de multiplicación de 32 bits y 64 bits: una novedad introducida en el ARMv4. Además, las operaciones de 64 bits almacenan el resultado en dos registros.

El paquete

Ahora que sabemos cómo los desarrolladores se comunican con este chip, vamos a ver qué hay dentro del silicio.

El núcleo

En términos de circuitería, el ARM7TDMI es una versión reducida del ARM710 con adiciones interesantes. El núcleo incluye :

• 16 registros de propósito general de 32 bits: Aunque es un gran avance en comparación con los siete registros de 8 bits del SM83/Game Boy, esto supone un compromiso con las directrices RISC, que estipulan treinta y dos registros de 32 bits. Esto se debe a que ARM prefirió mantener un tamaño de chip reducido .
• Bus de datos y ALU de 32 bits: significa que puede mover y operar valores de 32 bits sin consumir ciclos adicionales.
• Direccionamiento limpio de 32 bits: Esto es parte de la aportación de Apple. Las tres primeras CPUs ARM usaban direcciones de memoria de 26 bits para optimizar el rendimiento (el Contador de Programa y el Registro de Estado combinados podían caber en una sola palabra de 32 bits) a cambio de capacidad de direccionamiento de memoria (se podía acceder a hasta 64 MB de memoria). La serie ARM6 posterior (con su ISA ARMv3) implementó lógica de direccionamiento de 32 bits, pero mantuvo un modo de compatibilidad con versiones anteriores para el código heredado. Ahora, el ARM7TDMI (enfocado en la movilidad) desechó el modo de 26 bits y solo alberga lógica para direcciones de 32 bits (reduciendo la cantidad de silicio necesario).
• Sin Unidad de Gestión de Memoria (MMU): Desde el ARM1, ARM proporcionó una solución MMU. Primero como el coprocesador 'MEMC', y luego integrado con el ARM610. Ahora, el ARM7TDMI parece ser el único en su serie que no incorpora ninguna, posiblemente por falta de demanda (los primeros dispositivos móviles no requerían memoria virtual sofisticada).
• Sin caché: Otra medida de ahorro de costes en este chip, ya que los chips ARM anteriores incluían algo de caché.

Finalmente, todo esto puede operar con una fuente de alimentación de 3 voltios . Esto es un evidente paso hacia la computación móvil, ya que los núcleos anteriores requerían una fuente de 5 V.

El pipeline

Desde su primera iteración, ARM ha implementado una pipeline en tres etapas para ejecutar código. En otras palabras, la ejecución de las instrucciones se divide en tres pasos o etapas. La CPU captura, decodifica y ejecuta hasta tres instrucciones simultáneamente. Esto permite aprovechar al máximo los recursos de la CPU (lo que reduce el silicio inactivo) al mismo tiempo que aumenta el número de instrucciones ejecutadas por unidad de tiempo.

Al igual que dos contemporáneos muy similares, las CPUs ARM son susceptibles a peligros de datos. Sin embargo, ni el programador ni el compilador lo notarán ya que, en este caso, la CPU detendrá automáticamente la pipeline cada vez que sea necesario.

También están presentes los peligros de control, pero ARM los abordó con un enfoque eficiente llamado anulación condicional: Cada vez que una instrucción de rama está en la segunda etapa (Decode), la CPU calculará la condición de la rama . En función del resultado, si la rama debe ejecutarse, la CPU anulará automáticamente la instrucción posterior (convirtiéndola en un relleno). Ahora, esto puede parecer ineficiente en comparación con el enfoque de MIPS (ya que un compilador MIPS puede insertar instrucciones útiles, no solo rellenos). Por lo tanto, aparte de la bifurcación, ARM proporciona ejecución condicional. Esta última convierte este diseño de pipeline en una ventaja, ya que ARM puede decodificar una instrucción y calcular su condición incorporada en la misma etapa. Por lo tanto, en este caso, no se añadirán rellenos. De ahí que la ejecución condicional sea preferible a las bifurcaciones al programar para CPUs ARM .

Exprimir el rendimiento

Una de las desventajas de una arquitectura de carga-almacenamiento llevó a que el código de ARM fuera muy disperso. Competidores como x86 podían realizar las mismas tareas usando menores cantidades de código, requiriendo menos almacenamiento. En consecuencia, al examinar Nintendo el último diseño de ARM, el ARM7, este no les convenció. El tamaño de las instrucciones de ARM significaba que supuestos dispositivos con buses de 16 bits, memoria y almacenamiento limitados — todo para ahorrar costes y energía — harían que la CPU fuera ineficiente y crearían un cuello de botella. Por fortuna, Dave Jaggar acababa de terminar de diseñar el ARM7 y no estaba dispuesto a rendirse. Durante su camino de vuelta tras reunirse con Nintendo, se le ocurrió la solución: el set de instrucciones Thumb .

Thumb es un set de instrucciones independiente que funciona como modo alternativo dentro de la CPU. Está compuesto por un subconjunto del set de instrucciones ARM, con instrucciones codificadas en palabras de 16 bits (en lugar de 32 bits) . Al ser de 16 bits, las instrucciones Thumb requieren la mitad del ancho de bus y ocupan la mitad de la memoria. Para conseguirlo, introduce las siguientes concesiones:

• Thumb no ofrece ejecución condicional, dependiendo en su lugar de las bifurcaciones.
• Sus códigos de operación de procesamiento de datos usan un formato de dos direcciones (p. ej., suma R1 a R3), en lugar de uno de tres direcciones (p. ej., suma R1 y R2 y almacena el resultado en R3).
• Solo tiene acceso a la mitad inferior del archivo de registros. Por lo tanto, solo hay disponibles ocho registros de propósito general.

En general, dado que las instrucciones Thumb solo ofrecen un subconjunto funcional de ARM, los desarrolladores pueden tener que escribir más instrucciones para conseguir el mismo efecto. En la práctica, Thumb utiliza el 70% del espacio del código ARM. Para memoria de 16 bits de ancho, Thumb ejecuta más rápido que ARM. Si es necesario, las instrucciones ARM y Thumb pueden mezclarse en el mismo programa (lo que se denomina interfuncionamiento) para que los desarrolladores puedan elegir cuándo y dónde utilizar cada modo.

Los extras

El ARM7TDMI es, en esencia, un núcleo compatible con ARMv3 con extras. El nombre (TDMI) hace referencia a estos extras:

• T -> Thumb: la inclusión del set de instrucciones Thumb.
• D -> Extensiones de depuración: proporcionan capacidades de depuración mediante la interfaz Joint Test Action Group (JTAG).
• M -> Multiplicador mejorado: los núcleos ARM anteriores necesitaban varios ciclos para calcular multiplicaciones completas de 32 bits, esta mejora los reduce a unos pocos.
• I -> EmbeddedICE Macrocell: habilita puntos de interrupción de hardware, puntos de vigilancia y permite detener el sistema mientras se depura código. Esto facilita el desarrollo de programas para esta CPU.

En conjunto, esto convierte al ARM7TDMI en una solución atractiva para dispositivos móviles e integrados.

Áreas de memoria

La inclusión de Thumb en particular tuvo una fuerte influencia en el diseño final de esta consola. Nintendo mezcló buses de 16 y 32 bits entre sus distintos módulos para reducir costes, al tiempo que proporcionaba a los programadores los recursos necesarios para optimizar su código.

Arquitectura de memoria del sistema.

La memoria utilizable de la Game Boy Advance se distribuye en las siguientes ubicaciones (ordenadas de más rápida a más lenta) :

• IWRAM (WRAM interna) -> 32 bits con 32 KB: útil para almacenar instrucciones ARM.
• VRAM (RAM de vídeo) -> 16 bits con 96 KB: aunque este bloque está dedicado a los datos gráficos (que se explican en la siguiente sección), también aparece en el mapa de memoria de la CPU. Por tanto, los programadores pueden almacenar otros datos aquí si la IWRAM no es suficiente.
• EWRAM (WRAM externa) -> 16 bits con 256 KB: un chip independiente junto a la CPU AGB. Es óptima para almacenar instrucciones exclusivas de Thumb y bloques de datos pequeños. Por otro lado, el acceso al chip puede ser hasta seis veces más lento que el de la IWRAM.
• Game PAK ROM -> 16 bits con tamaño variable: aquí se accede a la ROM del cartucho. Aunque es una de las fuentes más lentas, se refleja en el mapa de memoria para ofrecer distintas velocidades de acceso. Además, Nintendo instaló un búfer de precarga que sirve de interfaz con el cartucho para reducir los bloqueos y compensar la falta de caché en la CPU. Este componente almacena en caché de forma autónoma direcciones consecutivas cuando la CPU no accede al cartucho, y puede contener hasta ocho palabras de 16 bits.
  • En la práctica, sin embargo, la CPU rara vez deja que el búfer de precarga haga su trabajo, ya que por defecto sigue leyendo instrucciones del cartucho para mantener la ejecución . De ahí que IWRAM y EWRAM sean tan críticas.
• Game PAK RAM -> 8 bits con tamaño variable: es el área donde se accede a la RAM del cartucho (SRAM o flash).
  • Se trata estrictamente de un bus de 8 bits (la CPU verá 'basura' en los bits no utilizados).

En definitiva, aunque esta consola se comercializó como un sistema de 32 bits, la mayor parte de su memoria solo es accesible a través de un bus de 16 bits. Esto significa que los juegos usan principalmente el set de instrucciones Thumb para evitar consumir dos ciclos por lectura de instrucción. Solo en circunstancias muy excepcionales — por ejemplo, al usar instrucciones no disponibles en Thumb o al leer desde la IWRAM — sacan partido del set de instrucciones ARM.

Convirtiéndose en una Game Boy Color

Aparte de la inclusión de hardware GBC (como la CPU Sharp SM83, la BIOS original, los modos de audio y vídeo, y una ranura de cartucho compatible), hay dos funciones adicionales necesarias para que la retrocompatibilidad funcione.

Desde el punto de vista del hardware, la consola se basa en un interruptor eléctrico para detectar si hay un cartucho de Game Boy o Game Boy Color insertado . Un detector de forma en la ranura del cartucho identifica el tipo de cartucho y permite a la CPU ARM7 leer su estado y actuar en consecuencia. Además, la alimentación, junto con los buses del mando, el cartucho y la WRAM, se redirigen físicamente en función del estado de ese interruptor.

Desde el punto de vista del software, existe un registro especial de 16 bits llamado REG_DISPCNT que puede alterar muchas propiedades de la pantalla, pero uno de sus bits pone la consola en 'modo GBC' . Esto hace que el sistema ceda el control a la CPU SM83 y arranque la BIOS de GBC. Eso sí, activar el modo GBC en REG_DISPCNT solo funciona si el sistema está arrancando desde la BIOS de GBA, ya que esta comprueba el valor del contador de programa (el registro PC).

Un aspecto curioso documentado en la Gbdev Wiki y en GBATek es que todas las variantes de Game Boy Advance son técnicamente capaces de ejecutar código de Game Boy . Esto incluye a la Game Boy Micro, que carece de la ranura de cartucho heredada. La razón es que todas las variantes integran el mismo SoC y no necesitan estrictamente el detector de forma para entrar en modo GB. Además, manipulando otros registros, es posible eludir las rutinas de verificación de la GB. Sin embargo, a falta de un cartucho GB, el juego debe residir de algún modo en la VRAM (ya que la CPU leerá ceros hasta llegar a ella), y el mando queda inutilizable (pues el detector de forma debe conmutarse para redirigir el bus al SM83) .