Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go(github.com)
github.com
Goboy: Multi-Platform Nintendo Game Boy Color Emulator Written in Go
https://github.com/Humpheh/goboy
33 comments
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/
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!
> 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!
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!
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?
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...
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...
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-...
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!
Thanks for the correction!
One way is to keep track of the emulated CPU clock cycle count, and each emulated instruction adds to this count. In each host system frame, run the emulation for the number of cycles the 'real' emulated system would be able to run in that time.
The number of cycles per instructions can be either looked up from a table, hardwired into the emulation code, or if your emulated CPU is working on a "sub-instruction" granularity, the cycles per instructions "fall into place" automatically.
For instance if your host system's frame duration is 16.6ms (for a 60Hz framerate) and your emulated CPU needs to run at 1 MHz you compute the number of clock cycles as (1000000 / 60), that's about 16k cycles per second. Run the system emulation until the accumulated cycle count is >= that number each frame, and if you're emulation is fast enough you still have plenty of time left in the host system frame to render the emulator's video output, audio and an UI on top.
The number of cycles per instructions can be either looked up from a table, hardwired into the emulation code, or if your emulated CPU is working on a "sub-instruction" granularity, the cycles per instructions "fall into place" automatically.
For instance if your host system's frame duration is 16.6ms (for a 60Hz framerate) and your emulated CPU needs to run at 1 MHz you compute the number of clock cycles as (1000000 / 60), that's about 16k cycles per second. Run the system emulation until the accumulated cycle count is >= that number each frame, and if you're emulation is fast enough you still have plenty of time left in the host system frame to render the emulator's video output, audio and an UI on top.
https://www.reddit.com/r/emudev/ is a helpful resource.
Most people suggest working on a "toy" system, such as Chip-8 first. It is a mythical processor, rather than based upon real hardware. That said there are only a handful of opcodes to implement, and it does support graphics.
https://en.wikipedia.org/wiki/CHIP-8
There are ROMs out there for pong / space-invaders / etc, so you can play real games pretty quickly.
Of course there is nothing stopping you jumping straight into NES/GB/whatever. NES is easy to get started with, the others less so because of bank-switching, etc. But if you're patient you can manage it :)
Most people suggest working on a "toy" system, such as Chip-8 first. It is a mythical processor, rather than based upon real hardware. That said there are only a handful of opcodes to implement, and it does support graphics.
https://en.wikipedia.org/wiki/CHIP-8
There are ROMs out there for pong / space-invaders / etc, so you can play real games pretty quickly.
Of course there is nothing stopping you jumping straight into NES/GB/whatever. NES is easy to get started with, the others less so because of bank-switching, etc. But if you're patient you can manage it :)
There are some fantastic resources out there which detail basically every part of the GameBoy from processor to graphics.
For me the GB was a great entry point in learning about emulators as is is fairly simple compared with some other consoles. Even if you're not going to make an emulator some of them are still great reads - I've put a few resources I used on the GoBoy page: https://github.com/Humpheh/goboy#resources
For me the GB was a great entry point in learning about emulators as is is fairly simple compared with some other consoles. Even if you're not going to make an emulator some of them are still great reads - I've put a few resources I used on the GoBoy page: https://github.com/Humpheh/goboy#resources
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
At least the CPU is completely done.
I'll lurk his code :D
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.
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.
It’s the drawing bit that I don’t have much experience of haha
currently following this https://cs108.epfl.ch/archive/18/p/00_introduction.html but it is in French
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)
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)
Well done!
Everybody who's interested in multiple platform emulation with a nice UI should check OpenEmu: https://openemu.org/
Everybody who's interested in multiple platform emulation with a nice UI should check OpenEmu: https://openemu.org/
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?
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
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?
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
[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
Gameboy is actually a bit friendlier than the NES to get started with, because of the low number of mappers (programmable chips in the cartridges to do tricks with addressing, NES had much greater need for these than the GB due to the dearth of tile RAM). But Sega Master System is even friendlier, I hear.
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
How did you reach that conclusion?
http://emulator101.com/ is a good resource, as is https://www.reddit.com/r/emudev/.
Or you can just cheat, design a "toy" instruction set, and write something to process it. A couple of years ago I did that, in C/Perl:
* https://github.com/skx/simple.vm
Later I rewrote the interpreter/emulator in go:
* https://github.com/skx/go.vm
The downside with my approach here is that I ignored graphcs, sound, & I/O.
These days I'd recommend you write an emulator for the Chip-8 system..
Or you can just cheat, design a "toy" instruction set, and write something to process it. A couple of years ago I did that, in C/Perl:
* https://github.com/skx/simple.vm
Later I rewrote the interpreter/emulator in go:
* https://github.com/skx/go.vm
The downside with my approach here is that I ignored graphcs, sound, & I/O.
These days I'd recommend you write an emulator for the Chip-8 system..
I like that the language is a part of the name.
Love the name!
prevedmedved(1)