The official Game Boy Programming Manual [0] leaked and is available at the Internet Archive. It's a great resource.
If you're just getting started with assembly and want to look at a short program, my maze generator [1] is available on GitHub with annotated source code.
It's actually Z80-ish with some features missing and some new ones included. It's a Sharp LR35902 SoC with an SM83 core (not sure if it has been used in non-GB SoCs).
I can recommend The Ultimate Gameboy Talk for details on it (and much more).
I believe the LR35902 SoC is exclusive for the Game Boy, but the actual CPU core, SM83, is probably used elsewhere. Sharp's datasheets [2] mention home appliances as intended application.
Yes, I've dabbled around with the NES as well. But the Game Boy is close to my heart as I had one as a kid. So most of my projects [3] revolve around that old gray brick.
Recently got an EZ Flash Jr to get into playing homebrew gameboy games on my (unmodded) GB pocket from middleschool. Itch.io has more fun GB games than i'll ever have time to play and its felt like a really positive community.
Then while bored in a meeting at work I started looking into coding a hello world for it and quickly found my way to some Assembly tutorials which Ive never had an excuse to touch.
- Retro development is “in”, a ton of the kids from the 1990s and 2000s are seasoned programmers with some free time now, or enthusiastic hobbyists.
- The tools have gotten a lot better. RGBDS, GB Studio, emulators with debugging capabilities, etc.
- Game Boy development in particular is an excellent entry point. The system design is simply excellent, and it feels like you’re working with a highly polished “2.0” of something. C works well enough on Game Boy, and assembly is approachable. You’re not writing code for multiple different architectures at the same time.
Of course you can. There's a good amount of homebrew out there for various retro systems and a good chunk of those will sell you the ROM to download or even offer a physical cart. If you drive enough hype you can even make money porting it to newer platforms, e.g Pier Solar which was originally a homebrew Sega Genesis game but now has ports to several modernish platforms like PS3, PS4 and Steam.
We've also seen "new" retro systems like the Playdate.
Depending on the platform, easy enough to bypass lockout. The traditional way to lock out old consoles is to require you to include some material with a Nintendo copyright or trademark on the cartridge. That way, Nintendo can sue unlicensed game developers for copyright or trademark infringement. Various systems of this kind have been bypassed without the use of infringing material.
The lockout circuit on the NES, for example, can be bypassed by sending it a negative voltage spike. You can put the circutry on your cartridge.
There's a lot of retro dev happening now across the board. SGDK has led to a big interest in making Genesis/Megadrive games. Jo Engine is increasing interest in the Saturn, etc. I'm also attempting to help contribute by writing a book on Neo Geo development (it has a long ways to go)
I just would absolutely love to give a +1 for jo-engine. It’s an insanely strong dev kit for Saturn games with great built in features like tilemap support, basic collision detection; a sprite converter - and a handful of incredible tutorials.
I got started as a developer / programmer at about 10/11 with mostly Assembly due to the burgeoning Sonic ROM hacking community. I’m 32 now and I’ve been a professional developer for 12+ years. I owe this scene a lot!
IMO C for GameBoy dev is a non starter. It's so different from other platforms that you really just want to control the instructions directly. Say you type "a * 5" that would just be one instruction on a regular cpu but it must be some more expensive function on a GameBoy. Even bit shifting can only shift one bit at a time, 1<<8 is 8 instructions. When programming in ASM it's usually that more instructions is slower so for a bit shift it might make sense to have a lut or something, C would hide it behind a single operator.
ASM will tend to be more efficient, especially if written by someone with experience and skill, but that isn't enough to prevent other tools from being used successfully. It's described in much more detail in the linked article.
In order to filter out "Game Boy-like" material on itch.io, you can also use the tag "gamboy-rom". Then it should only show you entries that will run on actual hardware (such as a flash cart or in an emulator):
As for advice on starting: a great thing to do is figure out a simple, small project to start with, and dive in. That will help give you concrete tasks to focus your learning of the hardware and dev tools around, and keeping the scope modest will prevent it from being overwhelming. There are a handful of tutorials if you want to try that route, and plenty of support (forums & discord).
Agreed too, Game Boy development has been exploding in the last couple years. GBStudio's arrival really brought making GB games within reach of a much larger pool of people. The ability to make them was no longer limited only those able to write software (or those working with them). This brought in a TON of graphics, music, storytelling and creative talent.
Gameboy C (and later Gameboy Advance) was actually a big part of discovering programming for me (after QBASIC). I didn't have a great idea of what I was actually doing - lots of copy-pasting, changing stuff around, cargoing, trial-and-error.. But I made stuff happen and it was super exciting.
It's kind of amazing that even 20y+ later, a lot of the resources, tools and even websites are the same as back then. The community is just great.
Reading the OP, I think you won't need much more actually - it's not very complicated, which is part of the attraction compared to modern SE... Just start playing around and see where it takes you. Look at code from other people for inspiration.
I can´t recall what were the main sites for classic GB but gbadev.org was a gold mine and seems to still be around and kicking.
If you are interested in retro game development, I highly recommend the Nintendo Game Boy or Game Boy Color as a development target. You can develop games with either Z80-ish (Sharp SM83) assembly or C. The system has most of the features of the NES, but has a ton of kinks worked… I like to think of it as a dream version of the NES.
It's really limited, though. Sometimes that is nice, but if you want a bit more of a comfortable environment, the GBA is wonderful. It's got a decently fast processor and enough RAM to not have to worry too much about it, and it's got some really interesting hardware that is easy to use but also allows lots of interesting trickery.
Oooh! I’d also love to recommend GBA homebrew development, especially if you’re a little wary of learning Assembler.
I had a fantastic time in high school, grade 11 or so (2005?) - playing with the homebrew development kit at the time…
The joy of GBA is a much broader palette - well - any colours whatsoever, if you’re just talking straight GB (no GBC) - and access to some fun hardware tricks like scaling, extra background layers; honestly - it’s like an SNES pro or something. I love it.
‘Never use recursive functions’ is one of those stories that comes up in embedded. For automotive work it is one of the SAE’s ground rules.
Since The 1980s, when LISPers decried Microsoft BASIC’s hegemony we were told that recursive functions are a superior answer. They are for some things, but as soon as you start coding in assembly (pure assembly, not a few lines of Assembly to optimize a C program) you start to see stack calling conventions as a problem as much as a solution.
It's good to distinguish between general-recursive and tail-recursive functions. Tail-recursive functions can be transformed into code that uses a bounded amount of stack (no more than a single call worth). The latter kind of functions could be used freely on systems where general recursion is forbidden, and sometimes are a clearer or more succinct way to specify the required behavior (and sometimes not)
Some lisp-adjacent languages like clojure use a special syntax for tail-recursive functions[0], so that you document and know at compile time that you don't have a general recursive function.
Tail recursions are just very badly documented while loops. In a while loop it is very clear if you use memory or not, in a tail recursion you have to inspect the code and realize if it is tail recursive or not, and if you do it wrongly you just accidentally used a lot of memory for the stack. And tail recursions doesn't do anything you can't do in a while loop, recursions only power is the power to use the stack, without it they don't add anything.
There are other sorts of data structures that interest me.
A number of my Arduino projects break down into definitive layers such as something that spools several threads of graphical data out of the program memory, processes it to make a line for a persistence of vision display, then either flushes pixel data via SPI to a lightstrip or sends the data via the serial line to my PC for testing.
If I recoded it in AVR8 assembly I would have no stack or reenterant or recursive subroutines. Everything would be allocated statically or would go in a register, depending on the graphic data you need a variable number of cursors allocated (like the way dimensions of arrays were set in the configuration of a FORTRAN program long ago.)
I haven't recoded it in assembly because I'm still thinking I might need to switch to a more capable board with a different CPU and the portability makes up for C being a very annoying language (e.g. the stack, calling conventions, and all of that is a problem instead of a solution for the programs I write)
(I think maybe... If performance isn't good enough I'll run a soft AVR8 inside an FPGA and offload the hard parts to the FPGA but that is going from the frying pan to the fire.)
Another alternative to the stack is the approach used by asyncio in Python and many similar frameworks where you maintain flat contexts of execution that can be managed at arms length by some kind of dispatcher but that are executed intimiately by coroutines.
I wonder if we could have a web based GameBoy editor, like the Pebble had. Just write code on the site and have it compiled and pushed out at the click of a button?
GB Studio seems to have some of that. Maybe just a little more magic to get it there?
RGBDS-live may be just what you had in mind. I can't remember exactly, but there may have been some experiments with a SDCC based C version of that as well.
https://daid.github.io/rgbds-live/
There was also a precursor to GB Studio which seemed headed in that direction. It was written by the same person who did GBStudio:
https://www.chrismaltby.com/projects/gbdkjs
If you're just getting started with assembly and want to look at a short program, my maze generator [1] is available on GitHub with annotated source code.
[0]: https://archive.org/details/GameBoyProgManVer1.1
[1]: https://github.com/svendahlstrand/10-print-game-boy