8 ms·

Writing a Game Boy Emulator in OCaml (2022)

257 points by ibobev 1y ago

deleted 1y ago
[deleted]
le-mark 1y ago
This is a very nice write up of not only Ocaml but also gameboy emulator implementation. Great job and thank you to the author! As an aside I’ve always thought it would be awesome to create a single page app with an assembler editor and assembler/linker/loader to enable doing gameboy homebrew in the browser. I think it would be a great, accessible embedded development teaching opportunity.
- binji 1y ago
  rgbds-live is more-or-less this same idea, with an embedded version of RGBDS: https://gbdev.io/rgbds-live/ https://gbdev.io/rgbds-live/
noobcoder 1y ago
ah nice ! great use of functors, GADTs I wanna compare a CHIP 8 or NES emulator or port CAMLBOY to WASM using ocaml-wasm
- hydroxideOH- 1y ago
  It should already be possible to run CAMLBOY on WASM because of the new WASM backend of js_of_ocaml (wasm_of_ocaml).
droolboy 1y ago
I know it’s a long shot, but does anyone know of a tutorial for the sound of a game boy emulator? Most of these tutorials never cover that piece and when I try it on my own I find it hard to properly implement or even understand the reference material well enough to implement on my own.
- jofzar 1y ago
  https://youtu.be/a52p6ji1WZs https://youtu.be/a52p6ji1WZs maybe?
- wez470 1y ago
  https://nightshade256.github.io/2021/03/27/gb-sound-emulation.html https://nightshade256.github.io/2021/03/27/gb-sound-emulatio... is pretty good
- t0mek 1y ago
  Not a tutorial per-se, but here are 2 slides describing how I've done it: https://www.slideshare.net/slideshow/emulating-game-boy-in-java/83928182#21 https://www.slideshare.net/slideshow/emulating-game-boy-in-j... Essentially, there are 4 channels, each providing a number 0-15 on every tick. Emulator should mix them together (arithmetic average), scale up to 0-255 and feed to the sound buffer, adjusting the tick rate (4.19MHz) to the sound output rate (e.g.: 22 kHz) - taking every ~190 value (4.19MHz / 22 kHz) is a good start. Now the 0..15 value that should be produced by each channel depends on its characteristics, but it's well documented: https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware Channels 1 and 2 produce square waves, so a bunch of low (0) and high (15) values, with optional volume envelope (gradually going down from 15 to 0 on the "high" part of the square) and frequency sweep (alternating 0s and 15s slower or faster). Channel 3 allows an arbitrary waveform, read from the memory. Channel 4 is a random noise, generated by the LSFR. See SoundModeX.java for the reference: https://github.com/trekawek/coffee-gb/tree/master/src/main/java/eu/rekawek/coffeegb/sound https://github.com/trekawek/coffee-gb/tree/master/src/main/j...
brunojppb 1y ago
Beautiful write-up! Thanks for sharing this. I want to write a game boy emulator in Rust and your blogpost really inspired me to kick this off. I’m bookmarking this.
mtlynch 1y ago
Excellent writeup and cool project. Needs a (2022).
numlock86 1y ago
Cool. The demo runs way too fast, though. The throttle checkbox doesn't really change it. Unchecking it, if anything, makes it run slower. It runs at 240 fps with throttle and at 180 fps without. With the throttle checbox active one second are already about four seconds in the emulator. I suspect this is related to the screen refresh rate, which is 240Hz in my case.
- chickenzzzzu 1y ago
  probably they are calling requestAnimationFrame() and then not accounting for deltaTime?
derefr 1y ago
Would anyone here assert that there's any particular programming language that's better for writing emulators, virtual machines, bytecode interpreters, etc? Where, when I say "better", I'm not so much talking about getting results that are particularly efficient/performant; nor in making fewer implementation errors... but more in terms of the experience of implementing an emulator in this particular language, being more rewarding, intuitive, and/or teaching you more about both emulators and the language. I ask because I know that this sort of language exists in other domains. Erlang, for example, is particularly rewarding to implement a "soft-realtime nine-nines-of-uptime distributed system" in. The language, its execution semantics, its runtime, and its core libraries, were all co-designed to address this particular problem domain. Using Erlang "for what it's for" can thus teach you a lot about distributed systems (due to the language/runtime/etc guiding your hand toward its own idiomatic answers to distributed-systems problems — which usually are "best practice" solutions in theory as well); and can lead you to a much-deeper understanding of Erlang (exploring all its corners, discovering all the places where the language designers considered the problems you'd be having and set you up for success) than you'd get by trying to use it to solve problems in some other domain. Is there a language like that... but where the "problem domain" that the language's designers were targeting, was "describing machines in code"?
- chickenzzzzu 1y ago
  C89
- johnnyjeans 1y ago
  sml, specifically the MLTon dialect. It's good for all the same reasons ocaml is good, it's just a much better version of the ML-language in my opinion. I think the only thing that ocaml has that I miss in sml is applicative functors, but in the end that just translates to slightly different module styles.
  - wk_end 1y ago
    Can you expand on what makes SML better, in your eyes, than OCaml? IMO: it's certainly "simpler" and "cleaner" (although it's been a while but IIRC the treatment of things like equality and arithmetic is hacky in its own way), which I think causes some people to prefer SML over aesthetics, but TBH I feel like many of OCaml's features missing in SML are quite useful. You mentioned applicative functors, but there's also things like labelled arguments, polymorphic variants, GADTs, even the much-maligned object system that have their place. Is there anything SML really brings to the table besides the omission of features like this?
