Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add basic support for rgbds assembly #13831

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

terinjokes
Copy link

@terinjokes terinjokes commented Oct 28, 2024

This adds basic support for assembling and linking Game Boy and Game Boy Color games with RGBDS's rgbasm and rgblink. This also adds knowledge of the Sharp SM83 CPU family, the 8080/Z80-like CPU used on the device's SoC.


An example of this being used can bee seen in the two included tests, as we'll as a fork of pokered.

As demonstrated in test case "2 rgbfix" as well as the pokered fork, many projects will need to call rgbfix to setup the ROM headers to the expected (and computed, in the case of checksum) values on top of the output of executable(). Unfortunately, it's not possible to have the linker automatically call rgbfix, and I wasn't able to find a good place in Meson to add that call. I'm open to ideas as possible alternatives to the custom_target I've documented.

This adds basic support for assembling and linking Game Boy and Game Boy
Color games with RGBDS's `rgbasm` and `rgblink`. This also adds
knowledge of the Sharp SM83 CPU family, the 8080/Z80-like CPU used on
the device's SoC.
@terinjokes
Copy link
Author

I'm open to ideas as possible alternatives to the custom_target I've documented.

I've implemented one possible alternative by adding an rgbds module. However, for the time being I've pushed that work to a separate branch, https://github.com/terinjokes/meson/tree/rgbds-module

@dcbaker
Copy link
Member

dcbaker commented Oct 31, 2024

A module is probably the most sensible way to go about replacing the custom target.

The code here all looks good to me. The one concern I have is that we now have two different languages implementing .asm support. While that should be safe across subproject boundaries, if someone has both the rgbds and asm language enabled at the same time, I suspect that we'll have issues. We probably need at the very least a warning, if not an error, if both get enabled at the same time.

@terinjokes
Copy link
Author

In this specific example, you do already get an error if you declare both in project() as both nasm and rgbasm have non-intersecting CPU constraints. (I was able to workaround with add_languages to be able to set nasm as native)

meson.build:1:0: ERROR: ASM compiler 'nasm' does not support sm83 CPU family

Looking past this specific case (eg, if this PR was adding fasm instead), I can imagine the issues. I'll look at where I could add a warning or error.

@dcbaker
Copy link
Member

dcbaker commented Oct 31, 2024

hmmm, if they're for different machines then that's not actually a problem. As long as the rgdbs only supports the sm83 architecture I think that's fine. You could, In theory, be building an emulator for the build machine and a rom image for a host machine (ie, for the emulator) as a single invocation, and the emulator using nasm to target x86 and the rom using rgbds would be a valid configuration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants