Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 34 posts

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

#21

Post by humpheh »

jchw wrote: post #2

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

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

#23

Post by Double_a_92 »

verletx64 wrote: post #18

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.

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

#24

Post by jacobush »

voltagex_ wrote: post #8
notafraudster wrote: post #6

Earlier quoted context omitted.

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?

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

#27

Post by 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)

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

#28

Post by staz »

verletx64 wrote: post #18

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.

currently following this https://cs108.epfl.ch/archive/18/p/00_introduction.html but it is in French

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

#29

Post by verletx64 »

Double_a_92 wrote: post #23
verletx64 wrote: post #18

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

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

#30

Post by flohofwoe »

CobrastanJorji wrote: post #12
akdas wrote: post #10

Earlier quoted context omitted.

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

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?

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.

Post reply on HN