Outils de dev MAC pour le neo geo en ASM
Posté : sam. 25 juil. 2026 15:21
Depuis la fin des années 90, la Neo Geo a toujours été ma machine de cœur.
J'en possède plusieurs et j'ai aussi une collection de jeux d'époque.
Il y a quelques années, j'ai décidé de réparer ces machines afin d'acquérir une solide expérience, pour passer à l'étape supérieure, avec un objectif clair depuis le début : le développement sur Neo Geo.
Ce rêve prend forme.
J'ai dû me remettre à l'assembleur — certains vont me traiter de fou, car il existe déjà des choses en C.
Dans ma jeunesse, je codais en ASM sur Amiga dans la scène demo française. J'étais loin d'être un tueur, mais j'adorais ce langage.
Étant sur Mac (je sais, c'est mal), j'ai décidé de me faire mon setup from scratch, depuis que la version en ligne de commande de MAME est disponible.
Les autres émulateurs Mac ne sont pas terribles, et le debugger de MAME est vraiment excellent.
Je suis parti sur la base de mon jeu de cœur, Art of Fighting.
Le but étant de pouvoir me servir de la PROM pour injecter mon code et recompiler tout l'aof.zip.
Mais très vite, si je voulais récupérer des infos graphiques déjà présentes dans le jeu, je devais pouvoir aller regarder du côté des sprites et du fix layer.
Il existe des outils basiques en ligne, et je voulais vérifier si une police de caractères était présente dans la cartouche.
J'avais trouvé ma police de caractères : elle commençait à la tile 30303, et dans le désordre, s'il vous plaît !
C'était la découverte parfaite pour s'essayer à un petit sine scroll avec ce texte, avec une palette définie à la main.
Uhhh, ça marche ! Ça scroll sur une table sinus à 256 entrées.
Prochain entraînement : l'affichage d'un sprite de personnage complet. Mais comment chercher dans les CROMs ? Tant qu'on y est, autant essayer de faire, en Python, mon propre éditeur de sprites, relié à ce setup de dev.
Python, ce n'est pas du bas niveau, mais pour faire de petits projets, c'est largement suffisant.
Mais c'est toujours pareil : et si on faisait ci, et si on faisait ça...
Du coup, l'idée me vient de pouvoir travailler sur un savestate de MAME, et d'essayer de reconstruire l'image sauvegardée dans le savestate à partir des informations qu'il contient (sprites, fix layer et palettes).
Du coup, j'ajoute une fonction qui ouvre une nouvelle fenêtre pour reconstruire l'affichage à partir d'un savestate pris en cours de jeu.
Mouais, on peut mieux faire : le fix layer est absent, les sprites des persos aussi.
Du coup, grâce au Neo Wiki et à ses fondateurs, on récupère beaucoup d'infos sur les palettes, les registres vidéo, la structure des sprites, et plein d'autres renseignements obscurs.
Les persos, c'était n'importe quoi : j'ai repéré un problème de byteswap qui me faisait chercher les sprites des persos à deux fois l'emplacement mémoire où ils se trouvaient réellement.
Après corrections, les persos sont là, et le fix, entre-temps, a été « fixé ».
Mais pas de décor quand l'image est en taille normale (j'entends : sans dézoomer).
Problème du bit de shrink, qui permet de gérer les « zooms » sur la machine : il manque toujours un morceau.
Ce petit logiciel est pratique, car il permet de récupérer les 256 palettes du jeu. Mais comment savoir quelle palette correspond à quelle image, et surtout à quel sprite ?
Les jambes sont manquantes.
Une erreur de paramétrage sur les sticky bits, qui permettent de coller les sprites ensemble, et les jambes reviennent.
J'ai aussi fixé la bande du haut sur le décor dézoomé, en allant chercher, dans l'éditeur de CROM, où commençaient les décors de cette bande.
Mais j'ai aussi changé de stratégie pour la récupération des données. Le savestate me posant trop de soucis, et grâce aux conseils du talentueux Aurélien, je me suis fait un script qui va directement sauvegarder le contenu de la VRAM quand je fais une pause dans MAME, et ça vient écrire le dump directement dans le dossier de mon setup de programmation.
J'essaye sur d'autres, dans différents stages, pour voir si la structure est bien recomposée. Et la réponse est : vvvooouuiiiii !
Alors, je me dis : est-ce que l'on pourrait ajouter des fonctions supplémentaires qui quadrilleraient la reconstruction, et qu'avec notre souris, en survolant une zone, nous aurions les infos sur l'adresse du sprite ou de l'élément du fix layer, ainsi que sa palette, avec la palette de 16 couleurs qui s'affiche à côté pour en avoir un aperçu ?
Fonction supplémentaire : en balayant avec deux doigts (Mac oblige), on déclenche un zoom/dézoom sur la zone qui nous intéresse, pour être sûr de bien sélectionner le bon sprite.
Bien sûr, on peut aussi extraire les palettes dans un fichier.
Il est 23h50... du matin. Ça fait une journée que je bosse dessus, ma femme ne me parle plus, mes enfants m'appellent tonton !!!!
Et une idée satanique d'Aurélien : griser les zones et ne laisser en couleur que la zone survolée.
Ça marche un peu, mais pas tout le temps.
Bref, à peaufiner, mais l'idée est très bonne (de toute façon, quand t'es proche du soleil, t'as que des bonnes idées).
J'ai mal à la tête, mes yeux me brûlent.
Mais maintenant, grâce à tout ça, c'est beaucoup plus facile de chercher des sprites dans la CROM : tu connais la palette exacte utilisée, il te suffit d'indiquer la palette que tu veux, et les sprites deviennent facilement reconnaissables.
On peut charger toutes les palettes directement depuis le dump.
On peut aussi lancer le jeu avec le système de trace et de sauvegarde de dump depuis l'application.
Et au final, l'identification m'a permis de faire mon sine scroll text depuis mon setup de dev, avec MAME, VS Code et VASM pour la compilation.
Je bosse sur des raster bars (vive les interruptions), des starfields avec des sprites d'AOF, l'affichage de personnages, et plein d'autres trucs.
Le but est de sortir une demo à l'ancienne l'année prochaine, et peut-être, pourquoi pas, un jeu... On m'a déjà proposé, mais je n'étais pas prêt.
Pourquoi faire ça en 2026, alors que la console a plus de 30 ans ??? Et pourquoi pas ? Il y en a bien qui font une réédition de la console avec un nouveau hardware, 30 ans après, et apparemment les gens sont super hypés.
J'en possède plusieurs et j'ai aussi une collection de jeux d'époque.
Il y a quelques années, j'ai décidé de réparer ces machines afin d'acquérir une solide expérience, pour passer à l'étape supérieure, avec un objectif clair depuis le début : le développement sur Neo Geo.
Ce rêve prend forme.
J'ai dû me remettre à l'assembleur — certains vont me traiter de fou, car il existe déjà des choses en C.
Dans ma jeunesse, je codais en ASM sur Amiga dans la scène demo française. J'étais loin d'être un tueur, mais j'adorais ce langage.
Étant sur Mac (je sais, c'est mal), j'ai décidé de me faire mon setup from scratch, depuis que la version en ligne de commande de MAME est disponible.
Les autres émulateurs Mac ne sont pas terribles, et le debugger de MAME est vraiment excellent.
Je suis parti sur la base de mon jeu de cœur, Art of Fighting.
Le but étant de pouvoir me servir de la PROM pour injecter mon code et recompiler tout l'aof.zip.
Mais très vite, si je voulais récupérer des infos graphiques déjà présentes dans le jeu, je devais pouvoir aller regarder du côté des sprites et du fix layer.
Il existe des outils basiques en ligne, et je voulais vérifier si une police de caractères était présente dans la cartouche.
J'avais trouvé ma police de caractères : elle commençait à la tile 30303, et dans le désordre, s'il vous plaît !
C'était la découverte parfaite pour s'essayer à un petit sine scroll avec ce texte, avec une palette définie à la main.
Uhhh, ça marche ! Ça scroll sur une table sinus à 256 entrées.
Prochain entraînement : l'affichage d'un sprite de personnage complet. Mais comment chercher dans les CROMs ? Tant qu'on y est, autant essayer de faire, en Python, mon propre éditeur de sprites, relié à ce setup de dev.
Python, ce n'est pas du bas niveau, mais pour faire de petits projets, c'est largement suffisant.
Mais c'est toujours pareil : et si on faisait ci, et si on faisait ça...
Du coup, l'idée me vient de pouvoir travailler sur un savestate de MAME, et d'essayer de reconstruire l'image sauvegardée dans le savestate à partir des informations qu'il contient (sprites, fix layer et palettes).
Du coup, j'ajoute une fonction qui ouvre une nouvelle fenêtre pour reconstruire l'affichage à partir d'un savestate pris en cours de jeu.
Mouais, on peut mieux faire : le fix layer est absent, les sprites des persos aussi.
Du coup, grâce au Neo Wiki et à ses fondateurs, on récupère beaucoup d'infos sur les palettes, les registres vidéo, la structure des sprites, et plein d'autres renseignements obscurs.
Les persos, c'était n'importe quoi : j'ai repéré un problème de byteswap qui me faisait chercher les sprites des persos à deux fois l'emplacement mémoire où ils se trouvaient réellement.
Après corrections, les persos sont là, et le fix, entre-temps, a été « fixé ».
Mais pas de décor quand l'image est en taille normale (j'entends : sans dézoomer).
Problème du bit de shrink, qui permet de gérer les « zooms » sur la machine : il manque toujours un morceau.
Ce petit logiciel est pratique, car il permet de récupérer les 256 palettes du jeu. Mais comment savoir quelle palette correspond à quelle image, et surtout à quel sprite ?
Les jambes sont manquantes.
Une erreur de paramétrage sur les sticky bits, qui permettent de coller les sprites ensemble, et les jambes reviennent.
J'ai aussi fixé la bande du haut sur le décor dézoomé, en allant chercher, dans l'éditeur de CROM, où commençaient les décors de cette bande.
Mais j'ai aussi changé de stratégie pour la récupération des données. Le savestate me posant trop de soucis, et grâce aux conseils du talentueux Aurélien, je me suis fait un script qui va directement sauvegarder le contenu de la VRAM quand je fais une pause dans MAME, et ça vient écrire le dump directement dans le dossier de mon setup de programmation.
J'essaye sur d'autres, dans différents stages, pour voir si la structure est bien recomposée. Et la réponse est : vvvooouuiiiii !
Alors, je me dis : est-ce que l'on pourrait ajouter des fonctions supplémentaires qui quadrilleraient la reconstruction, et qu'avec notre souris, en survolant une zone, nous aurions les infos sur l'adresse du sprite ou de l'élément du fix layer, ainsi que sa palette, avec la palette de 16 couleurs qui s'affiche à côté pour en avoir un aperçu ?
Fonction supplémentaire : en balayant avec deux doigts (Mac oblige), on déclenche un zoom/dézoom sur la zone qui nous intéresse, pour être sûr de bien sélectionner le bon sprite.
Bien sûr, on peut aussi extraire les palettes dans un fichier.
Il est 23h50... du matin. Ça fait une journée que je bosse dessus, ma femme ne me parle plus, mes enfants m'appellent tonton !!!!
Et une idée satanique d'Aurélien : griser les zones et ne laisser en couleur que la zone survolée.
Ça marche un peu, mais pas tout le temps.
Bref, à peaufiner, mais l'idée est très bonne (de toute façon, quand t'es proche du soleil, t'as que des bonnes idées).
J'ai mal à la tête, mes yeux me brûlent.
Mais maintenant, grâce à tout ça, c'est beaucoup plus facile de chercher des sprites dans la CROM : tu connais la palette exacte utilisée, il te suffit d'indiquer la palette que tu veux, et les sprites deviennent facilement reconnaissables.
On peut charger toutes les palettes directement depuis le dump.
On peut aussi lancer le jeu avec le système de trace et de sauvegarde de dump depuis l'application.
Et au final, l'identification m'a permis de faire mon sine scroll text depuis mon setup de dev, avec MAME, VS Code et VASM pour la compilation.
Je bosse sur des raster bars (vive les interruptions), des starfields avec des sprites d'AOF, l'affichage de personnages, et plein d'autres trucs.
Le but est de sortir une demo à l'ancienne l'année prochaine, et peut-être, pourquoi pas, un jeu... On m'a déjà proposé, mais je n'étais pas prêt.
Pourquoi faire ça en 2026, alors que la console a plus de 30 ans ??? Et pourquoi pas ? Il y en a bien qui font une réédition de la console avec un nouveau hardware, 30 ans après, et apparemment les gens sont super hypés.
