Hey HN,<p>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.<p>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.<p>I detailed the design and development process in the linked post. It's quite long, but there are a lot of pictures and videos.<p>Code and design files available on GitHub: <a href="https://github.com/elipsitz/gamebub">https://github.com/elipsitz/gamebub</a>, and an overview of the architecture: <a href="https://github.com/elipsitz/gamebub/blob/handheld/docs/architecture.md">https://github.com/elipsitz/gamebub/blob/handheld/docs/archi...</a>
This is really cool, thanks for the writeup. Love how thorough you were, one of my first thoughts was whether you could hook it up to a gamecube and it was already done in the blog post :).<p>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?<p>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?
Thank you for the nice project and write-up! I love stuff like this!<p>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?<p>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.
Sadly that display controller MISO thing is notorious. I first ran into it a few years ago. The recommendation was to use a tristate buffer on the chip select line or, as you did, separate the buses.<p>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:<p>Vdd<p>|<p>Esd diode<p>|<p>I/O pin<p>|<p>Esd diode<p>|<p>Ground<p>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.<p>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"
What is the total cost for a pcb populated with components? Probably around 60-70 qty 100?<p>I appreciate the blog post and the writeup, it might be nice to include it in the repo.<p>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.<p>Another option would be to have a USB port and support something like <a href="https://www.8bitdo.com/usb-wireless-adapter-2/" rel="nofollow">https://www.8bitdo.com/usb-wireless-adapter-2/</a> to enable legacy controllers.<p>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 have an Analogue Pocket, which works really well, but the fact that it uses an FPGA is essentially meaningless to me. Is there really any significant difference compared to software emulation?<p>I know <i>how</i> 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.
I love the idea of open source hardware, but one issue I struggle with is - what happens when one or more components go out of production?<p>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.
I don't really know if this is a stupid idea or not, I don't really have hardware experience. But the older systems, say NES, SNES, Genesis etc are pretty simple systems. Patents also have a lifetime. Why aren't we getting recreations of the hardware via a SOC sold that near-perfectly emulates the system? The FPGA projects are as close as I see this happening, but FPGAs are pretty expensive I imagine compared to some 40 year old cpu design and 1kb of ram.
Awesome project! Really cool to see that the UI is built with Rust and Slint, the GUI framework I’m working on. <a href="https://github.com/slint-ui/slint">https://github.com/slint-ui/slint</a>
Fantastic project and great writeup! The screen tradeoff with needing triple buffering but getting integer scaling was interesting to hear about - any feeling as to whether it adds human-noticeable latency vs. original hardware?
Damn what a great post, I hope to have similar skills one day (specifically about designing my own PCB and working with FPGAs)<p>Anyway feedback for the site, I think it could help if the active tab on the index is colored vs. bold
What a great writeup. I am always interested in these specifics of current design decisions even if I am so not into gaming handhelds. But the questions around display, enclosure, battery power and connectivity and the chose. borders between circuit and software are always current and shifting with time and goals. I love the Pico W integration, which is still one of rather undervalued development items of the last few years.<p>Great work. Thanks a lot for sharing.
Designing your own boards and writing the emulator is super impressive! I like the clear case too! :)<p>It's a good week for homebrew handhelds. Someone posted a cool one on reddit yesterday built with a Raspberry Pi:<p><a href="https://old.reddit.com/r/Handhelds/comments/1in0svx/my_pi_5_handheld_prototype_that_i_finished_with/" rel="nofollow">https://old.reddit.com/r/Handhelds/comments/1in0svx/my_pi_5_...</a>
You have not only created an open source Analogue Pocket, which is amazing, but you’ve also perfectly voiced the problems I have with the MiSTer project: that as cool as FPGA technology is, the MiSTer completely misses its sole advantages (which is better support for official hardware) due to a mix of limited I/O on dev boards (which is a fair point) and the community’s irrational hatred of cartridges as “unnecessary”. There is literally zero reason for the MiSTer to exist by their own logic, because why do you need a dedicated platform? That’s so unnecessary, just use a computer. Just as if not more accurate in most cases too.<p>Regardless, this article alone is like my holy grail of emulation and project design. And there’s more of them? I can’t wait.
This is fantastic! Perhaps I missed it but do you go over why you chose a portrait layout as opposed to a GBA-style landscape layout? With the existing equivalents in the FPGA space all being GBC style I'm curious if that's just a personal preference or if there was something that led you to select that layout.
Great, an open (and better!) alternative to FPGBC, which FPGA is locked to encrypted and signed configurations.<p>There's also the Chromatic, but that one is not made to be cost effective.
Very nice. I'm always happy to see new FPGA implementations of retro computing hardware. I've wanted to try Chisel, but have never gotten around to it.
I don't know what to say, epic man.
You alone, on your own, are on a par with the gods.<p>Retro history will remember you and your splendid journey.
If Nintendo wouldn't sue you for selling these, I'd say shut up and take my money. I do wonder if they'll definitely try to sue? Its really a shame, I never thought I'd see a project like this in my lifetime in all honesty. I would love to have something that lets me just keep playing my physical gameboy games indefinitely, so even if a truck crushes my gameboy, its nice knowing I can always print a new one.<p>I would love to see this done with the Super Nintendo.
Author missing one important point in their "A brief rant about FPGA retrogaming" rant. Sure FPGA systems are emulations, but key thing is that they typically are real-time systems, whereas software emulations typically are not.<p>That's actually a huge difference.
Why only GB/GBA? Mister FPGA support lot's of cores which can use the same Screen and controls: NES, SNES, various Sega consoles, C64, MSX etc.<p>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.