Add gameboy (SM83) ruledefs, platform, and example #222
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What it says on the tin. The GameBoy's SM83 CPU is kinda like a Z80... if you vaguely described a Z80 to someone over a bad phone line. A lot of things that work on a Z80 do not work on a SM83, but there are some shared features; however, I just took the SM83 opcode table, found the patterns in instruction encoding, and translated them into ruledefs.
The constants in platform/gameboy/constants.asm come from hardware.inc, a well-worn definitions file that pretty much every GameBoy homebrew project uses (though it has been known under other names too) for register locations, bit flags, and other magic values that you need in order to write a GameBoy game.
The cart_rom.asm file doesn't actually output a header; this is because unlike the NES' iNES header, the GameBoy header actually includes data that someone making a ROM might want to control (things like GBC or SGB compatibility, game title (which some emulators display), revision number, etc.). Instead, it defines the ROM bank, puts you in it, and gets out of your way.
The common_banks.asm file sets up banks for things that don't change no matter what MBC you use; this is VRAM, SRAM, WRAM, HRAM, and OAM.
Finally, the example ROM is a simple Hello World. Unfortunately, customasm isn't powerful enough to generate the right header checksum, but fortunately, most emulators don't care (and tooling does exist to fix that if you feel like fixing that is necessary). It uses ibmpc1.bin, a binary representation of the classic IBM PC font, as its font of choice.
NOTE: I'm currently (5/19/2025) on a loaner laptop due to hardware issues, so I can't actually test if this builds correctly within the repo, but my local working copy of the ASM built, and the only thing I changed was paths (
<std>
rather than using..
to get back to top level).