Emulating the Original Gameboy’s CPU | Hacker News Reader

Emulating the Original Gameboy’s CPU

medium.com

132 pointseatonphil29 comments

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!

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

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...

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

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

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

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...

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

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...

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 !

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 (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.

Video editing is trivial compared to writing an emulator. Get davinci resolve. Anything else will just crash and lag.

Thank you for the tip, ideally I'd prefer an open source solution but I realize that might be asking for too much. I'll give it a try.

There is OpenShot but I haven’t used it. The main features I tend to miss in the OSS video editors are proxy editing (which is an enormous timesaver) and basic audio features like side-chain compression. You may or may not care about the same features that I do.

I like to record voiceover in a separate audio track and process it separately in post. From what I can tell, OpenShot doesn’t support videos with multiple audio tracks.

Depending on what type of video you're trying to do, Komposition might hit the spot https://owickstrom.github.io/komposition/

OpenShot is really nice, and stays out of your way enough to where you'll be able to edit quickly.

How much pain are you willing to take for your ideals? If you need something super simple you might be able to just use ffmpeg.

thank you so much for doing this! here goes one resolution for 2020! i will be checking the repo.

small side rant: your repo name -- not saying you should change it, you are allowed to use any name you want -- is a good example of google always trying to outsmart users and being frustrating.

it keeps auto-replacing my search for me. i mean i know i can quote the search but i tend to bookmark a lot from my phone. and it's easier to search for sites i know exist than having to type long urls. so frustrating sometimes when it tells me i didn't mean what i meant...

Eh, it's not so much trying to be smart and more trying to be unique I suppose. I guess I could've named it "my-gameboy-emu" but I'm always a bit wary of using copyrighted names in emulation projects, probably more out of superstition than anything else to be honest.

If you have an other proposition I'm all ears, I don't really care for the name to be honest. Open an issue if you want.

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

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

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.

"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?

It's not really a Z80. This article talks about the differences: https://realboyemulator.wordpress.com/2013/01/01/the-nintend...

Or this one: https://gbdev.gg8.se/wiki/articles/CPU_Comparision_with_Z80

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.

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...

Ahaaa... I live and learn. About long dead CPUs.

It's more like a cut-down Z80. Some registers are missing (note the list excludes IX and IY), as are some instructions (but a few others are added) and even some of the status flags.

The official name of the CPU is unknown - there's some discussion of that here: https://forums.nesdev.com/viewtopic.php?f=20&t=18335

I guess you didn't know about the 8080 and how the Z80 is it's child?

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.

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.

The first emulator I wrote in JavaScript for a subset of x86 took a couple hours (maybe 4-6) over the weekend before I could run a `int main() { return 1 + 3; }` program. Like others have mentioned the GB takes longer before you get to the point of something you can see working.

Reply on news.ycombinator.com