
Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go - mrahbar
https://github.com/Humpheh/goboy
======
giovannibajo1
For something more complex, I have written a mostly working Nintendo DS
emulator in Go, with JIT, 3D graphics, and whatnot:
[https://github.com/rasky/ndsemu/](https://github.com/rasky/ndsemu/)

------
lostgame
I’ve often thought of writing my own emulator for the NES or GB/GBC to learn a
little about how emulation works on a more fundamental level.

I understand a lot of it is the process of translating machine code from, say,
the GB processor to x86, but I’d love to learn more!

~~~
akdas
> I understand a lot of it is the process of translating machine code from,
> say, the GB processor to x86, but I’d love to learn more!

You don't really need to translate to x86 per se. You can start off with an
interpreter that takes in the 6502 or Z80 instructions (as represented by the
binary data in the input ROM), then immediately perform operations based on
those instructions. For example, if you're holding onto an in-memory
representation of the GB registers, and you encounter an "add" instruction,
you would perform the addition and update the registers.

And if you're writing the emulator in a high-level language, you never really
think about x86 instructions.

The hard part, then, is timing. You need to make sure the different operations
that would be happening in hardware--namely performing the CPU instructions,
alongside audio and video operations that would normally happen "in the
background"\--happen in sync. But that's a later step after you start on your
first prototype!

~~~
CobrastanJorji
I have a question there. CPU instructions and what they do are highly
documented and easy to replicate, but I'm guessing that timing is
significantly less slo. How do you get that right?

~~~
akdas
Timings are usually documented as well, usually at the clock cycle level.

Beyond that, you have to worry about hardware peculiarities that happen to
affect maybe a few games, and at that point, you might start reverse
engineering the behavior of those games!

Take a look at this article talking about exactly those thinking issues:
[https://www.tested.com/tech/gaming/2712-why-perfect-
hardware...](https://www.tested.com/tech/gaming/2712-why-perfect-hardware-
snes-emulation-requires-a-3ghz-cpu/)

~~~
Narishma
Why not link to the original article?

[https://arstechnica.com/gaming/2011/08/accuracy-takes-
power-...](https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-
mans-3ghz-quest-to-build-a-perfect-snes-emulator/)

~~~
akdas
Oops! I searched for the article, then picked one of the results. I didn't
realize the one I linked wasn't the original because I only looked through it
enough to make sure the right content was present.

Thanks for the correction!

------
wareotie
I feel envy. I'm writing an NES emulator with a friend and it's taking so
long... The gui is stealing my sanity.

At least the CPU is completely done.

I'll lurk his code :D

------
verletx64
As somebody not versed at all in the front end part of an emulator, what’s a
good resource for learning how to put together something that will actually
render frames? No preference on technologies here.

~~~
Double_a_92
Emulating the frame is also just part of the emulator. I.e. you got the
display memory in some array (of pixel colors) in your code and the emulated
instructions modify it. Then you just have to draw whatever is in that array
on a "canvas" that your programming language supports.

~~~
verletx64
It’s the drawing bit that I don’t have much experience of haha

------
minimaul
Nice!

As someone who also wrote a GB emulator as a learning exercise, I found the
sound code to be the worst part by far to write - getting sound timing right
etc is very difficult (as the GB sound output changes instantly - it has no
buffers etc)

------
subbz
Well done!

Everybody who's interested in multiple platform emulation with a nice UI
should check OpenEmu: [https://openemu.org/](https://openemu.org/)

------
jchw
Cool! I also wrote a Gameboy emulator in Go, but I never got to supporting
audio or GBC. I wonder how much harder it is to do Gameboy Color once you've
got decent Gameboy DMG emulation?

~~~
humpheh
There aren't actually too many differences between GBC and DMG emulation as
most of the hardware was consistent between them. The main change is around
the PPU and the memory, as the GBC added some internal memory banks which are
used for tile attributes and colour palettes etc. The actual changes around
the graphics rendering aren't very significant other than some conditionals
for GBC mode - you can see them here where `isGBC` is used:
[https://github.com/Humpheh/goboy/blob/master/pkg/gb/ppu.go](https://github.com/Humpheh/goboy/blob/master/pkg/gb/ppu.go)

------
gf263
How would someone begin to work on something like this?

~~~
jchw
My recommendation is to start with the CPU emulation. The CPU in the Gameboy
has decent documentation and there are plenty of implementations to look at if
you're stumped. (One I like particular is the core in Higan, a multisystem
emulator written in C++.)

~~~
voltagex_
I remember seeing some people recommend starting with the NES rather than the
Gameboy - any ideas on this?

~~~
notafraudster
Start with Chip-8 or Space Invaders, both of which are substantially easier
than the NES and Gameboy.

~~~
voltagex_
Took me a minute to realise you were talking about 8080 emulation - not Atari
emulation:
[https://github.com/superzazu/invaders](https://github.com/superzazu/invaders)

~~~
jacobush
How did you reach that conclusion?

------
parski
I like that the language is a part of the name.

------
igotsideas
Love the name!

