
GameBoy CPU Manual (2013) [pdf] - pplonski86
https://realboyemulator.files.wordpress.com/2013/01/gbcpuman.pdf
======
simias
If you're interested in making a GB emulator here are a few resources that
helped me when I did just that a few years ago:

\- An intro to making a GB emulator in JS (it doesn't matter if you don't plan
on using JS, it still explains the basic concepts pretty well):
[http://imrannazar.com/GameBoy-Emulation-in-
JavaScript:-The-C...](http://imrannazar.com/GameBoy-Emulation-in-
JavaScript:-The-CPU)

\- Opcode map (note that the GB CPU is _not_ a stock Z80, it has different
timings, different registers, different flags and different opcodes, do not
use stock Z80 docs as a reference lest you end up with broken CPU emulation):
[http://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html](http://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html)

\- The GameBoy programming manual:
[http://www.romhacking.net/documents/544/](http://www.romhacking.net/documents/544/)

\- Accuracy test ROMs, very useful to make sure your timings are ok and you
emulate various quirks of the hardware:
[http://tasvideos.org/EmulatorResources/GBAccuracyTests.html](http://tasvideos.org/EmulatorResources/GBAccuracyTests.html)

Also note that even if you focus on making an original (DMG) GameBoy emulator
you should be able to add GameBoy Color support later without too much
difficulty, it's a fairly straightforward evolution of the original hardware.

~~~
b_tterc_p
Dumb question: is there a reason to make a gameboy emulator besides interest?
Is it not a completely solved problem space, with all games playable with
optimal performance?

~~~
simias
It's like writing a raytracer or ray-casting engine, it's not particularly
useful but it's pretty fun and it can learn quite a lot while doing it.

In the case of emulators I suspect that many developers nowadays never went
underneath the syscall layer (or even beyond the interpreter) so if they're
interested to learn about how it all works deep down it can be a good
challenge. Of course the GameBoy is archaic in most ways but it's a start.

------
Eiriksmal
Every time someone resurfaces the Pan Docs in a new form, I'm reminded of how
I haven't touched my Gameboy dev efforts[0] in months. As fun as it is to
conquer the Z80, it's difficult to get motivated working in an ecosystem that
is _still_ almost utterly without development tools.

Kirby's Dreamland was programmed with a track ball running on a hacked up
Famicom. [1] We haven't come too far since then.

[0]
[https://github.com/Eiriksmal/gameboy](https://github.com/Eiriksmal/gameboy)

[1] [https://arstechnica.com/gaming/2017/04/the-first-kirby-
game-...](https://arstechnica.com/gaming/2017/04/the-first-kirby-game-was-
programmed-without-a-keyboard/)

~~~
chrismaltby
I’ve been working on a little adventure game maker for GameBoy over the last
few months actually. I’ve been sharing a few alpha builds on a mailing list
and pretty close to releasing now. Was hoping to post a Show HN soon!

[https://www.gbstudio.dev](https://www.gbstudio.dev)

~~~
chronogram
I still cannot find a good Paint alternative for macOS but soon it will have a
gameboy game maker :-)

Really excited about it. Good luck!

~~~
Crinus
Have you tried Paintbrush? It is basically a modern mix between MacPaint and
MS Paint (the good one, not the abomination introduced in Windows 7).

[https://paintbrush.sourceforge.io/](https://paintbrush.sourceforge.io/)

------
jchw
I really like the Gameboy hardware; it's limited, but the design feels very
elegant in it's simplicity.

I've written a couple of toy Gameboy emulators at this point. It's a bit
challenging to get anything working, and honestly I have no idea how to
approach audio at all. Nevertheless, it's still quite fun. The LCD timings are
a point of curiosity for me. It seems there's still a slight bit of mystery
around it, still today.

I was inspired to play with emulating Gameboy specifically after an excellent
33c3 talk, The Ultimate Game Boy Talk, which I highly recommend.

[https://youtu.be/HyzD8pNlpwI](https://youtu.be/HyzD8pNlpwI)

(Some day I would like to approach emulation for more platforms, both newer
and older, but I feel I still have so much time learn about designing
emulators that I haven't bothered with that yet. It's so open ended, and
handling things like cycle counting has a lot of different approaches of
varying desirability.)

~~~
anyfoo
You might really enjoy this talk as well, then:
[https://youtu.be/GBYwjch6oEE](https://youtu.be/GBYwjch6oEE)

~~~
jchw
Oh thank you, I've never seen this talk nor heard of this conference but on
it's face it sounds like it's right up my alley.

------
mastrsushi
I was gonna say this depth of exposure would have a major impact in
performance for all the GB emulators our there. Then I realized they probably
don't need any more performance impact because they're GB emulators.

~~~
bredren
Is this document brand new?

~~~
Eiriksmal
It's been circulating in various forms since the late 90s, IIRC. Commonly
referred to as the "Pan Docs."

[http://gbdev.gg8.se/wiki/articles/Pan_Docs](http://gbdev.gg8.se/wiki/articles/Pan_Docs)

------
_srbu
I have recently finished a GameBoy DMG/CGB emulator with friends from school
[https://github.com/nbouchin/gbmu](https://github.com/nbouchin/gbmu)

It was a lot of fun!

~~~
Yajirobe
How do you use it

------
Waterluvian
If you're a web developer or someone working pretty high level and have this
desire to explore the depths, here's a project idea for you. First write a
CHIP8 emulator in your most comfortable language, then write a Gameboy
emulator in something like Rust or C++.

~~~
vSanjo
I would love to, but have - genuinely - no idea where to begin beyond tearing
down someone else's work on Github.

Can you recommend any starting paths for someone like you mentioned?

~~~
zeta0134
For the CHIP-8 emulator in particular, this is a good starting point:

[http://www.multigesture.net/articles/how-to-write-an-
emulato...](http://www.multigesture.net/articles/how-to-write-an-emulator-
chip-8-interpreter/)

Or you could just read the documentation directly here:

[http://devernay.free.fr/hacks/chip8/C8TECH10.HTM](http://devernay.free.fr/hacks/chip8/C8TECH10.HTM)

CHIP8 was itself an interpreted bit of hardware, so it's reeeeally loose with
things like timing requirements. Just run a couple dozen instructions per
"frame" in your game loop, then draw the screen somewhere, and you'll come
close to playability for most of the sample games if your interpreter is bug
free. It's the kind of project that with enough motivation you could complete
in a week or so, which is why it's usually recommended for a first emulator
project.

Once you have CHIP8 working somewhat, think about how you had to structure
your code to make that work. Wouldn't the z80 CPU in a gameboy, or the 6502
CPU in an NES, also have opcodes just like the CHIP8 interpreter did? Surely
you wrote a function for each CHIP8 opcode, so why not write a function for
each z80 opcode, figure out how to read the gameboy's cartridge header, and
see if your new CPU can run some instructions from Tetris? Once you get the
code writing to VRAM, can you draw the tiles? What about the background? Build
the emulator up piece by piece, and suddenly your game library is just chok
full of little puzzle boxes, waiting to be tackled one by one.

It's very difficult to do all of this _accurately,_ but don't focus on that
right away. Just get it working, and learn about the system as you go.

~~~
djmips
It's really pervasive that the CPU in the Gameboy is a Z80. It's not. It's got
a few instructions from the Z80 but it's closer to the 8080 overall.

------
ArtWomb
GB never dies ;) And Nintendo hardware remains a great way to explore
computation internals:

CPSC 305: Computer Systems and Architecture

[http://ianfinlayson.net/class/cpsc305/](http://ianfinlayson.net/class/cpsc305/)

Using The Game Boy Advance To Teach Computer Systems And Architecture

[https://www.researchgate.net/publication/323199083_Using_The...](https://www.researchgate.net/publication/323199083_Using_The_Game_Boy_Advance_To_Teach_Computer_Systems_And_Architecture)

~~~
cmpgamer
This was my professor! It was honestly a cool class. Half of it was learning
CPU design from the bottom up, and the other half was programming for the GBA.

------
n-gauge
One thing I would like to see in a gameboy emulator is the option to record /
input from file keypresses so that you can test speedruns or find exploits.

I was thinking this would be trivial for something like a js emulator where
you usually have a key array defined for storing keypresses.

If anyone knows of a GB emulator that already allows this please link to my
comment.

------
kbumsik
Is it a fan-made document or extracted from the vendor (Nintendo)? If it's the
former, it is surprising to see how they ended up with writing a chip
reference manual-grade document.

~~~
userbinator
Definitely fan-made. The formatting feels off, probably because it was
originally a text file that was converted into a PDF. Thus you see section
headings with proportional font, but body text in monospace with ASCII art
diagrams and tables.

------
aappleby
Beware, contains errors.

(been writing a gameboy simulator for a few months now...)

~~~
softblush
Maybe consider pointing out those errors

