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.
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.
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.
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 :)
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.
Can’t find an official announcement or datasheet yet, but according to this post:
* 2x Cortex-M33F
* improved DMA
* more and improved PIO
* external PSRAM support
* variants with internal flash (2MB) and 80 pins (!)
* 512KiB ram (double)
* some RISC-V cores? Low power maybe?
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).