Live data from Hacker News

Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go

github.com

1–10 of 34 posts

Re: Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go

#4
post #3

How would someone begin to work on something like this?

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

Re: Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go

#5
post #4
post #3

How would someone begin to work on something like this?

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

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

Re: Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go

#6
post #4

Earlier quoted context omitted.

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

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

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

Re: Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go

#7
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!

Re: Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go

#8

Earlier quoted context omitted.

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

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

Took me a minute to realise you were talking about 8080 emulation - not Atari emulation: https://github.com/superzazu/invaders

Re: Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go

#9
post #4

Earlier quoted context omitted.

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

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

The main advantage to NES emulation is that it's a very mature area of study. High-quality documentation is much more readily available than for other systems, and there's more public discussion of the specific problems that NES emulator authors encounter (both primarily on nesdev.com [1] [2]). There's even a sort of tool-assisted speedrun of writing an accurate NES emulator, if you're into that sort of thing [3] [4].

[1] https://wiki.nesdev.com

[2] https://forums.nesdev.com/viewforum.php?f=3

[3] https://www.youtube.com/watch?v=y71lli8MS8s

[4] https://www.youtube.com/watch?v=XZWw745wPXY

Re: Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go

#10
post #7

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!

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

Post reply on HN