In my recent post I have been talking a lot about the GBA and some of my plans of writing homebrew for it. I have already tested a few small things but now I want to set up a development workflow for it. This means testing examples, tweaking and running on real hardware. The obvious way to do this is running a ROM in an emulator and ofcourse this is part of that workflow. But at some point it needs to be tested on real actual hardware. And that is what I am going to talk about today 
Over the last few days I have been reading a lot of documentation and I think I have a very basic idea of how to use the system. What I would really like to have something similar to wiiload and 3dslink that allows me to "upload" a new ROM to test stuff out on the hardware. Since the GBA already has a build-in feature that allows it to download programs over a link cable that was originally meant for multiplayer that is a good place to start. For this purpose I have cut a multi-player cable and wired it to a Raspberry Pi to test a few programs I had found. While the upload speed is quite low it does work for small programs. I am currently using a python script that's based on a C++ uploader and the cable is connected to a breadboard and jumper wires....resulting in a less than stable connection. But at low speeds it seems to work good enough though.
The other obvious way to test bigger ROM's is using a flashcard's but the hassle of swapping SD cards get's old really quickly! What I am planning is to create a "gbalink" uploader that runs on the raspberry (or eventually on a remote PC) allowing to upload "multi-boot" homebrew to the GBA. As an extension to that I also want a way to have the uploaded program act as a "bridge" so I can access the RAM and VRAM from my PC with various commands. This will allow me to easily test graphics and sprites without compiling a new ROM every time!
To give an idea of how I see that upload work:
- execute command: "gbalink remote_mb.gba"
- "gbalink" will wait for a GBA and upload that ROM to it
- the "remote_mb.gba" ROM is a small loader that will wait for commands like:
- READ: read a RAM location in 8,16 or 32 bit mode
- WRITE: read a RAM location in 8, 16 or 32bit mode
- UPLOAD: upload data of size x (I guess small packets of 1-1024kb) or something would be nice)
- DOWNLOAD: same as upload but in reverse
- DMA: Use DMA to copy data from one place to another. (useful to upload graphics data or OAM data and than quickly transfer it to the GPU)
Maybe more useful commands could be added but this should be enough to get the idea. While I have an EZ Flash Omega on it's way to play with later, at the moment I only have the SuperCard MiniSD. While it's considered a bad and cheap flashcard it's what I have and hopefully it's good enough. It should have 32MB of RAM and it has an SD card slot to load data from. No matter how slow it might be loading data from it should be WAY FASTER than over the link cable Ofcourse the 2GB card limitation and no SDHC is an issue but I think it's only a problem of the default firmware being outdated! Electrically the SD cards are compatible but the protocol to access the card and the default filesystem are different, and that is why it does not work. Since I need to add SD card support manually in homebrew anyway why not test this theory right
In case anyone knows of helpful documentation or already existing apps (opensource preferred) please let me know. At least all my projects are keeping me too busy to get bored
Over the last few days I have been reading a lot of documentation and I think I have a very basic idea of how to use the system. What I would really like to have something similar to wiiload and 3dslink that allows me to "upload" a new ROM to test stuff out on the hardware. Since the GBA already has a build-in feature that allows it to download programs over a link cable that was originally meant for multiplayer that is a good place to start. For this purpose I have cut a multi-player cable and wired it to a Raspberry Pi to test a few programs I had found. While the upload speed is quite low it does work for small programs. I am currently using a python script that's based on a C++ uploader and the cable is connected to a breadboard and jumper wires....resulting in a less than stable connection. But at low speeds it seems to work good enough though.
The other obvious way to test bigger ROM's is using a flashcard's but the hassle of swapping SD cards get's old really quickly! What I am planning is to create a "gbalink" uploader that runs on the raspberry (or eventually on a remote PC) allowing to upload "multi-boot" homebrew to the GBA. As an extension to that I also want a way to have the uploaded program act as a "bridge" so I can access the RAM and VRAM from my PC with various commands. This will allow me to easily test graphics and sprites without compiling a new ROM every time!
To give an idea of how I see that upload work:
- execute command: "gbalink remote_mb.gba"
- "gbalink" will wait for a GBA and upload that ROM to it
- the "remote_mb.gba" ROM is a small loader that will wait for commands like:
- READ: read a RAM location in 8,16 or 32 bit mode
- WRITE: read a RAM location in 8, 16 or 32bit mode
- UPLOAD: upload data of size x (I guess small packets of 1-1024kb) or something would be nice)
- DOWNLOAD: same as upload but in reverse
- DMA: Use DMA to copy data from one place to another. (useful to upload graphics data or OAM data and than quickly transfer it to the GPU)
Maybe more useful commands could be added but this should be enough to get the idea. While I have an EZ Flash Omega on it's way to play with later, at the moment I only have the SuperCard MiniSD. While it's considered a bad and cheap flashcard it's what I have and hopefully it's good enough. It should have 32MB of RAM and it has an SD card slot to load data from. No matter how slow it might be loading data from it should be WAY FASTER than over the link cable
Ofcourse the 2GB card limitation and no SDHC is an issue but I think it's only a problem of the default firmware being outdated! Electrically the SD cards are compatible but the protocol to access the card and the default filesystem are different, and that is why it does not work. Since I need to add SD card support manually in homebrew anyway why not test this theory right In case anyone knows of helpful documentation or already existing apps (opensource preferred) please let me know. At least all my projects are keeping me too busy to get bored
