Writing a Game Boy emulator
cturt.github.io
cturt.github.io
The Game Boy hardware is, on its surface, extremely simple (as an example, there is no “operating system”, only a 256 byte (!) boot ROM that pretty much only serves to display and validate the Nintendo logo shown at start), and it has a vast library of games available for it that make use of that hardware to varying degrees.
This means that you can get really good results really fast. Especially the earlier games, like Tetris, don’t rely on fine grained implementation details too much, so even a sloppy, quickly put together emulation can run them well.
But if you then strive for accuracy or just being able to run more complex games, you can take things to almost arbitrarily detailed levels of this somewhat “fractal” complexity, uncovering and implementing all sorts of interesting hardware intricacies.
Contrast this with even slightly more recent game consoles, where you will have a lot of busywork ahead of you to even get the system past any reasonable definition of “booting”, without any gratifying visual feedback. With the Game Boy on the other hand, getting to a game’s title screen, with working buttons and all, is actually pretty simple.
If you want to write a complete emulator, I can imagine that the Game Boy Advance can be a bit more of an undertaking with the different alternative graphics modes.
There are some really nice ones out there too. There are a few js-based ones that can run in the browser!
After that, realistically, I would start looking at one of the existing GB emulator write ups, just enough to understand how things fit together. You can get pretty far on the Game Boy e.g. without even implementing interrupts (not sure, I don't think the boot ROM really needs them), so don't hesitate to experiment already.
Finally, have a few references ready (like available opcode tables and the infamous Game Boy CPU pdf that's easy to find), but keeping in mind that they do contain inaccuracies.
A lot of understanding will come while implementing.
I am surprised by this statement, as it's generally as easy as xcode-select --install to install the CLT (or failing that, installing full-blown Xcode). Slightly up in the article there is mention of Lion, so maybe this is related.
Then there's the problem of libraries. You have to use homebrew or whatever to install libraries in /usr/local. Some libraries would conflict with the system though, so you have to fiddle with env variables to make the build system find it.
Overall, building on MacOS/Xcode is a frustrating experience. I ended up installing nixos and using its toolchain for my work...
brew install gcc@8
OSX requires binaries to be signed to give them tracing/debugging privileges (or you can use root). It would be nice if Apple made this less painful -- or rather, if they stopped making native development increasingly more painful with every OS release.
I'm quite glad random unsigned binaries don't have the right to unilaterally attach to (signed) processes, otherwise the signature would be moot.
Perhaps we'll start doing a Nintendo64 emulator instead which is more complex but from what I've heard/read has much better documentation.
Furthermore E9 is not "JP (HL)" but rather "JP HL". If I remember correctly a few timings or instruction sizes are off as well.
http://gbdev.gg8.se/wiki/articles/Main_Page is my current documentation of choice - which seems to be based on the same .pdf but has a bunch of updates and errors corrected
Suddenly every game you have in your library becomes puzzle box and either works (yay!) or much more often for a young emulator, breaks in a perplexing way. It creates a really rewarding feedback loop, where tiny changes to timers and status registers can have big sweeping effects on your tests. And all your tests are themselves games, and usually fun to explore anyway.
I’d state the opposite and claim that it’s actually one of the most fun and interesting things I’ve ever undertaken. In fact, I am more interested in the process than the actual product. There are tons of well working Game Boy emulators already.
Besides, part of the challenge is that there is no comprehensive spec for the Game Boy, so discovery through research and implementation is part of the process.
In contrast to the creativity that you can exercise along many dimensions of implementing an emulator, riding a bike or laying at a beach with a cocktail is hardly „creative“ at all, yet many people enjoy doing that as well (I certainly do). You said you might even enjoy playing with the resulting emulator, that seems even less creative to me.
Some documentation is good to get you started, but at a certain point it’s the actual software that should be the guiding factor. Inaccurate documentation, which is not uncommon for the Game Boy, can be unnecessarily misleading though (on the other hand, there’s some satisfaction in essentially proving a different behavior, especially if you accept a piece of documentation to be likely inaccurate from the get go).
...unless you use MSVC, which has had that as an extension for a very long time (since MSVC6 at least.) I wonder if MS was the one who got that into C11.
Why these letters? I'm assuming I, J and K are reserved for specific uses... is G likewise?
A is the accumulator, F is flags, and as the sibling comment mentioned, H and L represent the high and low bytes of HL, which is the only 16-bit register you can use for indirect memory access in most instructions. It's also used in some control-flow instructions.
That leaves four remaining registers, which just so happen to fit perfectly into the remaining space: B, C, D, and E. (They can also be accessed as BC and DE with 16-bit instructions.)
That's excellent, when I wrote mine I wasn't aware of this feature and used a kludge of macros to handle it instead.
For most target hardware, this shortcut provides a reasonable approximation of the intended output image. However, some older hardware relied upon specific characteristics of CRT displays to enhance the graphics. For example, some clever developers found that they could create extra colors by swapping the palate during the vertical blanking interval on interlaced NTSC video.
Of course, some of the earliest video game consoles don’t have a framebuffer since RAM was to expensive. For these consoles, you will be stuck writing a video display emulator.
Just curious, why use anything except dolphin for emulating gamecube?