It will help you improve your skills and understand how to start this journey!
Months ago, I told myself: “I have the computing power of Regolo.AI, why not work on a special project where I can gain experience and do something uniquely useful?”
There’s already the gb-recompiled project (Game Boy C transpiler), so why not do something similar for the Game Boy Advance (a topic I’m familiar with, as seen in my FOSDEM 2024 talk) but instead of using C (which I’ll never fully understand), let’s use Python?
For the past few weeks, I’ve been uploading the code for this work to GBAtoPy. The code is entirely AI-generated using Spec-Driven Development workflow, and I analyze what it does, provide explanations, and make adjustments.
I chosen pygame as unique only dependence because is a framework that includes a lot of stuff from keyboards supports etc.
The code generator instead is in pure Rust that use a python file base of the various GBA internals and some stuff is hardcoded in Rust (that in the future can be organized better).
The other thing it was that everything it was planned to be public online.
This will be the first in a series of posts about the project, depending on how it evolves.
What I learned
I fed the AI all the GBA documentation at the assembly level, along with mGBA references.
My first step was to create a setup system that downloads mGBA and test roms with a doc about GBA in this way doesn’t matter what model I use there is documentation that I can provide already evaluated and focused. Because sometimes the AI started doing an Emulator instead of a transpiler, so having references it was important to keep track also of the progress.
After a lot of development, I realized a major issue: automated testing.
The AI works best when it’s independent, so after creating most of the various stubs in Thumb/ARM assembly (yes, the GBA also supports Game Boy ROMs, so it has two internal assembly modes), I moved on to patching mGBA. Initially, I wanted to extend its Lua scripting to add some APIs, but the project doesn’t accept AI-generated code (see PR #3752).
Then I realized the first step was to actually render something. I collected 66 test ROMs (from emulators and other sources) for the GBA, which seemed perfect as a testing baseline. By modifying mGBA to take screenshots at various frames (see custom patches), I could automate the whole process.
And finally, today the first surprise!
Here you can see the transpiled python for the stripes.gba rom and the same one in mGBA.
There is still a lot to do but hey there is a progress!
There is a lot of documentation generated by AI (behind my requests) that you can find on: https://github.com/Mte90/GBAtoPy/tree/master/docs
Instead if you are curious about the test roms: https://github.com/Mte90/GBAtoPy/blob/master/scripts/setup/download_roms.sh
Next steps
Tests all the 66 roms to see if the screenshot are the same until that part is done (and starting working on audio).
Right now the system does 4 screenshot at 10/20/30/60 frames.
I am planning to reorganize the code and maybe generate a more readable Python at the end because transpiling a GBA rom of 352 bytes generated a 200~kb python file (a 8MB rom generated 830~MB of python code).
It make sense after all because it includes all the GBA environment (BIOS, hardware emulation etc) so converting a real game rom probably it will be in hundreds of MBs. IN our case generate 1:1 code from assembly that can be optimized to avoid this duplication everywhere.
Also I want update better the documentation because it is not very good as there is a lot of “noise”.
PS: I am not thinking about the performance right now. Stay updated for the next big interesting… update!
PSS: In the next blogpost I will add also the various reports from the AI during the development that are more interesting.
