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).
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!
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.
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?
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.
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 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.
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.
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).