mgbdis
v2.0
Un désassembleur Rom Game Boy.
Nécessite Python v3.6 ou version ultérieure.
Les fichiers d'assemblage générés par MGBDIS sont conçus pour être assemblés avec RGBDS V0.6.0 ou version ultérieure.
Démonter une rom:
./mgbdis.py some-game.gb
La sortie par défaut est au répertoire disassembly . Vous pouvez vérifier le résultat du démontage en exécutant make puis en vérifiant le fichier game.gb (ou game.gbc ) créé:
cd disassembly && make
Il existe également un certain nombre d'options disponibles pour contrôler le style de mise en forme et d'instruction du code d'assemblage généré. Vous pouvez les afficher en fonctionnant:
./mgbdis.py -h
Les fichiers de symboles vous permettent d'indiquer où se trouvent les blocs de code, de données, de test et d'image dans la ROM.
Les instructions du Game Boy CPU (SM83) ont des longueurs différentes, et les données peuvent être entrelacées avec du code dans la ROM, il n'est donc pas possible d'identifier toujours avec précision où commence une instruction et s'arrête. La définition des blocs de code dans un fichier de symboles peut aider à éviter les problèmes avec les MGBDIS essayant de se désassembler au milieu d'une instruction.
Si vous n'avez pas de fichier de symboles, vous pouvez essayer d'en générer un avec mon émulateur de jeu Boy - Batten Dying Moon. Vous pouvez soit utiliser la démo Web, soit il existe des builds disponibles pour Windows et MacOS. Il peut générer un fichier de symboles avec des définitions de blocs de code en fonction des adresses des instructions qui ont réellement été exécutées pendant que vous jouez au jeu, en évitant les problèmes d'alignement des instructions.
Pour utiliser un fichier de symboles avec MGBDIS, il devrait exister dans le même répertoire que la ROM et avoir le même nom, sauf modifier l'extension pour être .sym .
Toutes les valeurs (sauf pour les largeurs d'image) doivent être en hexadécimal. Les entrées commencent par un numéro de banque suivi de l'adresse en mémoire.
Les types de blocs peuvent être définis en utilisant les étiquettes. .code , .data , .text et .image Magic, suivies de la longueur du bloc en octets.
Ajout d'une étiquette pour un code:
03:47f2 Read_Joypad_State
Ajout d'une étiquette pour 512 octets de données:
0d:4800 Level_Data
0d:4800 .data:200
Ajout d'une étiquette pour 16 octets de texte:
00:3d00 Character_Name
00:3d00 .text:10
L'étiquette Magic .image vous permet de définir des blocs de 1 ou 2 bits par pixel de données de carreaux dans la ROM. Les images sont sorties sous forme de fichiers PNG dans le répertoire /gfx du démontage et sont converties en données de tuiles 1BPP ou 2BPP par le makefile à l'aide de RGBGFX. Si une étiquette est spécifiée à l'adresse du bloc d'image, elle sera utilisée pour le nom du fichier PNG.
La longueur du bloc en octets doit être un multiple de 16, car chaque tuile nécessite 16 octets de données d'image.
La largeur d'image dans les pixels peut être spécifiée comme un numéro décimal préfixé avec w . La valeur de largeur doit être un multiple de 8, et la combinaison de la longueur du bloc et de la largeur de l'image doit entraîner une image rectangluar sans carreaux vides. La largeur d'image par défaut est 128 pixels, ou si la longueur du bloc indique un nombre impair de tuiles, une image avec une seule ligne de tuiles sera générée.
La palette est une valeur de taille d'octets qui sélectionne les nuances de gris à utiliser lors de la génération de l'image. Il utilise le même format que le registre BGP à 0xFF47 . La valeur peut être spécifiée en hexidécimal préfixé avec p . La palette par défaut est E4 .
La valeur par défaut est de le traiter comme 2 bits par pixel de données de tuiles. Une option 1bpp peut être fournie pour traiter les données comme des données de carreaux de 1 bits par pixel.
Ajout d'une étiquette pour 1280 octets de données de carreaux, avec une largeur de 128 pixels et une palette 0xe4:
02:791a Title_Screen_Tile_Data
02:791a .image:500:w128,pe4
Image résultante:
Exemple pour les données de carreaux 1BPP:
05:4000 Font
05:4000 .image:200:w128,1bpp
Image résultante:
NOP après STOP et HALT , de sorte que le désassembleur les sortira sous forme d'octets de données si l'instruction n'est pas suivie d'un NOP dans la ROM d'origine. Utiliser --disable-halt-nops avec MGBDIS pour demander aux RGBD de désactiver l'insertion d'instructions NOP automatiques après les instructions HALT .
