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?
I'm not saying that FPGAs aren't interesting, or don't have the possibility of allowing one to produce highly accurate emulators. I think that FPGA emulators are really cool -- I've written one! Check the website linked from my profile.
I'm taking issue with how Analogue markets their products. If they want to talk about the specific benefits their products have (like low latency, or video output, or original cartridges, or accuracy), great! But the claim that they're making is that their work involves "No Emulation". And through that, they're implying that FPGA based emulators are inherently better. And they're not. It's a different set of tradeoffs, and they certainly have the possibility to have certain advantages, but that's still all up to the quality of the implementation. Which is exactly the way that software emulators work too.
Yeah, I guess it's mostly just wordsmithing. But I don't think it's pedantry: by making the claim that their hardware isn't emulation, it implies that it's somehow better than software emulators. There's just an entirely different set of tradeoffs here, and FPGA emulators are not inherently more accurate than software emulators.
The issue I have is that they’re implying it’s inherently better than software emulation, perhaps because it more accurately reproduces the behavior. But an FPGA emulator isn’t necessarily any more accurate.
I think it’s dishonest marketing, and they know it. The low contrast, fine print at the bottom doesn’t make the same claim:
> 3. Analogue 3D is not designed using software emulation. It is designed using a specialty hardware chip called an FPGA, which operates on a transistor level implementation of its functionality.
But it isn’t a 1-to-1 simulation of the real hardware. Unless they have the original designs for the chips used in the N64, they’re still implementing something with likely very different internals on an FPGA.
You can get the same accuracy in a software emulator. If they want to claim it’s better because it’s more performant, or because it can use original cartridges, or it can produce better analog video output, that’s fine. But that’s not what they’re saying— they’re saying it isn’t emulation at all.
Whether it’s a program running on a CPU that interprets software written for the original device, or a configuration of look-up-tables in an FPGA that can interpret software written for the original device, it’s still a system that intends to exactly reproduce the behavior of another one. I’d call that emulation.
Sure, it’s not a software emulator, but it’s still an emulator. And Analogue’s use of “No Emulation” is dishonest: it implies that it’s somehow inherently better than a software emulator, which it isn’t. E.g. you can have an inaccurate FPGA-based emulator, and a highly accurate software-based emulator.
Analogue makes some really cool, well-engineered products. But saying there’s “No Emulation” because it uses an FPGA is blatantly false. If it’s imitating original hardware, without being the original hardware, it’s an emulator.
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).