daid / gbsdk

Gameboy Software Development Kit

Gameboy Software Development Kit

This is the Gameboy software development kit. For mixed assembly and C programming. Note that this isn't a mature project yet.

If you want to do C programming for the Gameboy, https://github.com/gbdk-2020/gbdk-2020 is much more mature.

If you want to do assembly programming for the Gameboy, https://rgbds.gbdev.io/ is the goto toolchain.

But... but...? Why this then?

This project has a few goals:

• Thin/no abstractions. GBDK-2020 is an oddball of low level functions, badly named functions and high level functions with horrible performance and side effects.
• Mixing of C code with ASM code, without subjecting yourself to the asxxxx syntax.
• A different linker. By using the rgbds linker instead of the SDCC linker, a bunch of features that exernal tools provide on gbdk-2020 are standard.

Usage

To use this, you need to have installed:

• sdcc (version 4.2.0)
• rgbds (version 0.5.1)
• python (version 3.6 or newer)
• A strong will, and a bit of crazy.

See https://github.com/daid/gbsdk-template for a ready to use template of a project setup.

gbsdk's Issues

"jp (hl)" instruction not handled properly

SDCC can generate the instruction jp (hl), which is incorrectly converted into jp [hl]. It should be jp hl for RGBASM.

Proposal: Relicensing runtime-linked code to avoid copyright notice dependencies on binaries

In short: It is often tough to comply with a copyright notice preservation requirement for binaries when self-contained ROMs are distributed digitally or on cartridge. Most projects do not comply with such requirements even today, leading to mass copyright infringement in homebrew scenes (for example, usage of newlib in GBA/NDS/PSP/Wii/3DS/... homebrew).

For this reason, many projects (my own WIP toolchain collection Wonderful, libnds, smaller things like decompressors) have opted to use, for the library code which is statically linked with the target binary, a license which does not impose such a requirement. Example options include:

• the zlib license (my personal preference), which preserves the requirement for source code but not binary form,
• the Boost Software License, which has a similar effect,
• licenses which do not impose any attribution requirements, like CC0, 0-clause BSD, etc.

My suggestion is that, in order to allow building modern toolchains which are easy to comply with the license of by end users, the runtime library code (inc/ and src/ but not tools/), it would be worthwhile to consider relicensing said code in GBSDK to one of these licenses. GBSDK is in an unique position here, as it does not include decades of difficult-to-relicense legacy code.

No support for ASxxxx ".byte" directive

asmconvert.py does not support the ".byte" directive, which works exactly like the ".db" directive.