deleted 1y ago
[deleted]

257 points by ibobev 1y ago

deleted 1y ago

[deleted]

This is a very nice write up of not only Ocaml but also gameboy emulator implementation. Great job and thank you to the author! As an aside I’ve always thought it would be awesome to create a single page app with an assembler editor and assembler/linker/loader to enable doing gameboy homebrew in the browser. I think it would be a great, accessible embedded development teaching opportunity.

binji 1y ago
rgbds-live is more-or-less this same idea, with an embedded version of RGBDS: https://gbdev.io/rgbds-live/ https://gbdev.io/rgbds-live/

noobcoder 1y ago

ah nice ! great use of functors, GADTs I wanna compare a CHIP 8 or NES emulator or port CAMLBOY to WASM using ocaml-wasm

hydroxideOH- 1y ago
It should already be possible to run CAMLBOY on WASM because of the new WASM backend of js_of_ocaml (wasm_of_ocaml).

droolboy 1y ago

I know it’s a long shot, but does anyone know of a tutorial for the sound of a game boy emulator? Most of these tutorials never cover that piece and when I try it on my own I find it hard to properly implement or even understand the reference material well enough to implement on my own.

jofzar 1y ago
https://youtu.be/a52p6ji1WZs https://youtu.be/a52p6ji1WZs maybe?
wez470 1y ago
https://nightshade256.github.io/2021/03/27/gb-sound-emulation.html https://nightshade256.github.io/2021/03/27/gb-sound-emulatio... is pretty good
t0mek 1y ago
Not a tutorial per-se, but here are 2 slides describing how I've done it: https://www.slideshare.net/slideshow/emulating-game-boy-in-java/83928182#21 https://www.slideshare.net/slideshow/emulating-game-boy-in-j... Essentially, there are 4 channels, each providing a number 0-15 on every tick. Emulator should mix them together (arithmetic average), scale up to 0-255 and feed to the sound buffer, adjusting the tick rate (4.19MHz) to the sound output rate (e.g.: 22 kHz) - taking every ~190 value (4.19MHz / 22 kHz) is a good start. Now the 0..15 value that should be produced by each channel depends on its characteristics, but it's well documented: https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware Channels 1 and 2 produce square waves, so a bunch of low (0) and high (15) values, with optional volume envelope (gradually going down from 15 to 0 on the "high" part of the square) and frequency sweep (alternating 0s and 15s slower or faster). Channel 3 allows an arbitrary waveform, read from the memory. Channel 4 is a random noise, generated by the LSFR. See SoundModeX.java for the reference: https://github.com/trekawek/coffee-gb/tree/master/src/main/java/eu/rekawek/coffeegb/sound https://github.com/trekawek/coffee-gb/tree/master/src/main/j...

brunojppb 1y ago

Beautiful write-up! Thanks for sharing this. I want to write a game boy emulator in Rust and your blogpost really inspired me to kick this off. I’m bookmarking this.

mtlynch 1y ago

Excellent writeup and cool project. Needs a (2022).

numlock86 1y ago

Cool. The demo runs way too fast, though. The throttle checkbox doesn't really change it. Unchecking it, if anything, makes it run slower. It runs at 240 fps with throttle and at 180 fps without. With the throttle checbox active one second are already about four seconds in the emulator. I suspect this is related to the screen refresh rate, which is 240Hz in my case.

chickenzzzzu 1y ago
probably they are calling requestAnimationFrame() and then not accounting for deltaTime?

derefr 1y ago

Would anyone here assert that there's any particular programming language that's better for writing emulators, virtual machines, bytecode interpreters, etc? Where, when I say "better", I'm not so much talking about getting results that are particularly efficient/performant; nor in making fewer implementation errors... but more in terms of the experience of implementing an emulator in this particular language, being more rewarding, intuitive, and/or teaching you more about both emulators and the language. I ask because I know that this sort of language exists in other domains. Erlang, for example, is particularly rewarding to implement a "soft-realtime nine-nines-of-uptime distributed system" in. The language, its execution semantics, its runtime, and its core libraries, were all co-designed to address this particular problem domain. Using Erlang "for what it's for" can thus teach you a lot about distributed systems (due to the language/runtime/etc guiding your hand toward its own idiomatic answers to distributed-systems problems — which usually are "best practice" solutions in theory as well); and can lead you to a much-deeper understanding of Erlang (exploring all its corners, discovering all the places where the language designers considered the problems you'd be having and set you up for success) than you'd get by trying to use it to solve problems in some other domain. Is there a language like that... but where the "problem domain" that the language's designers were targeting, was "describing machines in code"?

chickenzzzzu 1y ago
C89
johnnyjeans 1y ago
sml, specifically the MLTon dialect. It's good for all the same reasons ocaml is good, it's just a much better version of the ML-language in my opinion. I think the only thing that ocaml has that I miss in sml is applicative functors, but in the end that just translates to slightly different module styles.
- wk_end 1y ago
  Can you expand on what makes SML better, in your eyes, than OCaml? IMO: it's certainly "simpler" and "cleaner" (although it's been a while but IIRC the treatment of things like equality and arithmetic is hacky in its own way), which I think causes some people to prefer SML over aesthetics, but TBH I feel like many of OCaml's features missing in SML are quite useful. You mentioned applicative functors, but there's also things like labelled arguments, polymorphic variants, GADTs, even the much-maligned object system that have their place. Is there anything SML really brings to the table besides the omission of features like this?

deleted 1y ago

[deleted]