De cara a realizar un proyecto de desarrollo para Game Boy Advance u otras consolas de forma más "profesional" recomiendo siempre acudir a DevkitPro. Este artículo debe leerse como una prueba de concepto y una forma de entender mejor cómo funcionan las interioridades de la Game Boy Advance ya que definiremos en detalle y desde cero la cabecera de la ROM, el linker script, el código de arranque, etc. El código que generemos será igual de válido que el generado por DevkitPro con la diferencia de que DevkitPro dispone de multitud de librerías y herramientas que facilitan el desarrollo y lo de nosotros es "masoquismo".
Prerrequisitos
El único prerrequisito será tener instalada la toolchain bare-metal para ARM (arm-none-eabi). La construcción de dicha toolchain a partir de las fuentes está descrita en esta entrada de este mismo blog.
Características técnicas de la Game Boy Advance
La Game Boy Advance fue una consola portátil muy exitosa que sacó Nintendo en 2001, sucesora y compatible hacia atrás con las Game Boy y Game Boy Color. Es la primera de su clase provista de un procesador de 32 bits (un ARM7TDMI, con repertorio de instrucciones ARMv4T e instrucciones de multiplicación y división entera implementadas en hardware). No me detendré aquí a enumerar todas las características técnicas de la Game Boy Advance, para ello es mejor dirigirse a sitios como GBATEK o blogs como el de Jamie Stewart. Hay muchos recursos en internet disponibles. Me centraré en lo que necesitamos para construir un programa, una ROM mínima que se pueda ejecutar en una Game Boy Advance y utilizando sólo una toolchain bare-metal, por lo que nos veremos obligados a escribir el linker script y el código de startup desde cero.
Formato de una ROM de GBA
La Gameboy Advance utiliza un formato de ROM parecido al formato de ROM de sus precedesoras:
Offset (hex) Longitud (dec) Descripción 0000 4 Código ARM de 32 bits que se ejecuta al arrancar el cartucho. 0004 156 156 bytes fijos que contienen en logo de Nintendo comprimido. Siempre son los mismos bytes. 00A0 12 Nombre del juego (ASCII). 00AC 4 Código del juego (ASCII). 00B0 2 Código del fabricante (ASCII). 00B2 1 Valor fijo (96h). 00B3 1 Código del dispositivo (00h). 00B4 1 Tipo de dispositivo (00h). 00B5 7 Reservado (todo a 00h). 00BC 1 Versión del software (lo que queramos aquí). 00BD 1 Checksum calculado a partir de los bytes A0 a BC (ambos inclusive). 00BE 2 Reservado (todo a 00h) 00C0 n Resto de la ROM (el código y los datos)
Para contextualizar este mapa (que es el mapa de memoria de un cartucho de Game Boy Advance), veamos el mapa de memoria de la consola en sí:
Inicio Fin Tamaño Descipción 00000000 00003FFF 16 Kbytes ROM BIOS 02000000 0203FFFF 256 Kbytes WRAM (lenta) 03000000 03007FFF 32 Kbytes WRAM (rápida) 04000000 040003FE Registros E/S 05000000 050003FF 1 Kbyte Paletas LCD 06000000 06017FFF 96 Kbytes VRAM LCD 07000000 070003FF 1 Kbyte Sprites LCD 08000000 09FFFFFF 32 Mbytes ROM/Flash cartucho 0A000000 0BFFFFFF 32 Mbytes ROM/Flash cartucho 0C000000 0DFFFFFF 32 Mbytes ROM/Flash cartucho 0E000000 0E00FFFF 64 Kbytes RAM cartucho
La RAM de cartucho es opcional (no todos los cartuchos la tienen), mientras que las tres zonas de ROM/Flash de cartucho se diferencian por la cantidad de estados de espera que necesitan para ser accedidas desde la CPU. La primera zona (0x08000000 a 0x09FFFFFF) es la más rápida y en la que se asume que se encuentra el cartucho en sí, las otras dos zonas suelen ser utilizadas como memorias flash para almacenar datos no volátiles (partidas guardadas, por ejemplo), aunque algunos fabricantes de cartuchos optan por utilizar los 64 Kbytes de RAM de cartucho y utilizar una NVRAM en su lugar (mantenida con una pila o cualquier otra tecnología no volátil).
Teniendo en cuenta este mapa de memoria de la consola, las ROM de Game Boy Advance no empiezan en 0, sino en 0x08000000 (hay que sumar 0x08000000 a los offsets de la primera tabla).
El proceso de arranque
En el proceso de arranque, la consola comprueba la cabecera del cartucho insertado (accediendo a 0x08000000) y, si la cabecera es válida (logo de Nintendo y checksum), la consola hace un salto incondicional a la dirección de memoria 0x08000000. Como en esa posición de memoria sólo disponemos de 4 bytes, ya que en el offset 0x08000004 del cartucho está el logo de Nintendo y el resto de la cabecera, lo que se suele colocar aquí es una instrucción de salto a una dirección de memoria que esté más allá de la cabecera. En nuestro caso, por comodidad, hacemos un salto siempre a 0x08000100:
instrucción: "b 0x08000100" $\rightarrow$ opcode: 0xEA00003E $\rightarrow$ bytes en little endian: 0x3E, 0x00, 0x00, 0xEA
El byte de checksum se calcula realizando el siguiente cálculo con los bytes situados entre los offsets 0x080000A0 y 0x080000BC (ambos inclusive):
int32_t chk = 0; for (int n = 0xA0; n <= 0xBC; n++) chk = chk - headerData[n]; chk = (chk - 0x19) & 0xFF;
Para el resto de detalles de la cabecera del cartucho es mejor consultar la sección correspondiente en GBATEK. En nuestro caso, que hemos titulado a nuestro juego "EJEMPLO" y le hemos puesto el código de juego "AEJS" y el código de desarrollador "01", nos salen los siguientes datos de cabecera.
const uint8_t CARTRIDGE_HEADER[256] = { 0x3E, 0x00, 0x00, 0xEA, // branch to +0x100 0b 11101010 00000000 00000000 00111110 --> 0xEA 0x00 0x00 0x3E 0x24, 0xff, 0xae, 0x51, 0x69, 0x9a, 0xa2, 0x21, 0x3d, 0x84, 0x82, 0x0a, // nintendo logo 0x84, 0xe4, 0x09, 0xad, 0x11, 0x24, 0x8b, 0x98, 0xc0, 0x81, 0x7f, 0x21, 0xa3, 0x52, 0xbe, 0x19, 0x93, 0x09, 0xce, 0x20, 0x10, 0x46, 0x4a, 0x4a, 0xf8, 0x27, 0x31, 0xec, 0x58, 0xc7, 0xe8, 0x33, 0x82, 0xe3, 0xce, 0xbf, 0x85, 0xf4, 0xdf, 0x94, 0xce, 0x4b, 0x09, 0xc1, 0x94, 0x56, 0x8a, 0xc0, 0x13, 0x72, 0xa7, 0xfc, 0x9f, 0x84, 0x4d, 0x73, 0xa3, 0xca, 0x9a, 0x61, 0x58, 0x97, 0xa3, 0x27, 0xfc, 0x03, 0x98, 0x76, 0x23, 0x1d, 0xc7, 0x61, 0x03, 0x04, 0xae, 0x56, 0xbf, 0x38, 0x84, 0x00, 0x40, 0xa7, 0x0e, 0xfd, 0xff, 0x52, 0xfe, 0x03, 0x6f, 0x95, 0x30, 0xf1, 0x97, 0xfb, 0xc0, 0x85, 0x60, 0xd6, 0x80, 0x25, 0xa9, 0x63, 0xbe, 0x03, 0x01, 0x4e, 0x38, 0xe2, 0xf9, 0xa2, 0x34, 0xff, 0xbb, 0x3e, 0x03, 0x44, 0x78, 0x00, 0x90, 0xcb, 0x88, 0x11, 0x3a, 0x94, 0x65, 0xc0, 0x7c, 0x63, 0x87, 0xf0, 0x3c, 0xaf, 0xd6, 0x25, 0xe4, 0x8b, 0x38, 0x0a, 0xac, 0x72, 0x21, 0xd4, 0xf8, 0x07, 'E', 'J', 'E', 'M', 'P', 'L', 'O', 0x00, 0x00, 0x00, 0x00, 0x00, // game title 'A', 'E', 'J', 'S', // game code 'A' + two characters + 'S' (for spanish) '0', '1', // maker code 0x96, // fixed value 0x00, // GBA 0x00, // device type 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // reserved 0x00, // software version 0xC1, // complement check 0x00, 0x00 // reserved };
Linker script y código de arranque
El linker script es el script de "ld" (la herramienta de enlazado de GCC) que utilizaremos para decidir cómo se distribuyen el código y los datos en el espacio de memoria del cartucho:
SECTIONS {
. = 0x08000000 ;
.cartridge_header : {
startup.o (.cartridge_header)
}
. = 0x08000100 ;
.text : {
_linker_code = . ;
startup.o (.startup)
*(.text)
*(.text.*)
*(.rodata*)
*(.gnu.linkonce.t*)
*(.gnu.linkonce.r*)
}
.preinit_array : {
__preinit_array_start = . ;
*(.preinit_array)
__preinit_array_end = . ;
}
.init_array : {
__init_array_start = . ;
*(.init_array)
__init_array_end = . ;
}
.fini_array : {
__fini_array_start = . ;
*(.fini_array)
__fini_array_end = . ;
}
.ctors : {
__CTOR_LIST__ = . ;
LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
*(.ctors)
LONG(0)
__CTOR_END__ = . ;
}
.dtors : {
__DTOR_LIST__ = . ;
LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
*(.dtors)
LONG(0)
__DTOR_END__ = . ;
}
flash_sdata = . ;
. = 0x03000000 ;
ram_sdata = . ;
.data : AT (flash_sdata) {
_linker_data = . ;
*(.data)
*(.data.*)
*(.gnu.linkonce.d*)
}
ram_edata = . ;
data_size = ram_edata - ram_sdata;
ram_sbssdata = . ;
.bss : AT (LOADADDR(.data) + SIZEOF(.data)) {
_linker_bss = . ;
*(.bss)
*(.bss.*)
*(.gnu.linkonce.b.*)
*(.COMMON)
}
ram_ebssdata = . ;
bssdata_size = ram_ebssdata - ram_sbssdata;
_linker_end = . ;
end = . ;
}
Como se puede apreciar, al principio (zona marcada de verde) se fija el offset en 0x08000000 y, a partir de ese punto, lo primero que se hace es insertar una sección que hemos llamado ".cartridge_header" (el nombre es arbitrario) y que el linker script buscará en "startup.o", a continuación se fija el offset en 0x08000100 y a partir de ahí se coloca todo el código compilado, teniendo cuidado de que lo primero que se coloca a partir de 0x08000100 es la sección que hemos llamado ".startup" (el nombre también es arbitrario) y a continuación el resto del código (secciones ".text", ".rodata", etc. Estos nombres no son arbitrarios, son estándar de GCC).
Nótese que después de colocar todo el código, el linker script fija el offset en 0x03000000 (como se vio antes, esta sería la zona WRAM rápida de 32 Kbytes, zona marcada de rojo) para definir ahí las variables globales, tanto las inicializadas (".bss") como las sin inicializar (".data"). Mediante la palabra reservada "AT" le decimos al linker script que los datos "estarán" (futuro) en la WRAM (0x03000000) pero físicamente se encuentran ("por ahora") en "flash_sdata" (después del código). Esta "rareza" se explica porque los valores con los que se inicializa la RAM están en la ROM del cartucho y, antes de invocar a la función "main" tenemos que copiar dichos datos de la ROM a la RAM.
El código de arranque lo tenemos definido en "startup.cc". En este fichero tenemos definido un array constante de 256 bytes al que le asociamos la sección ".cartridge_header" (para que el linker script meta esos 256 bytes al principio de la ROM del cartucho, dirección 0x08000000) y también varias funciones que son las que realizarán todo el proceso de arranque.
__attribute__((section(".cartridge_header"))) const uint8_t CARTRIDGE_HEADER[256] = { 0x3E, 0x00, 0x00, 0xEA, // branch to +0x100 0b 11101010 00000000 00000000 00111110 --> 0xEA 0x00 0x00 0x3E 0x24, 0xff, 0xae, 0x51, 0x69, 0x9a, 0xa2, 0x21, 0x3d, 0x84, 0x82, 0x0a, // nintendo logo 0x84, 0xe4, 0x09, 0xad, 0x11, 0x24, 0x8b, 0x98, 0xc0, 0x81, 0x7f, 0x21, 0xa3, 0x52, 0xbe, 0x19, 0x93, 0x09, 0xce, 0x20, 0x10, 0x46, 0x4a, 0x4a, 0xf8, 0x27, 0x31, 0xec, 0x58, 0xc7, 0xe8, 0x33, 0x82, 0xe3, 0xce, 0xbf, 0x85, 0xf4, 0xdf, 0x94, 0xce, 0x4b, 0x09, 0xc1, 0x94, 0x56, 0x8a, 0xc0, 0x13, 0x72, 0xa7, 0xfc, 0x9f, 0x84, 0x4d, 0x73, 0xa3, 0xca, 0x9a, 0x61, 0x58, 0x97, 0xa3, 0x27, 0xfc, 0x03, 0x98, 0x76, 0x23, 0x1d, 0xc7, 0x61, 0x03, 0x04, 0xae, 0x56, 0xbf, 0x38, 0x84, 0x00, ... };
Código ARM y código THUMB
El procesador ARM7TDMI de la Game Boy Advance, al igual que otros procesadores ARMv4 y superiores, tiene dos repertorios de instrucciones:
1.- Un repertorio de instrucciones de 32 bits, con datos de 32 bits (modo ARM).
2.- Otro repertorio de instrucciones de 16 bits, con datos de 32 bits (modo THUMB).
El modo THUMB es igual de potente que el modo ARM, con el inconveniente de que las instrucciones no son igual de ortogonales y que para realizar la funcionalidad de algunas instrucciones ARM son necesarias varias instrucciones THUMB, pero con la ventaja de una mayor velocidad de ejecución y una mayor densidad de código. En el caso de la Game Boy Advance, el ARM7TDMI puede ejecutar código en ambos modos e incluso se puede pasar de modo ARM a modo THUMB y viceversa en cualquier momento de la ejecución de un programa.
A nivel hardware la Game Boy Advance posee un bus de 16 bits de anchura para la ROM del cartucho por lo que la opción recomendable para ejecutar el grueso del código es usar modo THUMB (el modo ARM funciona sin problemas sobre el espacio de direcciones de la ROM del cartucho, pero obliga al procesador a realizar dos lecturas de la ROM por cada instrucción y eso se nota en el rendimiento y el consumo). Por tanto el "coste" de tener un repertorio de instrucciones "recortado" (THUMB) se compensa por la velocidad de ejecución y por el menor consumo de energía.
El compilador GCC permite definir mediante opciones ("-marm" y "-mthumb") el tipo de código que generará por defecto y, de forma adicional, para introducir excepciones, es posible especificar que determinadas funciones sean compiladas en modo "arm" o en modo "thumb".
Teniendo en cuenta lo dicho y que los cartuchos ROM son arrancados siempre en modo ARM (la instrucción alojada al principio del cartucho, en 0x08000000, se lee en modo ARM, es una instrucción de 32 bits), lo que haremos será lo siguiente:
1.- Se compila por defecto todo el código del proyecto en modo THUMB (opción "-mthumb" del compilador).
2.- En el fichero "startup.cc", la función "_startup()" (que está en la sección ".startup" y, por tanto, su código se aloja justo a partir de 0x08000100, como se vio en el linker script), se marca como de tipo "arm", para que el compilador genere dicho código en modo "arm" (instrucciones de 32 bits) y, dentro de esta función, sólo hacemos un salto a la función "_startup_thumb()".
3.- En el mismo fichero "startup.cc" la función "_startup_thumb()", al no tener ningún atributo especial, se compila en modo THUMB (debido a la opción "-mthumb" que le pasamos al compilador) y el compilador genera, además, el código necesario para pasar de modo ARM a modo THUMB (por la llamada desde "_startup()" que está en modo ARM a "_startup_thumb()" que está en modo THUMB y gracias a la opción "-mthumb-interwork" que también se le pasa al compilador).
4.- Es la función "_startup_thumb()" (que ya se ejecuta en modo THUMB) la que realiza la inicialización de todo y la encargada de invocar la función "main()".
void _startup() __attribute__((section(".startup"), naked, target("arm"))); void _thumb_startup(); void _startup() { _thumb_startup(); } void _thumb_startup() { _initDataRAM(); _initBssRAM(); _callConstructors(); _callInitArray(); main(); _callFiniArray(); _callDestructors(); while (true) ; }
De esta forma ya todo el código que generemos en nuestro proyecto estará en modo THUMB (aunque nada nos impide escribir funciones que se compilen en código ARM añadiendo el atributo "target("arm")" a las mismas).
Compilar y generar la ROM
Ahora que tenemos nuestro código de arranque y el linker script, podemos compilar y enlazar todo nuestro código con la toolchain bare-metal de GCC:
# con esta línea compilamos "startup.cc", el código de arranque RUTA_BARE_METAL_ARM/bin/arm-none-eabi-g++ -std=c++11 -march=armv4t -mcpu=arm7tdmi -mtune=arm7tdmi -fno-exceptions -fno-rtti -nostartfiles -mthumb -mthumb-interwork -o startup.o startup.cc # con esta línea compilamos el resto de ficheros fuente que necesitemos RUTA_BARE_METAL_ARM/bin/arm-none-eabi-g++ -std=c++11 -march=armv4t -mcpu=arm7tdmi -mtune=arm7tdmi -fno-exceptions -fno-rtti -nostartfiles -mthumb -mthumb-interwork -o main.o main.cc # enlazamos (generamos un fichero .elf) indicando al enlazador # que use nuestro script de enlazado personalizado "gba.ld" RUTA_BARE_METAL_ARM/bin/arm-none-eabi-g++ -std=c++11 -march=armv4t -mcpu=arm7tdmi -mtune=arm7tdmi -fno-exceptions -fno-rtti -nostartfiles -mthumb -mthumb-interwork -Wl,-Tgba.ld -o main.elf startup.o main.o # generamos el binario (.gba) a partir del .elf RUTA_BARE_METAL_ARM/bin/arm-none-eabi-objcopy -O binary main.elf main.gba
El binario generado ("main.gba") es una imagen válida de un cartucho de Game Boy Advance, por lo que puede ser ejecutada tanto en un simulador de Game Boy Advance como en una Game Boy Advance real (mediante un cartucho flash o similar).
Primera prueba de concepto
Con el linker script anterior más el código de arranque que hemos definido ya podemos hacer una primera prueba de concepto.
#include <stdint.h> #include "Ana.H" // .H con datos generados a partir de una imagen de 240x160 (RGB555) using namespace std; using namespace avelino; #define DISPCNT *((volatile uint16_t *) 0x04000000) #define MODE3_VRAM_FB ((uint16_t *) 0x06000000) void memcpy16(uint16_t *dest, const uint16_t *source, uint32_t size) { uint16_t *s = (uint16_t *) source; while (size > 0) { *dest = *s; s++; dest++; size--; } } int main() { // force blank to access VRAM DISPCNT = ((uint16_t) 1) << 7; // draw on framebuffer memcpy16(MODE3_VRAM_FB, ANA, 240 * 160); // enable mode 3 with background layer 2 DISPCNT = ((uint16_t) 3) | (((uint16_t) 1) << 10); while (true) ; }
En este código lo único que hacemos es deshabilitar el LCD (para facilitar el acceso a la VRAM), copiar una imagen predefinida al framebuffer del LCD, habilitar el LCD en el modo gráfico 3 (que permite poner imágenes de color RGB555 (15 bits) en un frame buffer) y quedarnos en un blucle infinito a modo de "parada". En GBATEK puede verse cómo funcionan los diferentes modo gráficos de la Game Boy Advance.
Gestión interrupciones
El manejo de interrupciones es clave para sacar el máximo partido a cualquier plataforma embebida y en el caso de la Game Boy Advance, es importante tenerlas controladas tanto de cara a la gestión adecuada del controlador de LCD como de cara a minimizar el consumo de energía (recordemos que se trata de una consola portátil alimentada a baterías).
Para la gestión de interrupciones hay que tener en cuenta varias cosas:
- El registro IME (Interrupt Master Enable) permite habilitar y deshabilitar las interrupciones de forma global.
- El registro IE (Interrupt Enable) permite habilitar determinadas interrupciones de forma específica.
- Cuando de produce una interrupción se ejecuta un código específico de la BIOS de la Game Boy Advance que, a su vez, hace una llamada en modo ARM (no THUMB) a la dirección almacenada en 0x03007FFC (parte alta de la WRAM). Por tanto en esta posición de memoria escribiremos el puntero a nuestra rutina de interrupción, que deberá estar compilada en modo ARM (no THUMB).
- Una vez dentro de la interrupción hay que leer el registro IF (Interrupt Request Flags) para saber el origen de cada interrupción y escribir en él al final para marcar la interrupción como "servida".
Consideremos la interrupción que probablemente más vamos a necesitar: la interrupción V-Blank. Mediante interrupción sabremos cuando la CPU puede acceder de forma rápida a los registros de control de la pantalla y a la VRAM, de tal manera que no se produzcan "glitches" en la visualización de la imagen y podremos "prepararlo" todo para el siguiente frame (la Game Boy Advance pinta 60 imágenes por segundo, se producen 60 interrupciones de V-Blank por segundo).
Para configurar y usar la interrupción V-Blank podremos escribir el siguiente código:
typedef void (*fptr)(void); #define ISR_PTR *((fptr *) 0x03007FFC) #define IME *((volatile uint32_t *) 0x04000208) #define IE *((volatile uint16_t *) 0x04000200) #define IF *((volatile uint16_t *) 0x04000202) #define IFBIOS *((volatile uint16_t *) 0x03007FF8) void isr() __attribute__((target("arm"))); void isr() { // // ... // // mark v-blank interrupt as served IF = 1; IFBIOS |= 1; } void enableInterrupts() { IME = 0; ISR_PTR = isr; DISPSTAT = ((uint16_t) 1) << 3; IE = 1; // enable v-blank IME = 1; } int main() { enableInterrupts(); // // ... // while (true) { asm volatile ("swi 0x05"); // wait for v-blank } }
La función "isr()" la tendríamos definida como de tipo ARM (no THUMB) y, nada más empezar la función "main()", invocaríamos a la función "enableInterrupts()" que se encargaría de configurar las interrupciones y de escribir la dirección de memoria de la función "isr()" en 0x03007FFC. Una vez tenemos habilitadas las interrupciones, en el bucle infinito de espera incovamos una rutina de la BIOS de la Game Boy Advance ("swi 0x05") que pone a la CPU en modo de bajo consumo hasta que se produce una interrupción, con lo que conseguimos una ejecución más eficiente (gastamos menos batería). Para más detalles sobre el funcionamiento de las interrupciones u otras fuentes de interrupción, ver el apartado correspondiente en GBATEK.
Nótese que se produce una especie de contradicción en el manejo de interrupciones ya que, si bien dijimos antes que la forma más rápida y eficiente de ejecutar código en la Game Boy Advance, es en modo THUMB, ahora resulta que el código de interrupción se invoca en modo ARM. En una interrupción es cuando mas "prisa" tengo, ya que necesito despacharla rápido antes de que llegue la siguiente. Esta contradicción se suele resolver de varias formas:
A.- Dejando que el código de interrupción sea ARM, asegurarnos de que hacemos pocas cosas en la rutina de interrupción "isr()" y dejar el grueso de operaciones que debemos hacer entre cada V-Blank para justo después de la instrucción asm volatile ("swi 0x05"). Esta es la forma más sencilla de ejecutar código THUMB entre retrazos verticales, ya que el código que se ejecuta es THUMB (estaría en la función "main()").
B.- No podemos hacer que la función "isr()" sea THUMB pero, como compilamos con el flag "-mthumb-interwork" sí que podemos llamar desde "isr()" a otra función que sí sea THUMB (el compilador genera un pequeño overhead de 2 o 3 instrucciones adicionales) y de esta forma manejamos la interrupción mediante código THUMB.
C.- La forma más avanzada: ejecutar la función "isr()" en WRAM. En "startup.cc", antes de invocar "main()", se copia el código de la función "isr()" (que habremos compilado en modo ARM) al principio de la WRAM y las variables globales se ponen después. El puntero a "isr()" que se usa no es el del código de "isr()" que está en la ROM del cartucho, sino el puntero al código copiado a WRAM que, aunque se ejecuta en modo ARM, va mucho más rápido, puesto que la WRAM está dentro del procesador. El mayor inconveniente de esta técnica es que, si ya de por sí tenemos sólo 32 Kbytes de WRAM, podemos mermar aún mas dicha memoria (necesaria para variables globales y para la pila) si no hacemos una función "isr()" pequeña. Por otro lado tenemos la ventaja de que es la forma más rápida de ejecutar código ARM.
Para nuestra siguiente prueba de concepto optamos por el mecanismo más sencillo: dejar que la función "isr()" sea de tipo ARM y "dejarla" en la ROM del cartucho (no copiarla a WRAM), ya que no vamos a ejecutar muchas instrucciones en ella y así se mantiene el código más fácil de entender.
Segunda prueba de concepto
Partiendo de la primera prueba de concepto, vamos a mover un sprite por la pantalla, actualizando su posición sólo durante el retrazo vertical (V-Blank). Para utilizar el motor de sprites por hardware de la Game Boy Advance debemos acceder a las zona de memoria OAM (Object Attribute Memory), la paleta y una parte de la VRAM, según indica el apartado correspondiente en la documentación GBATEK.
int main() { enableInterrupts(); // force blank to access VRAM DISPCNT = ((uint16_t) 1) << 7; // draw on framebuffer memcpy16(MODE3_VRAM_FB, ANA, 240 * 160); // configure OBJ 256 color palette (all colors white) OBJ_PALETTE[0] = 0; // transparent (color don't care) OBJ_PALETTE[1] = 0; // black OBJ_PALETTE[2] = 0x7FFF; // white // OBJ tile 0 memcpy16((uint16_t *) OBJ_TILES_VRAM, BALL_TILE, 32); // MUST copy 16 bit words // configure OBJ 0 ballX = 120 - 4; ballY = 80 - 4; // (y, no rotation/scaling, enabled, no mosaic, 256 colors with 1 palette, shape = square) OAM[0] = (ballY & 0x00FF) | ((uint16_t) 1) << 13; // (x, no horizontal flip, no vertical flip, size = 8x8) OAM[1] = (ballX & 0x01FF); // (tile number = 512 (first obj tile with mode 3), priority = 0) OAM[2] = 512; // enable mode 3 with background layer 2, enable obj, enable obj 1-d mapping DISPCNT = ((uint16_t) 3) | (((uint16_t) 1) << 10) | (((uint16_t) 1) << 12) | (((uint16_t) 1) << 6); ballDX = 1; ballDY = 1; while (true) { asm volatile ("swi 0x05"); // wait for v-blank } }
Asignamos una paleta muy sencilla en la posición de memoria OBJ_PALETTE (color 0 transparente, color 1 negro y color 2 blanco), inicializamos una baldosa de 8x8 con el dibujo de una pequeña pelota en la posición de memoria OBJ_TILES_VRAM (baldosa 0) e inicializamos los atributos del sprite 0 (posición de memoria OAM) para que el sprite empiece en el centro de la pantalla.
Definimos 4 variables globales para la posición y la velocidad del sprite en X y en Y e implementamos una sencilla mecánica de movimiento y detección de colisiones en la rutina de interrupción ("isr()").
int32_t ballX, ballY, ballDX, ballDY; void isr() __attribute__((target("arm"))); void isr() { // calculate next location ballX += ballDX; ballY += ballDY; // check collisions if (ballX < 0) { ballX = 0; ballDX = 1; } else if (ballX > (240 - 8)) { ballX = 240 - 8; ballDX = -1; } if (ballY < 0) { ballY = 0; ballDY = 1; } else if (ballY > (160 - 8)) { ballY = 160 - 8; ballDY = -1; } // locate sprite OAM[0] = (ballY & 0x00FF) | ((uint16_t) 1) << 13; OAM[1] = (ballX & 0x01FF); // mark interrupt as served IF = 1; IFBIOS |= 1; }
Ahora tenemos a nuestro sprite "pelotita" danzando por la pantalla. Todo el código está disponible en la sección soft.
[ añadir comentario ] ( 939 visualizaciones ) | [ 0 trackbacks ] | enlace permanente
Tweet | |
( 3 / 768 )
Calendario
