#Gameboy color emu comparison manual
#Gameboy color emu comparison code

The aforementioned Ultimate GameBoy talk contains a pretty good explanation on how the Gameboy copies video memory into screen, using the fetcher.

#Gameboy color emu comparison code

The bootstrap code displays a scrolling “Nintendo” logo using the basic GPU features, so I already had a way to test the first implementation.įor the GPU, I also wanted to have it emulated closely to the original. Gameboy displays two kinds of graphics: background (which is usually more static) and sprites (moving objects, like Mario or falling block in Tetris). The next step was implementing the basic graphics support. That was exactly the thing I was looking for - after just 3 days I had an application running the Gameboy code!įor (Entry t : indexedList(0x0b, 0x10, 'BC', 'DE', 'HL', 'SP')) ').load(t.getValue()).alu('DEC').store(t.getValue()) However, when the original Gameboy starts, it executes a simple 256-bytes program, a kind of firmware displaying the Nintendo logo and self-testing the system.

I had neither the cartridge nor the GPU emulation yet, so even the simplest game wouldn’t be an option. After implementing the opcodes and memory (modelled by an int array) I was eager to check whether it’s possible to run some code on it.

#Gameboy color emu comparison manual

As a reference, I’ve used the GameBoy CPU Manual - later on I discovered that it has a few typos and is not specific enough for some of the operations. It’s not exactly the Z80, but it’s pretty close. CPU and memoryįirst I implemented all the Gameboy CPU opcodes.

how do the interrupts work and why they’re useful.įor all of these points I had a general idea before, but actually implementing them required a deeper understanding.

how does the GPU display pixels on the screen, what are the HBlank and VBlank,.

how does the CPU work and what are the opcode cycles,.

However, it wasn’t the point to conquer the GB emulators market, but rather to completely understand the architecture of a simple computer system and implement it in a performant way. Of course it was - there’s a dozen of existing GB emulators, created in JS, C, Java, Rust, Python and probably all the other languages. My family members who saw this and friends who heard about this from me often asked if this hasn’t been done before. It was also very addicting - every time I had a few minutes during the day and basically every evening I felt an irresistable urge to move the emulation a bit forward - fix this strange GPU bug, pass one more compatibility test or implement one more missing feature.

At the same time it was one of the most engaging and rewarding side-projects I’ve ever had. I realized later that it wasn’t exactly the truth - creating a working program was quite a challenge. After watching The Ultimate GameBoy talk found on the Hacker News, I realized that the Gameboy architecture is quite simple and maybe writing a running emulator for this kind of machine wouldn’t be that hard - especially that it’s well documented too. I imagined this big switch construct that chooses the right operation for the current CPU opcode and the array modelling the memory. The old computers are great on their own, so this kind of connection between historic machines and the modern computing environment feels almost like a time travel.Īs a developer I often think about the internal design of an emulator. Being able to run code from a completely different hardware architecture always seemed like a magic. Why did I spend 1.5 months creating a Gameboy emulator? įor me, the most favorite type of a computer program is an emulator.