I always upvote everything GB-related on HN. Keep it coming!
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.
You might be in luck here! In the US, patents last for only 20 years. Since, the Game Boy was released in 1989, any patents are long since expired.
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]
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.
Didn’t EA go to court with Sega over exactly this? I believe the court said using a trademark as a device to prevent access to a device was not applicable.
I feel this way about the GBA. It's modern enough to offer things like a 32-bit pipelined CPU that can be targeted with a modern C[0] or Rust[1] toolchain, but you are still extremely close to the metal. Even decade old PCs can run emulators that focus on accuracy rather than raw performance, and the physical AGS-101 has pretty nice backlight without any mods. Plus many of the games have aged extremely well, with the graphical style of e.g. Pokemon Emerald still being closely followed in modern indie games.
I, too; am a huge fan of GBA homebrew dev, in high school; honestly, it was supremely helpful in me mastering the C language, and; even better - it led to my DS development days, which was far, far, more fun.
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...)
A few months ago I also built a GameBoy emulator with the intent of educating myself. It's in Java and uses Swing for the GUI. It also supports sound but its implementation is definitely not ideal.
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.
Huh, I'm pretty sure I did exactly this initially, but it didn't work. Maybe it didn't work because some other instruction that the test itself relies on didn't. I'll check again, thanks.
I wanted to write an 8080 emulator for the hell of it. What target? I started in Javascript, but I ended up writing it in 8088 (MS-DOS) assembly, because it has all the same flag behavior built in. Way more fun!
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.
Imagine a 6502 game boy? 3 hours of battery but those spirits would fly.
Also imagine a PPU similar to NES. Would have been tons of ports. I’m actually not sure why they didn’t go this route. They didn’t use stock 6502 so repackaging would have been fine.
Hi HN, author here! The GameBoy emulator written up in this post runs on axle, which is a message-passing microkernel-based OS I’ve been working on for a very long time. dang suggested that I put together a Show HN for axle, which I’d love to do once I have a bit more time to get things into a working-out-of-the-box state!
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 was thinking, for myself; growing up as a SEGA kid, I'd far rather implement a GG/SMS emulator, heh.
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.
I had a 95% accurate emulator for GG/SMS running in one night. The only bit I took off-the-shelf was some C code for the Z80. I promise you it is pretty easy - if you've coded some assembler before then you'll pick it up really quickly. You don't even need to know Z80 opcodes or anything - it is more about mapping all the memory addresses and setting up an onscreen bitmap to blit all the sprites to.
I see posts like this and wonder: with the amount of coding necessary to write your own OS and then write a retro emulator for it, do you do anything else with your free time?
(Implicit question: are the rest of us just slackers?)
axle is definitely one of my main hobbies, and since it's important to me I try to find time to work on it! Often, what happens is that I'll get really passionate about some thing or another (like the GameBoy emulator!) for a few weeks, and work in a frenzy to hammer it out. If you multiply this by years you're left with quite a lot of product!
Despite it being so far behind my skill-set it’s not even funny, I absolutely love reading about custom made OSes, so I’m definitely keen to read a write-up on yours.
If you are interested in it, you should dive in. Every OS ever written was written by someone for whom it was beyond their skillset at one point, everybody has to learn.
At first I misunderstood the title, thinking that for your hobby OS you targeted gameboy hardware. Makes me wonder what would be the first game console you could really make a usable GUI OS on.
I had guessed 3DO but a Google search turned up an article about one for the NES. I don't know if it qualifies as "usable" though because it can only run a word processor that supports 8 files containing a screen each of text.
The limiting factor for old consoles is largely RAM. The NES only had 2 KiB of RAM, making it pretty infeasible to even run anything CP/M-like. Its 6502 CPU also doesn’t have things like privilege levels/memory protection.
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.
It's true the NES has 2 KiB built-in RAM, but a cartridge can provide its own RAM. Some of the later cartridges (MMC5 for example) supported up to 128 KiB of extended RAM. There's not really any limit to how far you could push that with a custom mapper.
Thanks a lot, and it's really great to hear that you're interested in reading a full PPU writeup! This is the first time these posts have been in the public eye, so it's really encouraging for me. I'd definitely like to go back and flesh out that post, and more so now that you've inquired.
Not OP, but if you mean that ~200 page doc, it's pretty good but has some issues and inaccuracies some places, but it might just be me. Some things like how carries are supposed to work in some edge cases, for example, but I think it was written under the assumption that the reader would be familiar with a standard Z80 chip.
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.
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...