Usually when writing emulation software for a system like the Game Boy, one makes sure to take as many shortcuts as possible in order to reduce the resources required for the emulation. This has however the unfortunate side-effect that it reduces the overall accuracy of the emulation and with it the compatibility with games on the system.
This is the basic reasoning behind projects which seek to abandon simplistic abstractions in favor of cycle-accurate, full compatibility approaches, of which MetroBoy is probably the most extreme one. Instead of abstracting away the hardware, it instead does the emulation at the circuit level. As with such other projects, this means that the emulator requires a lot more CPU cycles to get things just right. On the bright side, one can likely still run this emulator on any modern system.
As the MetroBoy author explains, he implemented code in C++ which allowed him to construct circuits in an HDL-style manner, which should theoretically also allow him to generate a Verilog (or VHDL) softcore out of the project. As a demonstration of implementing HDL in C++ it’s decidedly interesting.
An approach like this is pretty much the exact opposite of a project like the UltraHLE (ultra high-level emulator) Nintendo 64 emulator, which used the knowledge that Nintendo 64 games are written in C as a first step to creating libraries that the code in the Nintendo 64 ROMs would call instead of the native (Nintendo) libraries. This allowed N64 games to directly run on the target system, with the graphic and system calls translated by UltraHLE into native OS calls, using the 3dfx Glide API for accelerated graphics.
While an approach like UltraHLE took allows for the most minimal use of system resources by essentially foregoing emulation completely, for retro systems like the Game Boy where games were implemented in assembly on bare hardware, using this circuit-level emulation ensures that one gets the most accurate match with the original handheld console experience.
As a word of caution to those who are now itching to try out MetroBoy, its Github site notes that it currently lacks support for game saves, uses a mixture of original Game Boy (DMG) and Game Boy Advance SP (AGS) hardware that confuses some games and has rather buggy sound support.
If playing around with software-defined Game Boy circuits isn’t enough and would like to literally look inside a real Game Boy, the X-ray image from the top of the article is something Chris over at Elektronaut pulled off several years ago.
With stuff like this, I keep wondering if parts of the emulator could be offloaded to something like a MKR Vidor 4000 or other FPGA platform aimed at the maker space.
I don’t know enough about this space to say if this is a dumb idea or not.
It’s a good idea, and cycle-accurate FPGA recreations of video game consoles are becoming the new hotness in retro gaming circles. Check out Mister: https://github.com/MiSTer-devel/Main_MiSTer
I’m vaguely aware of full FPGA based EMUs. but I don’t know if anyone is considering a hybrid approach where parts of the machine are offloaded onto an FPGA. It might connect via Ethernet or USB to the host depending on the bandwidth and timing constraints.
If all that is workable, then I wonder if some of these relatively cheap FPGA platforms have enough power to really boost performance and/or accuracy on something like a RasPi. Maybe it would allow for more modern consoles to be emulated on these lower power platforms. I don’t have the time, skill set, or background to explore this though :(
MetroBoy author here, just noticed someone posted this to HaD. :D
Apparently I broke a few things in the last round of timing fixes, so compatibility isn’t quite where it should be but that will be fixed shortly.
Lemme know if you’ve got questions.
Odd, I thought this post didn’t go through so I wrote a second one. :/
Hi, I’m the MetroBoy author. Compatibility is slightly broken at the moment as I ended up with a mishmash of DMG (original Game Boy) and AGS (Game Boy Advance SP) timings in the published version.
Happy to answer questions. :)
So I’m curious, if it’s written to be translated into Verilog, why did you not write it in Verilog to begin with?
Testing Verilog designs is a huge pain, and the compile-run-debug cycle can be hours long. By writing and debugging a circuit in C and then translating it to Verilog, you can leverage your C skills and tools and still have something you know will synthesize in the end.
Also, running the C code directly is potentially thousands of times faster than running Verilog in a simulator.
In the github page you talk about another project, Metron, could you post the github for that as well? I worked on something similar a few years ago and could help share some experience
The Metron codebase is a disaster area and can only translate portions of Metroboy (the SPU, parts of the CPU/GPU). I’ll release it when it can translate the whole thing.
I read that you are finding back all “instruction” by writing a whole brunch of test case and measuring back signals.
Will you post your newly found model?
Are you using some Discord or other to talk to emulator programmers and share your common knowledge or are you doing it “lone wolve”?
Also, did the work on “Verilogboy” (https://hackaday.io/project/57660-verilogboy-gameboy-on-fpga#menu-description) help you?
Sorry, lot of questions here.
The MetroBoy codebase _is_ the newly found model. The PPU in particular is much closer to reality than most of the emulators out there.
I just discovered a Gameboy discord channel and am there now. :)
I looked at a couple Verilog gameboys, but the coding style is… difficult to follow.