Choosing tools for Game Boy development(gbdev.io)
gbdev.io
Choosing tools for Game Boy development
https://gbdev.io/guides/tools.html
37 comments
Delightful! Is it 6502?
Edit: It appears to be Z80. Have you done any NES ASM?
Edit: It appears to be Z80. Have you done any NES ASM?
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).
https://m.youtube.com/watch?v=HyzD8pNlpwI
EDIT: I had the SoC and the core names the wrong way around. Thanks svendahlstrand.
I can recommend The Ultimate Gameboy Talk for details on it (and much more).
https://m.youtube.com/watch?v=HyzD8pNlpwI
EDIT: I had the SoC and the core names the wrong way around. Thanks svendahlstrand.
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.
[2]: https://duckduckgo.com/?q=sharp+sm83+datasheet
[2]: https://duckduckgo.com/?q=sharp+sm83+datasheet
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.
[3]: https://hackaday.io/project/167042-joy-boy
[3]: https://hackaday.io/project/167042-joy-boy
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.
https://itch.io/search?q=gameboy
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.
https://m.youtube.com/watch?v=RZUDEaLa5Nw
It seems like a really awesome entry point for C or Assembly. Wondering if anyone has any GB development beginners advice in addition to this post?
Also is there a GameBoy dev zeitgeist or is it just coincidence that I feel like Im seeing a lot of developer stuff pop up for it lately?
https://itch.io/search?q=gameboy
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.
https://m.youtube.com/watch?v=RZUDEaLa5Nw
It seems like a really awesome entry point for C or Assembly. Wondering if anyone has any GB development beginners advice in addition to this post?
Also is there a GameBoy dev zeitgeist or is it just coincidence that I feel like Im seeing a lot of developer stuff pop up for it lately?
> … is there a GameBoy dev zeitgeist …
It’s not just you.
- 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.
- Game Boy hardware is still reasonably priced.
It’s not just you.
- 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.
- Game Boy hardware is still reasonably priced.
I'm wondering if there is anything that can be converted into a commercial adventure. I see a few retro options here:
- develop games for popular retro platforms. So far Nox Archaist for Apple ][ is the most successful example.
- develop a new hardware as platform. So far I have seen a lot of projects such as Arduboy but none of them is successful enough AFAIK.
- develop games for popular retro platforms. So far Nox Archaist for Apple ][ is the most successful example.
- develop a new hardware as platform. So far I have seen a lot of projects such as Arduboy but none of them is successful enough AFAIK.
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.
We've also seen "new" retro systems like the Playdate.
For carts for retro platforms, wouldn't Nintendo/Sega sue for commercial activities? Just curious.
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.
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.
The trademark method of lockout is also probably not legal at least in some parts of the world. See Sega vs. Accolade.
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)
https://github.com/Stephane-D/SGDK
https://www.jo-engine.org/
a Saturn homebrew showcase - https://www.youtube.com/watch?v=NqKKExcTaKo
https://neogeobook.mattgreer.dev
https://github.com/Stephane-D/SGDK
https://www.jo-engine.org/
a Saturn homebrew showcase - https://www.youtube.com/watch?v=NqKKExcTaKo
https://neogeobook.mattgreer.dev
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!
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.
Plenty of games are being written in C for the Game Boy on a regular basis.
Just a few polished examples of that: https://tangramgames.itch.io/tobu-tobu-girl-deluxe
https://user0x7f.itch.io/black-castle
https://binji.itch.io/porklikegb
https://pocketpixel.design/super-jetpak-dx-game-boy-rom.html
https://aiguanachein.itch.io/powa
https://thegreatgallus.itch.io/cavern-mvm-9
https://user0x7f.itch.io/gunship
https://www.infinitygbc.com/
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.
Just a few polished examples of that: https://tangramgames.itch.io/tobu-tobu-girl-deluxe
https://user0x7f.itch.io/black-castle
https://binji.itch.io/porklikegb
https://pocketpixel.design/super-jetpak-dx-game-boy-rom.html
https://aiguanachein.itch.io/powa
https://thegreatgallus.itch.io/cavern-mvm-9
https://user0x7f.itch.io/gunship
https://www.infinitygbc.com/
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.
Great recommendations.
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):
https://itch.io/games/tag-gameboy-rom
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.
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):
https://itch.io/games/tag-gameboy-rom
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.
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.
Too late to add a reply to the person asking, but way back then this was a goldmine: https://www.devrs.com/gb/
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.
Also a shout out for DS homebrew. Hella fun.
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.
Also a shout out for DS homebrew. Hella fun.
It's like an SNES pro, with the caveat that the audio capabilities of the GBA are much less than the SNES.
That said, the audio capabilities on the SNES are difficult to use.
That said, the audio capabilities on the SNES are difficult to use.
Game Boy and Game Boy Advance are definitely both at the top of my list.
This is a great overview! I would personally love to see a feature-length documentary on the rise of the modern-day Game Boy development scene.
‘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.
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.
[0]: https://clojuredocs.org/clojure.core/recur
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.
[0]: https://clojuredocs.org/clojure.core/recur
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.
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.
For the Go folks, https://dev.to/aurelievache/learning-go-by-examples-part-5-c...
>>> if you are using VBA or VBA-rr, stop using them right now. These emulators are extremely inaccurate, and also contain severe security flaws
thnx for the alert! does this include mgba?
thnx for the alert! does this include mgba?
mGBA is great, and actively developed.
mGBA's sound for GB/GBC is still inferior to VBA's. See these comments by the mGBA dev and others: https://www.reddit.com/r/emulation/comments/sdlxz8/so_in_202...
In any case, mGBA has nothing to do with VBA, so there's no reason why that statement would include it.
Personally, I've been using BGB for 10 years or so, and it's been great.
In any case, mGBA has nothing to do with VBA, so there's no reason why that statement would include it.
Personally, I've been using BGB for 10 years or so, and it's been great.
Is there a tool to decompile gameboy roms into C? Could be an interesting way to learn a bit about how the system works, as well as learn a bit of ASM
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?
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/
Source: https://github.com/daid/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
Source: https://github.com/daid/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
Very detailed guide, thanks for share. I am wondering what the position of Zig language in retro gaming development.
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