fxGBA : émulateur GBA pour G90
Posté le 16/07/2023 16:06
Ce projet est encore expérimental !
DISCLAIMER :
Ce projet a utilisé de l'IA dans son développement récent. Pas uniquement de l'IA, je l'ai utilisé dans la rédaction des commits, des jeux de tests, ou du bug tracking, ainsi que pour m'aider à trouver réponse à mes questions.
Si cela invalide le projet pour vous, c'est complètement valide. Du reste, il m'était complètement sorti de la tête de mentionner la part de l'IA dans le projet et cela mérite de sincères excuses.
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
14/05/2026 : Fix de crashes à la lecture de la ROM, ainsi que deux autres qui arrivaient rarement.
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.
Citer : Posté le 14/05/2026 17:59 | #
Mis à jour l'add-in, j'ai pu réparer plusieurs crash (certains étaient rares, d'autres arrivaient plus souvent lors de la lecture de la ROM). Il y a aussi quelques mineures optimisations, je suis en train de chercher du côté de faire du JIT GBA ARM/Thumb -> SH4A codegen natif.
Ce serait un gros rework, mais on expérimente
Citer : Posté le 12/07/2026 21:40 | #
Il y a l'émulateur Bloom, qui est un émulateur PS1 pour Dreamcast, qui "maintient" un fork de GNU Lightning avec un backend SH4 ici : https://github.com/pcercuei/gnu_lightning/tree/sh4
Note que c'est SH4 et non SH4AL, donc la codegen est à adapter, ne serais-ce que pour l'usage du FPU.
J'espère que ça t'aidera
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 13/07/2026 19:18 | #
FYI I vibe-coded this gpSP port with SH4 dynarec here: https://github.com/KaraRyougi/gpsp-sh4-jit
It runs 50 ~ 60 fps on quite a few games with Ptune4 preset 5.
I used Opus 4.8 / GPT-5.5 extensively, and also used Fable 5 / GPT-5.6 later.
Harness is very important - with a proper emulator (I built one based on https://github.com/Heath123/casio-emu, not released yet) you can have closed-loop testing.
Citer : Posté le 13/07/2026 22:17 | #
Il serait peut-être temps qu'on discute de ce qu'on veut comme politique du site pour le vibe code ? On pourrait ne rien faire mais pas mal de gens ont des sentiments forts.
Northern_sno m'indique en off que fxGBA est aussi vibe codé avec Claude, ce que Lightmare n'a mentionné juste nulle part :/
Citer : Posté le 13/07/2026 22:27 | #
Quand je regarde le log des commits, Claude n'est marqué comme co-auteur que sur des commits récents. Ces commits semblent exister depuis l'apparition du JIT. Je ne sais pas à partir de quel point un projet peut être considéré comme vibe codé. Par contre le port de Nothern_sno là il n'y a pas d’ambiguïté.
Citer : Posté le 13/07/2026 22:40 | #
Je dirais que le caractère vibe codé doit être clairement précisé.
C'est une question de respect non seulement envers les utilisateurs, mais aussi envers ceux qui se donnent la peine de rédiger des tests/reviews.
Citer : Posté le 13/07/2026 23:10 | #
btw Codex won't add itself as a co-author by default - i explicitly turned that on.
also, when I said I vibe-coded it - I mean 100% of the new code was generated by LLM and I didn't write a single line of code.
this is apparently different from the case for OP's project.
Citer : Posté le 16/07/2026 10:17 | #
J'ai rajouté un disclaimer en début de topic (que je rajouterai également au début de la page du programme juste après ce message).
J'ai bien utilisé Claude Code en assistant pour le développement récent du projet, pour la rédaction de commits, jeux de tests, bug tracking, et recherche d'infos.
Comme il était visible sur le github, il m'était sorti de l'esprit de mentionner son utilisation sur le topic ou la page du programme. Je donne ma parole que ce n'était pas par mauvaise intention et prendre crédit pour du code que je n'ai pas rédigé.
(le projet est déjà basé sur une codebase qui n'est pas la mienne).
Mais pour ce manquement, je m'excuse sincèrement. Je suis bien au courant de la lutte du site contre l'usage de l'IA et plus singulièrement sur les avis de la plupart de ses membres.