Show HN: Game Bub – open-source FPGA retro emulation handheld (eli.lipsitz.net)
Over the past ~1.5 years, I built an open-source FPGA retro emulation handheld that can play Game Boy, Game Boy Color, and Game Boy Advance cartridges. To my knowledge, there isn't an existing open-source FPGA emulator that can play physical cartridges like this.
One of my main goals was to do all of the pieces myself, and be able to understand every component of it, so I designed my own PCB, wrote the firmware, wrote a Game Boy and Game Boy Advance emulator for the FPGA (using the Chisel HDL), and designed a 3D-printed case.
I detailed the design and development process in the linked post. It's quite long, but there are a lot of pictures and videos.
Code and design files available on GitHub: https://github.com/elipsitz/gamebub, and an overview of the architecture: https://github.com/elipsitz/gamebub/blob/handheld/docs/archi...
69 comments
[ 2.7 ms ] story [ 139 ms ] threadI would love to see this done with the Super Nintendo.
I just moved, which gave me an opportunity to give all the old Rock Band instruments that were too loud for my last apartment a fresh try. It's disappointing how bad RCA-era systems like the Wii looks on a 4K OLED. The upscaling is blurry as shit.
I've been trying to get all my songs imported into YARG (an open source Rock Band clone), but if I can't get that working, maybe I should get a scanline generator. (It applies a filter to the video to replicate the look of a CRT.)
https://electron-shepherd.com/products/electronwarp
There was also an official component cable which would look much nicer than the composite that the Wii comes with. But your 4K tv almost definitely don't have component input.
I suppose one solution is that the maintainers could update their component list (which might involve more than one component because of compatibility issues?). But what if I'm in the middle of purchasing the components only to discover I can't get them all? Maybe the maintainers could sell component kits? That might be a nice way to fund their work. Not sure if that would run into issues with IP laws, though.
At least with open source hardware you could theoretically modify the hardware to use an alternative component, even if it’s no longer commercially viable.
For a lot of open source projects you can pretty much just source everything from DigiKey or Mouser, so you can buy them all atomically.
Happens all the time, as a production model may take a long time to make it through development and lab certification.
In general, large firms will try to warehouse spools for some bespoke design, but the 3 year contact-oxidation garbage-clock starts the second the component spool/tray leaves the manufacturer.
Thus, one may try to mitigate supply chain instability, but in the end you are still just better off avoiding unicorn parts in your work to begin with... Longer chip lot runs with multiple suppliers having identical packages is usually safer. YMMV =3
And any cheap Chinese retro-console of the same sort support even more of them. So from a practical standpoint I don't see any advantage of this (no doubt cool) project.
The FPGA cores here are written from scratch by me with hardware support in mind, and it’s quite a bit of work! Plus, SNES cartridges don’t exactly fit in a handheld :)
Surely, you've heard of the Supaboy.
I jest, this project looks great! After looking over the build instructions, it seems like this might be a good reason to finally make an account with JLCPCB.
Portable FPGA retro console would be great.
I realize you don't have the resolution needed for such a thing on your project, but it would be interesting to see a full SGB setup via FPGA.
It's a good week for homebrew handhelds. Someone posted a cool one on reddit yesterday built with a Raspberry Pi:
https://old.reddit.com/r/Handhelds/comments/1in0svx/my_pi_5_...
https://en.wikipedia.org/wiki/Term_of_patent
The SNES came out in 1990:
https://en.wikipedia.org/wiki/Super_Nintendo_Entertainment_S...
Every patent on the original SNES should have expired by 2010.
Plus FPGAs add a lot of flexibility (e.g. multiple systems, enhancements), and they're really not that expensive. Especially in relatively low volumes compared to an ASIC.
I think these days FPGAs have just gotten cheap enough that the economics of making custom chips doesn't make much sense for the volumes these kinds of products tend to sell.
> FPGAs are pretty expensive I imagine compared to some 40 year old cpu design and 1kb of ram.
The MiSTER Pi set me back $180 and is perhaps my favorite purchase of 2024. It'll run almost any system made before the year 2000 and the gap is rapidly closing for lesser-appreciated consoles like the Saturn and Jaguar. This represents a tremendous value; it's hard to argue with that kind of money for an entire century of gaming. I heartily recommend picking one up.
I appreciate the blog post and the writeup, it might be nice to include it in the repo.
I have been toying with a similar design, with many of the same choices. Although for the system controller pair, I'd go with RP2350B and ESP32-C61 (I think). It would be nice if there was an optional chip and pad layout to support legacy or classic BT.
Another option would be to have a USB port and support something like https://www.8bitdo.com/usb-wireless-adapter-2/ to enable legacy controllers.
It looks like supporting legacy BT while noble, could be a project killing sidequest (if you didn't already have it done!) Another out, would be exposing an SPI connection internally so someone could hack in a controller of their choice.
I really did want to switch to the RP2350B, but it's (still) not available to buy. There's also the (unreleased) Raspberry Pi RM2 module which would help with Bluetooth Classic and LE support.
On Game Bub, I do expose a Pmod interface (4 data wires) connected to the FPGA, so that actually is an option here too.
I know how they're different, I understand the mechanics of it, I just don't understand why it's not possible to make a software emulation that is as good as FPGA emulation. Or maybe it is possible. I always felt like doing it in software would be a lot more flexible.
IMO: the only real advantage is that it allows you to meet the precise timing needed to interface with physical hardware, like cartridges and other consoles (with link cables).
I think they're also really fun to write, because you think more like a hardware designer than a software engineer.
This is very much a genuine question, I just want to know if my intuition about this is right or wrong.
Your project looks amazing btw!
I think with a dedicated emulation handheld (non-FPGA), you could probably pull some tricks to bring down the latency though.
That's why you can build "any" hardware with them. Even CPUs which then execute your desired software
Those consoles are so old now that you could emulate them with anything, a Chinese chip that cost dollars will do. But you will be extremely wasteful, consuming tens or hundreds of times more energy(less battery time) for a worse result.
Software is way more flexible. Everything is prototyped first in software. In the past there were machines that consumed a hundredth of a watt of energy. Emulating them using 20Watts is so wasteful.
With software you had only one thing that needs to do totally different things. With hardware you can choreograph a chip working in parallel among others in an independent way.
For instance when you press a button, it will take few ms to register with software emulation, whereas on FPGA it should be very much instantaneous.
Anyway feedback for the site, I think it could help if the active tab on the index is colored vs. bold
In the absolute worst case (drawing an object at the very top of the screen, and the LCD output for the next frame started right before the current one finished), buffering adds a 2 frame delay (33 milliseconds). Probably noticeable for some people, but this worst case is uncommon.
Average case I would expect ~0.5 to 1 frame delay, so 8 to 16 milliseconds. Probably not really noticeable.
I visited the comments earlier and was discouraged to find that most of them were of the flavor of, "why does this exist?" From people who have obviously never attempted 1% of an audacious project like this. It exists because it's cool sure looked to be a fun cross-domain learning experience, like what else do you need?
BTW, I have submitted to Hack-A-Day's tip line so don't be surprised in there's an article there about it in a few days.
I also run into the power domain issue a lot. I didn't see a graphic about it in the article but essentially in the majority of devices the IO is like this:
Vdd
|
Esd diode
|
I/O pin
|
Esd diode
|
Ground
Where the diodes are pointing towards. That way if the line goes too negative the lower one will conduct and clamp it to a diode drop + ground, same as if it goes too high to a diode drop + Vdd. The problem is if Vdd has a low impedance path to ground. This is common with power supply ICs either with output discharge resistors or transistors allowing current through to ground. When that happens, your io pin now has a diode in parallel to ground. If you're not careful and don't have current limiting resistors in the way I2C does (because it needs the pull ups), suddenly you're putting the max current your driver can deliver through that diode. Doesn't take much for the smoke to escape.
Some IO pins are designed to be fine without VDD. You can usually check the absolute max ratings for someone like "VDD + 0.3" vs "3.6"
There's also the Chromatic, but that one is not made to be cost effective.
One cool advantage of real cartridge compatibility I hadn't really thought about is that lets you not have to think about memory mappers (I'm mostly familiar with NES's dozens of different mappers, not sure if GB carts work the same way) and other custom cartridge hardware since you're just "emulating" up to the cartridge boundary. I guess this means even crazier hardware like the camera/rumble/sewing machine would "just work" with an original cartridge without any special support right?
I guess that doesn't save too much for this though if it supports loading ROMs. For that do you still end up having to emulate all the different mappers in the FPGA?
Mappers are a huge problem with the NES, but a much smaller problem with the Game Boy. There are only a few official ones (6 iirc), and one or two unofficial ones. And unlike the NES, the ROM includes a cartridge header that tells you which mapped chip is used.
For the GBA, there aren’t any mappers (except for one or two GBA video cartridges). There’s some extra hardware (like rumble or gyroscope), but not a whole lot. So yeah, I have to emulate all of those but it’s not much of a problem.
Retro history will remember you and your splendid journey.
Great work. Thanks a lot for sharing.
That's actually a huge difference.