DevKitArm (il faut sélectionner seulement GBA, pas PSP et GP32, parce que déjà que ça rajoute plein de fichiers inutiles alors avec ça en plus
).
En gros dans mon dossier j'ai un dossier "bin" qui contient entre autre "arm-none-eabi-gcc.exe" et "arm-none-eabi-objcopy.exe" (même si le tuto en
./41 spécifie "arm-elf-gcc.exe" et "arm-elf-objcopy.exe", je ne les ai pas et ça marche très bien sans (enfin si quelqu'un a une explication, ce serait sympa
)), un batch pour compiler qui contient :
cd bin
arm-none-eabi-gcc -mthumb-interwork -specs=gba.specs ..\test.s
arm-none-eabi-objcopy -O binary a.out ..\test.gba
@pause
(Là encore je ne sais pas à quoi correspond le paramètre "-specs", si c'est une référence à un fichier je ne l'ai pas trouvé, mais vu que ça ne bug pas...
)
Autrement j'ai aussi le programme
Bimbo pour convertir des images en binaire (seulement 240*160 ou 160*128 par contre
), et pour finir mon fichier source :
.arm @ on compile avec les instructions ARM
.text @ on place le programme en ROM (adresse de départ apparemment)
.global main @ début du programme (pour que les linkers s'y retrouvent)
main:
mov r0, #0x4000000 @ on met l'adresse REG_DISPCNT (driver LCD) dans le registre r0
mov r1, #0x400 @ contraintes de l'instruction mov :
@ de 0 à 256 : toutes valeurs possibles
@ de 256 à 1024 : multiples de 4
@ de 1024 à 4096 : multiples de 16
@ ici $403 = 1027, on ne peut pas, donc on prend $400 = 1024
add r1, r1, #3 @ la valeur 0x403 signifie le mode graphique 3 et le BG 2 (cf http://static.patater.com/gbaguy/gba/ch5.htm )
@ (on ne peut pas mettre directement 0x403 dans r1 en utilisant mov
@ car ce n'est pas une valeur 8bit, et utiliser un ldr, ldrh etc... est plus long)
strh r1, [r0] @ on se sert de l'instruction strh (et pas str) pour écrire en mémoire (à l'adresse du driver)
@ un demi-mot 32bits (soit 16bits = 2 octets) pour ne pas écraser autre chose
mov r0, #0x6000000 @ addresse de la mémoire vidéo (VRAM)
ldr r1, =pic @ on met l'adresse de notre image dans r1
mov r2, #0x960 @ le nombre d'octets nécessaires pour remplir l'écran (240*160/16)
loop1:
ldmia r1!, { r3,r4,r5,r6,r7,r8,r9,r10 } @ cette instruction charge plusieurs registres puis incrémente ensuite
@ (LoaD Multiple, Increment After), r1 contient l'adresse de base,
@ puis chaque registre recevera une valeur 32bits différente (l'adresse est
@ incrémentée de 4 à chaque itération),
@ la valeur finale est chargée dans r1 (à cause du !).
@ C'est un peu comme un :
@ ld hl,{ r3,r4,r5,r6,r7,r8,r9,r10 }
@ ld de,r1
@ ldir ; sauf que ça incrémente de 4, puis qu'on doit mettre la valeur finale dans r1
stmia r0!, { r3,r4,r5,r6,r7,r8,r9,r10 } @ on charge notre image dans la mémoire vidéo (même principe : chaque adresse des
@ registres reçoit la valeur de l'adresse contenu dans r0+4 à chaque itération)
@ Avec ces instructions il faut juste faire attention à ne pas utiliser le registre initial dans la liste des destinations !
subs r2, r2, #1 @ on decrémente le nombre de fois où on doit faire notre boucle
bne loop1 @ goto loop1 si nz
infin:
b infin @ boucle infinie
.ltorg @ ça j'ai pas trop compris (?)
pic:
.incbin "../test.bin" @ binaire de l'image obtenu avec BimboVoilà, y'a quelques trucs qui me dérange encore, mais sinon c'est compréhensible.
Pour la suite il faut que je vois comment gérer les sprites (s'il faut créer sa propre routine ça peut être sympa) et comment gérer le getkey ! Ensuite j'aurai de quoi faire une petite démo
La Revo k101 a l'aire assez sympa, je crois que programmer en assembleur pour la GBA serait intéressant (et avec le DS qui peut l'émuler on a une audience assez grande). D'ailleurs elle (la Revo) ne coûte presque rien ! Je crois que programmer pour ce genre de console serait très amusant : un console construit pour aider au programmeur et pas le restreindre !
)
), et pour finir mon fichier source :