fxGBA : émulateur GBA pour G90
Posté le 16/07/2023 16:06
Ce projet est encore expérimental !
Introduction :
Bonjour à tous ! Je propose aujourd'hui d'aborder à nouveau le sujet d'un émulateur GameBoy Advance pour la Graph 90.
Ce topic fait suite à une conversation qui a eu lieu dans les commentaires de
celui-ci, dans lequel on émettait la faisabilité d'un tel projet.
3 années plus tard j'ai donc pris de mon temps pour me pencher sur l'adaptation d'un émulateur existant :
gdkGBA, en raison de sa simplicité.
(Je préviens : l'émulateur nécessite l'utilisation du BIOS de la GBA pour fonctionner, et il va de soi que je ne partagerai pas la propriété intellectuelle de Nintendo ici)
Objectifs :
Faire un POC d'émulateur en privilégiant la stabilité à la vitesse.
En ce faisant, documenter les astuces, forces et contraintes afin de faciliter une éventuelle meilleure implémentation dans le futur.
Etat actuel :
16/07/2023 : J'ai réussi à compiler le projet en add-in et à le lancer, mais pour le moment il ne peut pas faire tourner de ROM.
9/05/2026 : L'émulateur fonctionne à des perfs réduites (3/4 fps, jusqu'à 8 avec un frameskip de 1), pas testé avec beaucoup de ROMs différentes
Comment je peux tester ?
Il y a un build en fichier joint, il manque le bios à rajouter (renommez le bien "gba_bios.bin")
Pour cela, compilez le projet avec fxSDK + Gint, puis mettez l'add-in avec le BIOS de la GBA nommé "gba_bios.bin" et une ROM en ".gba". N'importe quelle ROM devrait faire l'affaire.
LIENS UTILES
Cliquer pour enrouler
Images!
Cliquer pour enrouler
Citer : Posté le 16/07/2023 19:19 | #
Je pense avoir trouvé l'origine du problème lié au crash : l'émulateur essaie de charger la ROM du jeu entièrement dans une variable (qui est initialisée à 33Mo) ce qui dépasse complètement la RAM de la G90.
Je pense que le plus intuitif serait de lire la ROM par morceaux de taille inférieure à 60Ko (qui est le max, donc ce sera probablement bien moins que ca) et de charger dynamiquement les régions de la ROM dont l'émulateur a besoin, en déchargeant celles qui ne sont plus utilisées.
Citer : Posté le 16/07/2023 20:05 | #
Il y a 512ko de mémoire malloc() able sur G90. Il y a aussi 6mo (je crois) qui sont disponibles mais c'est pas totalement sûr de taper dedans
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 16/07/2023 20:08 | #
owo génial ! c'est le genre de trucs que j'adorerais faire depuis longtemps mais par manque de temps/par éparpillement ça n'a pas abouti. C'est génial !
Si je peux aider pour quoi que ce soit, bien que mes capacités soient probablement bien maigres, n'hésite pas !
Citer : Posté le 16/07/2023 22:38 | #
Oui on peut avoir grosso modo 3,5Mo de RAM mis a disposition sur la G90.
Il faut créer des arènes spécifiques. Attention par contre, c'est vrai sur la G90, mais pas sur les modèles anciens de Prizm (CG10/20) qui n'ont pas la même puce mémoire.
Pour le code, tu peux t'inspirer de ça : https://gitea.planet-casio.com/Slyvtt/Shmup/src/branch/master/src/main.cpp#L307-L387
Regarde le début du fichier pour les variables et les includes qui vont bien
Citer : Posté le 17/07/2023 10:31 | #
Il y a 512ko de mémoire malloc() able sur G90. Il y a aussi 6mo (je crois) qui sont disponibles mais c'est pas totalement sûr de taper dedans
Oui on peut avoir grosso modo 3,5Mo de RAM mis a disposition sur la G90.
Ooooh d'accord pas mal ! Ca élimine pas le problème de diviser la ROM, mais ca donne déjà plus de manoeuvre.
Je pense que j'irai voir ce qu'a fait Thomas Williamson pour Prizoop et Nesizm, car il a dû rencontrer le même problème.
Si je peux aider pour quoi que ce soit, bien que mes capacités soient probablement bien maigres, n'hésite pas !
Merci beaucoup de ta proposition ! Si jamais tu en as l'envie et le temps, le simple fait de bidouiller avec le code source et de voir comment l'erreur se comporte peut beaucoup apporter.
JePasseJuste Invité
Citer : Posté le 28/08/2023 23:08 | #
Bah nan ça règle pas vraiment le soucis de la taille de la ROM parce que les ROMs de jeux GBA font toutes au moins 8MO si ce n'est plus (16MO voir 32MO).
Citer : Posté le 29/08/2023 11:18 | #
Formidable ambition, j'ai bien de voir et annoncer des progrès significatifs. Courage et force à toi !
Citer : Posté le 09/05/2026 14:39 | # |
Fichier joint
Bonjour bonjour, j'arrive avec des nouvelles 2 ans et demi plus tard!
Le projet a bien avancé,
même si ca se voit pas encore sur le repo.j'ai push sur le repo!Je fais ici un résumé des progrès!
On a un émulateur qui marche! j'ai pu tester sur quelques ROMs de 4Mo, et ça tourne à 6-8 fps avec un frameskip activé (sans, plutôt 3-4 fps)!
Il s'est avéré très tôt que la raison du crash à la base n'était pas liée à la taille de la ROM à charger (c'était un problème parmi d'autres), mais c'était à cause d'une erreur dans la manière où la sortie vidéo était transmise à la VRAM (...Elle était pas transmise du tout). J'en ai profité pour retirer les derniers vestiges de SDL du projet.
Ensuite est venu le second problème rapidement identifié : la conversion de RGBA vers RGB565. Fallait le faire.
Après ca, il y a eu besoin de plonger plus à fond dans comment le projet original fonctionnait (il s'est avéré que faire un joli paquet autour d'un émulateur existant sans se soucier du reste ne marche pas vraiment), et ca m'a pris la tête donc grosse pause
...Puis mon prof de C m'a aidé, et m'a débloqué sur pas mal de points! Ses explications m'ont très vite fait comprendre que plusieurs points critiques du projet étaient au delà de mes capacités, donc j'ai dû bien compartimenter mon approche, et j'ai pas mal tâtonné dans le noir jusqu'à que ca marche.
En vrac les gros obstacles qu'il a fallu résoudre pour avoir le résultat actuel :
- changer la manière dont les chemins rapides appelaient la ROM
- changer la gestions des entrées ("keydown" au lieu de "getkey")
- ajout de diagnostics
- changer en "big endian" l'ordre des champs d'union
- obtenir davantage de RAM pour travailler : un GRAND MERCI à Slyvtt à qui j'ai emprunté extram avec dû crédit!
C'est un gros résumé.
Maintenant le vrai défi est de creuser à droite à gauche pour trouver des pistes d'optimisations, sachant que je connais très bien mes limites à ce sujet.
Je vais mettre à jour le post original!
Citer : Posté le 09/05/2026 15:44 | #
Est ce que tu as profilé ton code ? Ça peut déja pas mal aider
Pour ce qui est de changer d'endianess, ça peut être fait en quelques instructions d'asm
volatile asm (
"swap.b %0,%0\n"
"swap.w %0,%0\n"
"swap.b %0,%0\n"
: "=r" (x)
: "r" (x)
);
return x;
}
Un truc dans ce genre (non testé)
Pareil pour la conversion RGB555 -> RGB565, et pour les modes avec palette ça doit même être possible de précalculer ces transformations
En général tu devrais aussi pouvoir profiter pas mal d'Azur pour le rendu.
En tout cas c'est très cool que ça avance
Edit : J'avais oublié le return
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 09/05/2026 16:03 | # |
Fichier joint
Merci pour les suggestions !
L'endianess sera super utile plutôt que le faire à la main, et pour les couleurs normalement on est bien sortis d'affaire!
Je vais étudier la question d'Azur, à voir s'il y a de quoi gratter en performances/fonctionnalités de ce côté là!
(J'en profite pour montrer une image de Mario Kart!)
Citer : Posté le 09/05/2026 17:26 | #
Azur aidera pas trop, il vaudrait mieux recoder direct le bout de driver écran, comme dans DOOM.