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 :).
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?
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.
Thank you for the nice project and write-up! I love stuff like this!
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.
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.
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"
What is the total cost for a pcb populated with components? Probably around 60-70 qty 100?
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.
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.
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 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?
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.
Am I correct in thinking that FPGAs have an advantage over software emulators when it comes to latency? In particular the latency from the host operating system before input has even been received by the software emulator? I.e. FPGAs don't have a host OS and will have the same latency as original hardware?
This is very much a genuine question, I just want to know if my intuition about this is right or wrong.
FPGAs not only have no host OS, but they are actual hardware. The only thing you program are lookup tables which then represent logic gates/multiplexers which only have the normal hardware latency. There is literally no software involved in execution.
That's why you can build "any" hardware with them. Even CPUs which then execute your desired software
Yeah, that's another advantage. Theoretically you can get down to <1 frame of input latency with an FPGA. I haven't found the latency on a software GBA emulator running on a computer to be noticeable, but some people might find this to be another advantage.
I think with a dedicated emulation handheld (non-FPGA), you could probably pull some tricks to bring down the latency though.
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.
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?
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.
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.
"mass produced hardware doesn’t run into the problem"
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
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.
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.
There technically is also a path from FPGA to ASIC so you could use a FPGA for dev and test and at some point if it makes sense make a volume product based on that FPGA.
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.
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.
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?
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?
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.
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.
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.
Good question, I didn't talk about this in the writeup.
It's because I think that this design is the most efficient use of space, if you want to ensure that Game Boy cartridges don't stick out (like they do on the GBA). The device is divided into a front half and a back half, with the PCB in the middle. The screen and buttons are all in the front half, and the cartridge and battery are in the back half. If the device were landscape, you'd have the cartridge take up the entire middle space in the back half, leaving smaller spaces to the left and right (under the Dpad and face buttons) for the battery. So you'd either need to use two smaller batteries (and deal with that), or use a single battery (and have worse battery life and an empty space).
It's definitely possible, this just seemed like the simpler way forward. I probably would actually personally prefer a landscape orientation. Maybe in a future version!
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.
Like most things that tempt us with nostalgia and “the cool factor”, many of these likely end up on a shelf or drawer. Still, there are tons of folks buying collector’s editions of new games, etc. The market is there. I personally just own one such handheld and it gets used by the kids once in a while.
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.
I would love to see this done with the Super Nintendo.
I've never paid that much attention to retro hardware - I still have a lot of the originals in my parents' garage.
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.)
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.
However, I made some modifications to the theme for the first time recently, and learned that I absolutely hate Hugo's templating language. I might switch away at some point in the future (perhaps to https://github.com/getzola/zola -- the templating is Jinja2-esque).
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.
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.
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.
This main distinguishing feature of this project is that it supports physical cartridges, whereas MiSTer and almost every other emulation handheld doesn’t.
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 :)
>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.
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 :).
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?
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.
Thank you for the nice project and write-up! I love stuff like this!
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.
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.
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"
What is the total cost for a pcb populated with components? Probably around 60-70 qty 100?
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.
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.
jlcpcb part number C42415655
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?
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.
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.
Am I correct in thinking that FPGAs have an advantage over software emulators when it comes to latency? In particular the latency from the host operating system before input has even been received by the software emulator? I.e. FPGAs don't have a host OS and will have the same latency as original hardware?
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!
FPGAs not only have no host OS, but they are actual hardware. The only thing you program are lookup tables which then represent logic gates/multiplexers which only have the normal hardware latency. There is literally no software involved in execution.
That's why you can build "any" hardware with them. Even CPUs which then execute your desired software
Yeah, that's another advantage. Theoretically you can get down to <1 frame of input latency with an FPGA. I haven't found the latency on a software GBA emulator running on a computer to be noticeable, but some people might find this to be another advantage.
I think with a dedicated emulation handheld (non-FPGA), you could probably pull some tricks to bring down the latency though.
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.
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?
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.
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.
"mass produced hardware doesn’t run into the problem"
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
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.
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.
There technically is also a path from FPGA to ASIC so you could use a FPGA for dev and test and at some point if it makes sense make a volume product based on that FPGA.
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.
Patents last 20 years:
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.
Awesome project! Really cool to see that the UI is built with Rust and Slint, the GUI framework I’m working on. https://github.com/slint-ui/slint
Thanks! Slint has been great to work with :)
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?
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.
Damn what a great post, I hope to have similar skills one day (specifically about designing my own PCB and working with FPGAs)
Anyway feedback for the site, I think it could help if the active tab on the index is colored vs. bold
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?
Yeah a different color so it immediately sticks out it could even be grey/dark.
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.
Great work. Thanks a lot for sharing.
Designing your own boards and writing the emulator is super impressive! I like the clear case too! :)
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_...
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.
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.
Good question, I didn't talk about this in the writeup.
It's because I think that this design is the most efficient use of space, if you want to ensure that Game Boy cartridges don't stick out (like they do on the GBA). The device is divided into a front half and a back half, with the PCB in the middle. The screen and buttons are all in the front half, and the cartridge and battery are in the back half. If the device were landscape, you'd have the cartridge take up the entire middle space in the back half, leaving smaller spaces to the left and right (under the Dpad and face buttons) for the battery. So you'd either need to use two smaller batteries (and deal with that), or use a single battery (and have worse battery life and an empty space).
It's definitely possible, this just seemed like the simpler way forward. I probably would actually personally prefer a landscape orientation. Maybe in a future version!
Great, an open (and better!) alternative to FPGBC, which FPGA is locked to encrypted and signed configurations.
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.
Retro history will remember you and your splendid journey.
How many retro emulation handheld do we really need? Are there people out there seriously playing retro games for many hours at a time?
Like most things that tempt us with nostalgia and “the cool factor”, many of these likely end up on a shelf or drawer. Still, there are tons of folks buying collector’s editions of new games, etc. The market is there. I personally just own one such handheld and it gets used by the kids once in a while.
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.
I would love to see this done with the Super Nintendo.
You're literally describing a product and a company that already exists (Analogue Super Nt: https://en.wikipedia.org/wiki/Super_Nt)
I've never paid that much attention to retro hardware - I still have a lot of the originals in my parents' garage.
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.)
You can get better video output from the Wii than RCA. It won't be 4K but it will be much sharper:
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.
Thanks for the tip!
This is an open source analogue pocket.
Very cool project, and a fantastic write-up! The timelapse videos of the PCB layouts are particularly brilliant.
Apologies for the tangent, but may I ask what you use to write your blog? I love how clean it is.
Thanks, it's generated with Hugo using the https://github.com/adityatelange/hugo-PaperMod theme.
However, I made some modifications to the theme for the first time recently, and learned that I absolutely hate Hugo's templating language. I might switch away at some point in the future (perhaps to https://github.com/getzola/zola -- the templating is Jinja2-esque).
This is a very nice project and write-up. I think it's a perfect case for Show HN.
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.
That's actually a huge difference.
[dead]
[dead]
Can you do one for Game Gear?
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.
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.
This main distinguishing feature of this project is that it supports physical cartridges, whereas MiSTer and almost every other emulation handheld doesn’t.
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 :)
Funny you should mention SNES carts...the only way I can use a Super Game Boy portably is with a Supaboy, which looks very silly :D
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.
>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.
this is very impressive. all i say is you might port some of the Mister cores as well, if only for Roms support.
Portable FPGA retro console would be great.