DEV Community


Posted on • Updated on

Rusty Boy - Week 0: Where are we?

Rusty Boy, what is that?

Great question! Rusty Boy (also known as rusty-boi and rusty-boy, depending on the day), is the name of my Gameboy emulator, which I'm writing in Rust. I know, a very creative name.

A bit of History

I started this project back on August 2019, almost a year ago.
I've always been interested on emulation, it's a pretty fascinating thing, but I've never coded anything on that area. So having a lot of free time in my hands, I started with the classic CHIP8 interpreter. It was written in C#, and I got it running on a day (give or take).

Around this time I also discovered Rust, which would later become my go-to language to do stuff. But let's not get ahead of ourselves here.

I wanted to learn Rust, so I did what any reasonable human would do: I started reading The Book. A few chapters later and I did, again, what any reasonable human would do: I started writing an emulator on a language I barely knew.

Here's where a big question showed up: what platform will I emulate?. I had a few candidates - the NES, Sega Megadrive, another CHIP8 interpreter. I started with the NES, but it didn't really get anywhere, but the rusty-* naming was already there. This is when I landed on the Gameboy. This is where the juicy part of our story begins.

A Gameboy Emulator

Seemed simple enough, right? A handheld console from 1989, can't be so hard. Oh Lord, I didn't know where I was getting myself into. In retrospective, this project is probably not the best "Hello, World!" kind of project to start learning a language, but it's been a fun ride so far.

Early build
A very early build of what would become Rusty-Boy

The Gameboy is a pretty interesting console. The good thing about emulating something this old is that a lot of things are very well tested and documented. Not all of them, but you get a head start at least. You can get creative later.

So, how's Rusty-Boy running? Another great question right there!

The Tests

The go-to tests when developing an GB emulator are blargg's CPU tests. This test suite checks that your emulator executes most instructions properly, and that their flags are also correct.

On this area, Rusty-Boy is currently doing pretty well with just 4 tests failing out of 11.

blargg's CPU tests
Not perfect, but getting there

Running the individual tests I can see what instructions are currently failing the tests, and they range from expected (DAA on test 1), to not quite (ADC and SBC on tests 4 and 9). I'll get them fixed eventually.

Gekkio's test for mooneye-gb are also a very comprehensive test suite for different areas of the emulator - timing of instructions, unused bits of memory registers, DMA transfers, memory banks for cartridges, and a lot of others. While I haven't ran all of them yet, I can pass some of them. I'll probably fail most of the other though, since timings are not my biggest priority right now.

A test
One of Gekkio's tests passing

More recently, I even wrote a simple test myself! I was having some issues with CPU interrupts, so I wrote a test on GB Assembly, which I checked with BGB (a very accurate emulator with a great debugger) and the various docs I've been using.

My interrupts test

While the test itself is pretty simple, it helped me pinpoint some issues with my interrupt handling.

The Games

It's a Gameboy. Part of it is running games, right? Well, yeah, but not quite here. Let me explain.

Rusty-Boy has been though a lot of rewrites. The latest rewrite resulted on a huge speedboost. While I'm very happy of how it runs, it's also a problem. Games tend to run very fast, which would render them unplayable, or at least very hard to play. That is of course, if I actually managed to get any inputs through - games mostly ignore inputs.

My best theory for this issue right now is that since it runs so fast, inputs get written to the register, but the window for them to actually get read by the game is pretty small. Limiting speed should eventually solve the issue (I hope). Games still run though, to different degrees of success.

The next biggest issue for games would be the absence of sprites. They were implemented a while back, but got temporally axed on the last rewrite (the same that brought the speed issues). So a considerable amount of graphics are missing.


A timeless classic. Runs pretty well actually, or so it'd seem at least. Falling pieces are missing because of sprites not being implemented.

Tetris Menu
Tetris' Menu working perfectly

Tetris ingame
Tetris ingame - Sprites are missing

The Legend of Zelda: Link's Awakenings:

The intro sequence runs pretty well, but I can't say the same for the menu. Can't progress any further because of broken inputs.

Intro sequence
The intro sequence is mostly fine

The menu
But the menu is pretty broken


A recently released horror game. Currently boots fine to the menu, but the menu's background gets partially covered by the Gameboy's window.

deadeus menu
The black window covers most of the background

What else can it do?

Well, Rusty-Boy has some nice features I've been recently adding.
This is the emulator's window with all its components enabled:

main window
Rusty-Boy's Main Window

I've been adding debugging capabilities into the emulator itself, which includes viewing CPU Registers, settings breakpoints, viewing video registers, the background and the window before getting merged into a final frame, interrupts, and the memory disassembler.
While some things might be a bit close to the feature creep area cough disassembler cough, it's pretty nice to have all that data in one window.

Closing Up

Well, this has been my crash course for you into Rusty-Boy, featuring a trip down memory lane, and the current state of yet another Gameboy emulator.
Hope it was a good read and that you'll come back, since I plan to write a new entry each week with new changes and improvements to the emulator. There's still a lot to do, and I still want to work on it, so we'll keep moving forward. But now with cool looking reports.

See you in a week?

Top comments (0)