I've never used Java before this year but one of the computing courses I've been taking requires it so I've been learning on the go. With the firm conviction that it's more fun to learn a language and its features on your own project, I decided to develop a Game Boy Color emulator. I used to live on a boat so when my friends and I played video games they were of necessity all played on my Game Boy pocket, and considering that all other kids my age also had Game Boys we use to have a lot of fun with them as a group. The fact that the Game Boy Color (GBC) has a relatively simple architecture with a variant of a classic processor, the Z80, just made the choice easier.

Unfortunately, learning Java by making an emulator is like trying to learn to sail in the desert. Java doesn't have an unsigned byte data type which would be useful to have for emulating an 8 bit system and doesn't support operator overloading which would be useful in making your own. Additionally, there's no simple, low latency, real time audio synthesis library that I can find so far, and the graphics library with which I'm most familiar, SDL, doesn't have up to date Java bindings. Nevertheless, the point of using Java was to learn and from that perspective, the project's been at least moderately successful.

The Game Boy Color processor is backwards compatible with the original Game Boy processor but features 8 times the quantity of general purpose memory, twice the video RAM, the capability to display 56 15 bit colours simultaneously, the ability to double the CPU core clock speed, and many more improvements in capability. The processor is largely derived from the Z80 excluding the extended, IX, and IY instructions. The processor can address a 16 bit space of which the first 32kB is dedicated to cartridge ROM. As the majority of gameboy games are larger than 32kB they use one of four official memory mappers known as Memory Bank Controllers (MBC) which can switch between different banks for a possible ROM size of 2MB.

Unlike the GBA which supports bitmaps graphics modes as well as its own form of mode 7, the GBC only supports a tiled video output. Hardware video features allow for simple and fast object rotation, movement, palette switching, and more. I naively expected the video hardware features to be far less extensive when I started emulating the video hardware and as a result I've only so far implemented the relatively simple background layer. Normally, what Nintendo called objects and the rest of us call sprites, are overlaid on this background to produce the entirety of the graphics. The sprites and background can share the same tiles and function similarly but sprites are more complex because one needs to emulate movement, rotation, and z priority. Nevertheless, I decided to write this post because it's exciting to have some early screenshots to share.

combined
Buggy screenshots showing backgrounds without sprites and other small miscellaneous issues.

Of course, because I resent writing tests bugs abound everywhere. In many cases I'm unsure as to the genesis of a bug. Is the game not running because it's checking that sprites have moved and sprites don't yet exist? Is it a bug in another video functions? Is it a CPU bug? I've learnt the hard way that just because your CPU passes a test ROM doesn't mean you should trust it. Anyway, Tetris has a strange bug and I'm not sure if it's graphical or CPU.

Tetris is screwed up yo. It's interesting to see that rather than being a demo where sprite movement is completely planned, the demo is just the Gameboy playing the game with the same logic and rules.

Tetris is screwed up yo. It's interesting to see that rather than being a demo where sprite movement is completely planned, the demo is just the Gameboy playing the game with the same logic and rules.