
Emulating the Original Gameboy’s CPU - eatonphil
https://medium.com/@raphaelstaebler/building-a-gameboy-from-scratch-part-2-the-cpu-d6986a5c6c74
======
djhworld
Emulating a gameboy is a fun project, I highly recommend it.

The most patience testing element of it is you won't really see any direct
results for quite a while, but once you get that Nintendo logo scrolling down
the screen, achieved from implementing a lot of the core components (cpu,
memory, ppu, screen etc) it's almost like magic and extremely satisfying!

~~~
jchw
Seconded, had a similar experience. I never made it to emulating audio,
though, myself...

~~~
simias
The Gameboy sound chip is definitely one of the trickiest part of the console,
if only because there are a million tutorials out there on how to _start_ a
Gameboy emulator but very few go all the way, and generally the sound chip is
what you do last. It's also surprisingly quirky and many games will misbehave
if you don't implement some weird edge cases.

It's also annoying to debug because it's not as obvious as video when
something is wrong, especially when you've just spent two hours listening to
the same chip tune square waves in a row...

~~~
Andrex
I'm interested in writing my own GB emulator mostly because sound is so patchy
across all existing JavaScript implementations.

My entrance into the GB scene coincided with my interest in LSDJ, and I really
want to write a web app around it[1], but I'm stymied by outdated
implementations and my own lack of domain knowledge.

[1] [https://github.com/andrewrabon/little-web-
dj](https://github.com/andrewrabon/little-web-dj)

^ Still unfinished. My own emulator will probably have to come first.

~~~
simias
The most thorough reference I've found for the Game Boy SPU is unfortunately
the Gambatte source code itself since it's a fairly accurate emulator and open
source. Unfortunately it's also not the most human-readable code (due to
micro-optimizations and lack of comments, plus it's C++ which is already a -10
handicap in readability).

In the meantime you can try to dig around my code which is not nearly as
accurate but (hopefully) should be easier to understand:
[https://github.com/simias/gaembuoy/blob/master/spu.c](https://github.com/simias/gaembuoy/blob/master/spu.c)

It seems to work fine with all games I've tested, although of course that's
only a tiny subset of the console's library...

------
simias
That's a good introduction. The GameBoy is really a good starting point to get
into emulation, I recommend it.

I've been thinking about making my own tutorial for Gameboy/Gameboy Color
emulation over the past few months, I've even finished writing the emulator
itself:
[https://github.com/simias/gaembuoy](https://github.com/simias/gaembuoy)

I've made sure to rebase all of my fixes to have a single, linear, clean
commit history that should be easy to follow. It can play most GB and GBC
games. Now I _just_ need to make the actual tutorial, but I want to make
videos and I know nothing of video editing so I'm afraid that writing the
emulator was actually the easy part.

If somebody has tips for video editing on Linux, I'll gladly take them...

~~~
johnchristopher
Well, talking on the video will be faster than writing out articles but will
it result in materials best suited to your intended audience ?

edit: also, video editing is the final process of putting everything together.
Which learning style are you going for ? What visuals are you using to support
that ? How are you going to assess your audience's progress ?

Pedagogy is a really interesting and rewarding field ! So many ways, so many
questions !

~~~
simias
I believe it can be, I find that explaining things using animations and being
able to use a more casual tone while narrating can be helpful and easier to
follow.

I've already tried writing a PlayStation emulation guide:
[https://github.com/simias/psx-guide](https://github.com/simias/psx-guide)
(only covers the very basics unfortunately). I found that in order to really
get in-depth I had to write big walls of text to explain relatively simple
concepts. Being able to talk more casually and expressively over illustrations
can be less daunting for somebody looking to get into emulation.

Regarding your edit: I already took a bunch of notes while actually
implementing the emulator so I have a fairly clear idea of what my script will
look like (i.e. Intro -> CPU instructions -> timings -> basic GPU ->
controller input -> sprites -> sync to real time -> etc...). I won't focus on
the code too much because it's not a programming tutorial, it's meant to me an
emulation tutorial. It would be targeting people who already know how to
program but might not be comfortable in the low-level and don't know where to
start.

------
_Donny
I can also highly recommend the PyBoy[0] project for Game Boy emulation. It is
written in Python, has an accompanying report for documentation, and is still
being developed.

It provides an interesting basis for student projects to work on, such as
machine learning on games, rewinding time and replaying (great for machine
learning), adding the sound-subsystem, link-cable, and much, much more.

[0]: [https://github.com/Baekalfen/PyBoy](https://github.com/Baekalfen/PyBoy)

------
eliasson
Anyone interested in how the Game Boy works should watch "The Ultimate Game
Boy Talk" by Michael Steil.

[https://www.youtube.com/watch?v=HyzD8pNlpwI](https://www.youtube.com/watch?v=HyzD8pNlpwI)

------
aquova
One of the reasons I first got into programming was due to a fascinations with
emulators. Several years later, I'm finally working on a Gameboy emulator of
my own. It's a really rewarding experience, I had taken a brief look at GB
assembly code before and couldn't make head or tails of it, but after
implementing the CPU and memory, a lot of the actions taken within code
finally make sense.

I'd like to write my own document on emulator development someday, but I need
to finish my own first. I'm nearly at the point where I can display a screen,
hopefully sometime within the next week.

------
nottorp
"The Gameboy’s CPU is known as the DMG CPU. It is equipped with 6 registers of
16 bit each and they’re called AF, BC, DE, HL, SP and PC."

Those look like Z80 register names. Guess it's a Z80 and the article autor
doesn't know that?

~~~
DanBC
It's not really a Z80. This article talks about the differences:
[https://realboyemulator.wordpress.com/2013/01/01/the-
nintend...](https://realboyemulator.wordpress.com/2013/01/01/the-nintendo-
game-boy-1/)

Or this one:
[https://gbdev.gg8.se/wiki/articles/CPU_Comparision_with_Z80](https://gbdev.gg8.se/wiki/articles/CPU_Comparision_with_Z80)

~~~
userbinator
I suspect Nintendo may have started with a Z80 core and then customised it a
little bit, similar to what they did with the almost-6502 in the NES.

~~~
simias
It's definitely based on the Z80, but it's also different enough that you
can't really base yourself on Z80 docs to implement the Game Boy CPU (I
learned that the hard way). The flags are different, the timings are
different, some instructions are removed, some instructions are added etc...

------
atum47
How long did it take to make? I been thinking about writing my own emulator in
JavaScript for a while now. I know there's a lot of great projects out there,
but I like to make one myself.

~~~
Macha
Depends how accurate you want to get.

Getting an implementation of the CPU instructions in a high level language
with instruction level accuracy and approximately correct timings is a weekend
or two project.

Going for extra components like the graphics or audio support, or higher
accuracy in terms of cycle counts and timing can make it a lot longer.

