elipsitz

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

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.

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.

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?

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.

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.

Thanks! Slint has been great to work with :)

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?

Looks like a significant jump over the RP2040!

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.

Altera, not Xilinx (owned by AMD)

I wrote about what I was doing here: https://eli.lipsitz.net/posts/internet-connected-pinball/#mo...

I needed to detect writes to a bus that could happen at 1MHz, which involved reading the state of the bus multiple times per microsecond (based on the timing of the various signals). The jitter in the worst case was multiple microseconds (causing missed accesses), no matter what I tried.

I wasn’t able to use DMA on the ESP32 to help— perhaps it could have if I had tried to massage the problem a little bit more though.

I had a project where I needed predictable timing for I/O (reading a microprocessor’s bus at 1 MHz), and the ESP32 I was using just couldn’t do it reliably. Despite having a tight loop on a dedicated core with interrupts disabled, a loop iteration would sometimes take longer than a microsecond, causing it to miss some I/O. I was able to do it much more reliably with RP2040’s PIO.

For another project, the ESP32 family unfortunately doesn’t have a model that has both Bluetooth Classic (only the original ESP32 does) and USB host/device modes (only ESP32-S2 and ESP32-S3 do), so I’m thinking I’ll use the RP2040 as the main processor, with USB, and an ESP32 coprocessor. I really would rather just use a single ESP32, but that isn’t looking like an option here.

Just edited the post to have a link to the GitHub repo: https://github.com/elipsitz/internet-connected-pinball

Fortunately I don’t have to worry about rollover. The game can score a maximum score of 99,999,999, and the highest I’ve been able to score is about 3,500,000.

Thanks! Yeah, it would work on any System 7 game, as long as you’re willing to solder in the 2x20 connector to the MPU. All of the memory locations should be exactly the same.

Awesome! I really like the idea of scanning an RFID card to identify players.

Nope, I actually hadn't even heard of Open Pinball before. Looks cool though!

It'd be nice if there were an open standard for pinball machines talking to score servers. For this project I had to do everything custom. If people started putting ESP32s on their pinball controllers there might be some actual demand for something like that.

KiCad is excellent and open source. There's a recent post about it: https://news.ycombinator.com/item?id=34769574

Yeah, definitely if people are interested. Let me clean up the repo a little bit first :)

It's probably hard to directly apply this to other machines, but the interposer board idea would make it easy to take the same hardware and use it on any MC6808-based machine.