Show HN: Game Bub – open-source FPGA retro emulation handheld

Thanks! Yeah, support for physical cartridges makes it a complete non-issue.

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.

Populated PCB in quantity 100 would probably be 60-70 USD, yeah. Maybe a bit less, it really depends on how much you can buy the FPGAs for.

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 agree, and wrote a rant about this as part of the post: https://eli.lipsitz.net/posts/introducing-gamebub/#a-brief-r...

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.

It deeds on the game and technology that you try to emulate. I wrote home-brew emulator software for the Nintendo DS. I could play Sega Genesis games without problems but some SNintendo games like StarFox game me literally headaches. Why? Because the SNES included special chips in the cartridge that were painful to emulate, badly documented and gave you screen flickering and stuff.

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.

Software emulations typically are not real-time, so that's one substantial difference.

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.

Consider that you can emulate an FPGA on a CPU, just much slower.

Mostly input latency since it does not incur all the layers of latency in the os plus the emulator.

Yep, that’s definitely a concern with hardware projects. I guess mass produced hardware doesn’t run into the problem as much because there’s funding for upfront bulk component purchases.

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.

We do, sort of. There are ASIC based clones of the NES, SNES, Genesis, GBA and GBC. Hyperkin for example sells a few, the SupaRetron HD is an ASIC based SNES clone, the MegaRetron HD is an ASIC based Genesis clone. Some Chinese companies have Game Boy Clones (e.g., GB Boy Colour). They aren't perfect because they aren't perfect 1:1 reverse engineered chips and nobody seems willing to spend the money to fix all the bugs, but they can be pretty close. The main benefit of the FPGA systems is that bugs can be fixed and they can do more than the real systems if need be like scan line emulation.

It's been done before. Lots of 90s bootleg consoles used clones of the Famicom/NES chips, though they weren't particularly accurate clones. The Commodore 64 Direct-To-TV of all things had a custom ASIC made for it in 2004.

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.

I imagine there's a huge difference, legally, with black-box reverse engineering and then creating a very similar design on an FPGA (what I did here), and actually fully decapping the chip and cloning the gates.

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.

As I understand it this has already been done for several systems. The first time I saw such a device it was one of those bootleg "100 Games In A Joystick" things that Ben Heck tore apart because it contained a glop-top "NES on a chip".

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

There's a Gameboy clone made by kongfeng that seems kind of like this, with its own chip. I'd love to know more about how they created it.

I believe NES patents might be finally all expired and off this year, but the SNES is probably covered for a little longer. Reverse engineering emulators and fpgas has been safer legally speaking for most of the last few decades.

Thanks! Slint has been great to work with :)

Great question!

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.

Thanks for the feedback! Do you mean have it be an entirely different color (e.g. blue), or dim the other inactive headers to make the active one stand out more?