Un beau jour de printemps pas beau, j'eu envie d'essayer la GBA.
Je sais pas, une certaine nostalgie pour mon vieil Atari St ptet!
Ces notes ne peuvent pas servir de documentation a part entiere. Elles
sont plutot a voir comme un complement, une explication plus clair et
en francais (ou presk :-) des diverses tutoriaux ou documentations que
j'ai pu obtenir.
Donc voila un petit tuto, en francais, pour ceux qui debute!!
il faut absolument aller sur www.gbadev.org pour tout trouver: compilo,
emulateur, exemple! un bon debut c'est les tutoriaux de PERN. On apprends
beaucoup de chose sur le fonctionnement du gba. Grace au tutorial, on
installe tres facilement le compilo, les exemples, tout se compile tres
vite, un jeu d'enfant!
Pour le code et les données autres que graphique, on a tres peu de RAM:
128+32 ko.
256ko pour un code en RAM, mais un peu lent. 32ko, c'est pour de la RAM
rapide. A l'init, la gba execute son code de boot, puis donne la main
a la cartouche. il ne faut pas oublier de dire au linker d'utiliser des
DATA et BSS (data non initalisé) en RAM, pas en Rom, sinon plantage....
Le code peut parfaitement s'executer en ROM. mais pour profiter de la
RAM ou RAM rapide il faut recopier le code la ou il faut....et l'avoir
bien sur compilé/linké de facon correct (adressage absolu).
Et oui, on gere la memoire a la main! pas de malloc ici! Pareil, le code
(et donc le CPU) peut etre en deux modes:
THUMB, 16bits, moins puissant mais plus petit opcode, donc bon pour la
ROM qui est lente a lire.
Et le mode normal qui fait 32 bits.
On peut interlacer les deux types de code! A priori le 32b serait plus
destiné a la VRAM voire la RAM, et le thumb a la ROM, mais je n'ai pas
pu verifier.
Donc avec, on voit comment changer de mode par exemple... on compile
avec un .bat...il faudrait peut-etre changer ca par un makefile ! Mais
pour l'instant, ca marche. J'utilise VC comme environnement de dev, par
habitude, car il n'y a rien de specialpour GBA sous VC.
Voila donc comment configurer le compilo et l'EDI:
Note: J'utilise personellement que du C++.
armasm -CPU ARM7TDMI -Littleend start.asm
armasm -CPU ARM7TDMI -Littleend data.asm
armcpp -c -Wall -Otime -fpu none -Littleend -cpu ARM7TDMI -apcs /narrow/noswst
ex.cpp
(pour le C: armc -c -ansic -Wall -Otime -fpu none -Littleend -cpu ARM7TDMI
-apcs /narrow/noswst ex.c)
armlink -bin -first start.o start.o data.o ex.o -map -ro-base 0x08000000
-o ex.gba
compilation Aller dans Tool, puis customize, puis Tools!
Ajouter un tool qui pointe sur le make.bat Initial directory: la ou est
votre programme.
Cochez "Use Output Window"
Aller dans Tool, puis customize, puis Tools!
Ajouter un tool qui pointe sur votre emulateur favori Argument: la ou
est votre programme.
Un peu horrible mais pour l'instant ca marche. Il vous faut aussi des fichiers de boot que vous retrouverez dans les exemples (start.asm).
La RAM qu'occupe la video est dispatché en 3 unités:
La VRAM, ou RAM video: 96ko, Stocke l'ecran a afficher, ainsi que les
TILEs (definition: un TILE est un bloc graphique de 8*8 pixel)
OAM ou object: en plus clair, la position ou afficher les sprites. 1 ko!
les palettes:1 ko (deux palette de 256couleurs, 2 octets/couleurs=1ko)
On regles le mode voulu par le registre DISPCNT:
bg0-2: mode background, c'est a dire qu'on stocke dans l'ecran une adresse,qui
refere a un TILE (caractere 8*8, en 16 ou 256c). Une sacre difference
par exemple par rapport au PC ou ST...
bg4: un mode 256c qui ressemble au mode 13h PC
bg3,5: un mode 16b. XR5G5B5.
Je m'interesse plus specialement au mode 0,1 et 2. Les autres modes semblent
plus simple, car tres proche du PC...deux problemes arrivent rapidement:
il mange beaucoup de memoire, enormement, et la gba en a tres peu. 2eme
probleme, le hard aide tres peu par raport aux autres modes.
Les modes 0-2 sont des modes tiles...C'est-a-dire que d'un cote on a les
tiles, des blocs de données graphique 8*8, de 16 ou 256c. D'un autre,
ce qui est affiché, donc le numero de la tile. Soit une resolution de
256*256, on a ecran de (256/8)*(256/8)=1024 octets! Vraiment tres peu
de données a traité, deplacer, parfait pour un scroll (et encore, pas
besoin, le hard sait le faire!)...
En fait, c'est un peu plus compliqué: On a pas 1 octets/tile, mais 2 octets.
On peut par exemple faire des rotations par pas de 90 degres a chaque
tile! Cela permet une enorme economie dans les RPG par exemple! En plus,
on a pas un seul ecran qui affiche des tiles,mais jusqu'a 4! Chacun peux
etre activé ou pas, ce qui prends donc de la memoire ou pas, et il ne
font pas tous obligatoirement la meme taille.
On voit la un des problemes specifiques du developpement sur console:
l'organisation de la memoire. La palette est de 256 couleurs,pas une de
plus... La Vram utilise 96 koctets, et elle stocke les tiles (le tableau
affiché), et les blocs graphiques qui les representent.
Donc un background de + ou de - pese beaucoup!
Il est possible de dire ou commence un background (ecran utilisant des
TILES) par le registre BGxCNT (x=0..3) . Dans ce registre on peut regler
le "character base bloc" sur 2 bits et le "Screen base block" sur 5 bits.
Le "screen base block" est l'adresse de ce que j'ai appelé
le "background", soit le numero des TILEs a afficher. Il est precis a
2ko pres, donc une valeur de 5 signifie 5*2=10 ko APRES le debut de la
VRAM. Le "character base bloc" dit ou sont stocker les fameuses TILEs...precis
a 16 ko pres... 3=16*3=48. La aussi, il ne faut pas partir a l'aveuglette
et chercher de la place au hazard: Mieux faut faire un schéma de la VRAM
en debut de production.
Petite cerise sur le gateau: les sprites sont eux aussi dans la VRAM!
En fait, les 32 ko de fin de VRAM (dans les modes 0,1,2) sont reservé
aux données des sprites.
il y a deux palettes, celle des sprites,et celle de l'ecran a afficher. Ces deux palettes peuvent etre divisé en 16 palettes de 16 couleurs pour permetre des effets de couleurs rapide.
L'OAM est une zone de 1024 octets (1ko), decouper en cellule de 4 int16. On a donc 128 sprites au maximun. En fait, si il n'y a pas de rotation,on utilise que 3 int16, le dernier est innutile. On indique le x, le y du sprite, ainsi que different parametres (sprite en 16 couleur ou 256? flip ou non (un flip,c'est un effet mirroir)) ainsi que le numero du TILE sur 9 bits, a partir de VRAM laisser au tile (donc les derniers 32ko de la VRAM dans les modes tiles). On peut aussi indiquer la rotation,le scale etc... Voila ce 1er petit tour de la GBA, apres quelques jour de lecture de doc et de test divers.
main.zip, un petit exemple (deux sprites et un background, repompé sur le tutorial 3 de PERN)
Le portail de reference sur la programmation game boy advance, remis a jour quotidiennement! voir surtout http://www.agbdev.net/thepernproject/tutorial_1.html sur lequel je me suis enormement inspire.
Un autre tres bon site, plein de doc. Voir par exemple http://www.devrs.com/gba/files/dwcmp.txt, un tres bon comparatif des compilateur disponible sur GBA.
un doc sur les bidouilles faisables sur GBA.