RGBDS is a toolchain to develop in assembly for the Game Boy. It is used by many projects nowadays, and I'm not talking about small ones:

The only real alternative is WLA DX, as far as I know. I personally don't like the syntax (because of small things like using parentheses instead of square brackets for indirection) but it is probably as powerful as RGBDS, and it's worth taking a look at it if you want to do something serious for the GB.


It was released in 1997 as ASMotor by Carsten Sørensen as a general-purpose assembler for DOS/Win32. In 1999, it was modified by Justin Lloyd and released as RGBDS. In 2009, Vegard Nossum adapted the code for the toolchain to be more UNIX-like and released it as rgbds-linux. In 2010, Anthony J. Bentley forked the repository and improved on it, becoming the reference implementation of RGBDS. Then, in February 2017, he asked me if I wanted to be its new maintainer, I accepted, and he moved the repository to a neutral username. Basically, I was one of the few people still proposing new changes and fixes, so it was a safe choice.

Nowadays, this project is located here: https://github.com/rednex/rgbds

It is important to know that during all this time (20 years!) many people have contributed to it, not only the main maintainers mentioned above. This had left the codebase in a really complicated licensing situation. The original code was released without a license, and pretty much every new contributor used a variation of the BSD or MIT license for new changes.

This is why I tried (and succeeded!) to get all the main authors to agree to change the license so that all the codebase would have the same one. In the end, all of the main contributors answered and gave permission to relicense their code, and the MIT license was chosen: https://github.com/rednex/rgbds/pull/225

In any case, because of its story, I don't think it makes sense to consider this the project of a specific person in particular. At some point it just becomes a project of the community.

How it works

RGBDS is divided into rgbasm, rgblink, rgbfix and rgbgfx. In the past, there was another tool called rgblib, but it was quite pointless as nobody really used it, and the object format breaks quite often when adding new features to the toolchain.

  • rgbasm: Assembler.

    It takes a file with source code as input and generates an object file as output. It uses yacc/bison to parse files, which is a bit problematic because of the source code syntax and how hard it is to resolve conflicts.

    It is really flexible. It has support for macros, unions, even for referencing local labels through the parent label. Of course, the address of labels is not always known at compile time, it is only known if the value is directly assigned, or if the base address of the section is directly assigned. In order to be able to resolve their address at linking time, or even be able to calculate simple expressions with them (addition, bit masks...) there is a RPN language that is used in object files to tell the linker how to operate with them. Each value that has to be modified by the linker generates a patch of RPN instructions.

  • rgblink: Linker.

    It reads all object files generated by rgbasm (and potentially a linkerscript with information about where to place sections) and generates a raw GB ROM, that is not generally ready to directly use in a GB.

    In short, it places all sections in their final locations and calculates the final value of all RPN patches. It can also generate files with a list of labels and addresses to help debugging.

  • rgbfix: ROM fixer.

    Used to fix a finished GB ROM. There are some fields in the header that must have the correct value for the game to boot in a real GB. Some of this fields are difficult to fill at linking time, so it's easier to have an external tool for it, that's where rgbfix comes in handy. It also pads a ROM if the size isn't a power of two.

  • rgbgfx: Graphics converter.

    This tool converts png files into the format that the GB uses. I must admit that I've never used this tool, but it is used in disassemblies extensively.


I find it really interesting that this toolchain has managed to survive for such a long time, and that it is still used so much. It's mostly used by disassemblers, I must admit, but hey!

As I've said before, this project wouldn't be nearly as useful if it wasn't thanks to all of its contributors. Because of it, it is always open to contributions. They don't have to be big or fancy, even small bug reports (or bug fixes!) are welcome. So yeah, let's keep this project alive!