I wrote a GameBoy emulator for my hobby OS (2022)
axleos.com
axleos.com
GB Studio, upvote.
Cool people writing their own emus, upvote.
Analogue Pocket, upvote.
My sincere wish is that one day Nintendo somehow, someway, open up legitimate Game Boy publishing for third-parties again. Release the patents, allow developers the use of the Nintendo logo in the one very very specific place it's necessary to allow GB games to boot, etc. Maybe open sourcing schematics and internal docs.
But that's as likely as them releasing a (new) Mario game on PC...
For me, the GB is that perfect middle ground between too arcane/simple and too modern/complex (both the design of the games and in the programming required). If the platform were opened, it would be kind of a "forever console." It would obviously not compete with new systems or anything like that, so it would always be pretty niche.
It would be a fantastic educational tool to get kids into programming and game design at various levels.
Maybe in another 20-30 years...
Using the Nintendo logo might (NB: Not a Lawyer!) be permissible if it's required for software to run on the hardware. This was a big part of the Sega v. Accolade case.[1]
There are still new games being released on cartridge for the original Game Boy. The most recent I'm aware of is Ruby & Rusty last year.[2]
[1] https://en.wikipedia.org/wiki/Sega_v._Accolade
[2] https://www.bitmapsoft.co.uk/product/ruby-rusty-save-the-cro...
Two publishers I've been keeping a very close eye on are SpaceBot Interactive and Ferrante Crafts.
https://www.spacebot-interactive.com/games
https://www.etsy.com/shop/FerranteCrafts?ref=usf_2020
Also, seems like there's some legal stuff around this I need to research more extensively. But the spirit of what I was trying to say is that it would be awesome to have Nintendo officially bless it... But it's unlikely they ever will.
[0]: https://gbadev.org [1]: https://docs.rs/gba/latest/gba/
Dealing with the DS, especially; wow. Two screens, touch input, I gotta say, as a developer it felt like an open canvas; even if I was; like...15 at the time, lol.
It's what led me into iOS development when the App Store was officially announced. (I must've been 18 at that time? 19?) I, again; saw this as a multi-touch open canvas for creating basically anything my mind could imagine, at the time; the extreme restrictions Apple placed on App Development were actually nothing compared to the limitations of e.g. the DS, much less the GBA. (at least the DS had a wi-fi stack, lol...)
While most of the games I tested are playable, I couldn't get SBC and ADC instructions to work correctly for all cases. I especially have no idea whatsoever how they're supposed to affect the carry flags. Test ROMs aren't very helpful either because the ones I used just ran the instruction with all possible combinations of input parameters, checksummed the results, compared the checksum to the expected value, and said "duh, your thing is wrong". And Googling around wasn't any more helpful. Since most of my childhood games ran fine anyway, I gave up. I'd still like to fix it eventually though.
That said, writing a video game system emulator is a tedious but rewarding experience. You just move bytes around and do an unhealthy amount of bit operations, and a game comes out. IMO every software developer should try writing an emulator at some point.
SBC:
result = byte1 - byte2 - carry
carry = result < 0
return result & 0xff
ADC:
result = byte1 + byte2 + carry
carry = result > 0xff
return result & 0xff
ZEXALL and derivatives are pretty good test suites. I think it checksums results but it does have lots of tiny tests to exercise particular instructions and operands. You'll still need to single-step through all the code that runs the generated test suite and prints the results. I know there's a port to a Sega Master System rom (ZEXSMS), dunno about the Gameboy.
axle is a really fun project for me, and serves as the testing grounds for all kinds of technical experiments. The bore-you-with-features spiel goes something like: x86_64, SMP, UEFI bootloader, TTF rendering, compositing window manager, TCP/IP stack, AHCI driver, custom assembler/linker, and, of course, a GameBoy Emulator!
When working on axle, the level of yak shaving can get pretty extreme. For example, when I got around to writing axle’s first network card driver, I was puzzled when my driver could transmit packets fine, but failed to receive any packets. I dug around for quite a while before considering that it might be a QEMU bug, and tracked it all the way to macOS’s incomplete implementation of poll(), which QEMU was relying on! I ended up writing a patch for QEMU to work around it, and, several layers up, was finally able to progress on the network card driver and network stack. This was back in 2021, but I wrote up the journey recently here: https://axleos.com/adding-vmnet-support-to-qemu/
axle was mostly C-based for a lot of its history, which can get pretty gnarly both in kernel-space and when trying to write higher-level productivity software in userspace. Recently, I’ve been writing a lot more of in Rust, but for the past couple of years that’s been confined to userspace only. When adding SMP support to the kernel, though, I added Rust to the kernel too. It’s really nice.
One other fun thing I’ve been working on semi-recently is a homegrown IDE with an assembler/ELF-linker that runs under axle. I found the linker pretty difficult to get right, because a lot of the ELF data need to know the size and locations of other bits of data in the binary, and it’s tough to shake everything into place in a way that has serial data dependencies! It’s immensely gratifying, though, to write some assembly, generate an ELF at runtime, and execute it. I also added some process-monitoring hooks into the kernel while working on this, so the IDE application can monitor the output of the assembler/linker, and show the output of the generated program, all within the GUI. I uploaded a quick demo video of this IDE here: https://www.youtube.com/watch?v=YG9XyzSBUNg. This whole shebang (IDE + assembler + linker/ELF binary-packer) is written in Rust.
Thanks for reading — I hope you enjoy the post, and let me know if you have any questions!
And then wrote my own Game Gear emulator for it one night, just for shits and giggles, like you did. It was also my first attempt at writing a whole system emulator, and the GG, like the GB, was incredibly well understood even back then.
For anyone interested in emulation I think it is a great little project to write a video game emulator. It is enormously fun to watch one of your favorite video games boot up in code that you wrote. And it is fun (for me) to try and debug all the little glitches where you've made errors or omissions in your emulator.
I would say my interest is perked, though! I have a number of projects at the go currently that I think would prevent me from really dedicating all the effort I'd need to a project of that magnitude, but...it's also Z80, yeah? Mainly?
I did mostly Genesis ASM back in my ROM hacking days, which was 68k, with a Z80 sound chip.
Moving up to the Sega Genesis with its 16-bit 68000 that many old UNIX systems were built around: it still only has 64 KiB. But, hey, that’s a lot better than 2 KiB, and it has memory protection. But the 68000 can’t do virtual memory (unassisted) and I don’t believe the Genesis has a timer interrupt, which seems like it’d complicate multitasking (I guess you could run the scheduler when the graphics system raises the vertical retrace interrupt?) but IMO it’s about the minimum level that could run something like what we tend to think of today when we talk about an operating system.
(Implicit question: are the rest of us just slackers?)
I ended up finding the documentation wrong in a handful of places, which made the project tedious. Did you find that document reliable?
Something else I noticed was that there were some specs that I guess the gameboy follows, but not exactly. For example with swapping pages, it's supposed to take up to (I forget the actual numbers) 50 cycles, but the actual gameboy always finishes in exactly 38 cycles, and some games are written for that.
In the end, what worked for me was finding a working emulator that would output the registers' states every operation, and then making sure mine would match up with it.