Not to draw attention to myself or anything, but if you're interested in learning to make cores for the Analogue Pocket or MiSTer (or similar) platforms, I highly recommend taking a look at the resources and wiki I'm slowly building - https://github.com/agg23/analogue-pocket-utils/

I started ~7 months ago with approximately no FPGA or hardware experience, have now ported ~6 cores from MiSTer to Pocket, and just released my first core of my own, the original Tamagotchi - https://github.com/agg23/fpga-tamagotchi/

If you want to join in, I and several other devs are very willing to help talk you through it. We primarily are on the FPGAming Discord server - https://discord.gg/Gmcmdhzs - which is probably the best place to get a hold of me as well.

This is awesome! Thank you for sharing and documenting this so ardently. I don't have a Pocket yet but look forward to trying this tomagotchi core when I do, and maybe learning more to become a contributor when I have some spare time.

I've always wanted to get more involved in emulation and this seems like a perfect scene to get involved through

Which would you recommend is better to get started with: MiSTer or Analogue Pocket (non dev edition)?

The workflow of testing new cores on AP if you don't have Developer Pocket seems kind of nasty.

The workflow is actually the exact same for the dev and retail Pockets. Both have an exposed JTAG port, but for the retail Pocket, you just need to remove the "hump" on the lower back. You want to make sure you get an official USB Blaster (https://www.mouser.com/ProductDetail/Terasic-Technologies/P0...), because they negotiate a lower voltage level with the Pocket (someone blew their JTAG port using a cheap one).

For a beginner, the Pocket is definitely easier. With MiSTer, you're building a bunch of other framework code that isn't your own, and that adds a lot of iteration time. I also think the Pocket APIs are more refined, but also more limited. I've already written some info about this - https://www.reddit.com/r/fpgagaming/comments/1318jsr/tamagot...

I spent an hour looking through the GitHub repo for the Tamagotchi core and disassembler. That you accomplished all this in just seven months is very impressive, for someone like me just starting out learning Verilog on Xilinx FPGA in Vivado.

I’ve managed to make the 4 LEDs on my Digilent Arty board ping-pong back and forth like the power indicator on the Nintendo Switch Joy-Con controllers, debounce the buttons and switches and set up clock division to produce different frequencies from the hardware clock. That’s taken me a handful of days in my spare time.

Hey thanks for your Pocket cores, man. I really appreciate how fully featured the SNES core feels, even if it doesn't have save state support. You're doing the lord's work!

Thank you. I want to point out that the SNES core is not my own, I just did the port to Pocket. The real praise goes to srg320 (https://github.com/srg320) who has been in Ukraine all this time and is still pumping out updates.

This is perfect, thanks. I guess i signed up for a dev kit at some point as I'm an FPGA engineer by trade and got sent a pocket dev kit for free. Was a bit of a bother trying to find a singular resource for this stuff.

Feel free to drop by and ask questions. We love seeing new people build stuff.

The article says FPGAs are too power hungry for handheld devices. Did Analogue do anything special to solve this problem on the Pocket?

That's honestly not true at all; it all just depends on your platform. On the Pocket, the FPGA _is_ the processor (there are actually two FPGAs, one for the actual emulation core, and one for scaling video, and there's technically a PIC microcontroller for uploading bitstreams and managing UI). The FPGAs are still not much power compared to the display itself. With the in-built current sensor on the dev kits, the highest we've measured drawn by the main FPGA is ~300mAh. Now this sensor isn't going to be the best measurement, but it's something to go off of.

Personally I think this is the biggest selling feature of FPGA based emulation.

The reality is both Software and FPGA emulation can be done very well and with very low latency, however to achieve this in software you generally require high end power hungry hardware.

A steam deck can run a highly accurate sega genesis emulator with read-ahead rollback, screen scaling, shaders and all the fixings no problem, but in theory the pocket can provide the exact same experience with an order of magnitude less power.

It's not quite apples to oranges of course, but the comfortable battery life does make the pocket much more practical.

When being nitpicky about latency is where FPGAs truly shine. You lose a good bit of it by connecting to HDMI (I think the Pocket docked is 1/4 a frame, and MiSTer has a similar mode) (EDIT: MiSTer can do 4 scanlines, but it's not compatible with some displays), but when we're talking about analog display methods or inputs, you can achieve accurate timings with much less effort than on a modern day computer.

For a full computer like the Steam Deck, you have to deal with preemption, display buffers, and more, which _will_ add latency. Now if you went bare metal, you could definitely drive a display with super low latency, hardware accurate emulation, but obviously that's not what most people are doing.

> ~300 mAh

mA? You're not very convincing here.

Its roughly a function of driving frequency. If you're emulating a classic video game system you are in the low MHz and your power consumption is low.

More capable FPGA's like what I work with run in the hundreds of MHz and that's when you can draw 100W on a single chip

You are entirely correct, but I would like to point out that there are Cyclone V cores running logic ~140MHz, not just RAM clocks, and the power consumption is nowhere near that.

Getting a large design that passes timing at that frequency with the Cyclone V fabric is unlikely, however.

----

The distinction here, being that more capable FPGAs can get up to the 600MHz+ range, and actually run a full design at that speed.

Gate for gate an FPGA consumes more power then a dedicated chip, but the power dissipation depends heavily on the programming. Careful programming can reduce power dissipation.

A potential advantage of an FPGA over a dedicated chip is that any unused functions can just be left out, saving power dissipation and logic resources. This is the (largely unrealised) promise of Reconfigurable Computing [1].

[1] https://en.wikipedia.org/wiki/Reconfigurable_computing

They are generally much more power hungry than the equivalent ASIC, built using the same process. However if your aim is to emulate a sufficiently old ASIC then you can probably beat it with a modern FPGA. And there are FPGAs aimed at low power consumption: they are just also slower.

>The article says FPGAs are too power hungry for handheld devices

Guessing that's a generalization of using it as the main CPU. There's a Lattice ICE5LP4K FPGA in the iPhone7.

There's also the MiSTer project: https://github.com/MiSTer-devel/Wiki_MiSTer/wiki. Not hand-held (yet...) and hardware is less slick but a bunch more systems and also fully open source.

MiSTer makes me kind of sad, the DE10-nano board it's based on is 7 years old at this point, and the actual FPGA chip on the board is probably over twice as old as that. And this is still the peak of hobby FPGA chips. I wonder why Moore's Law is hitting the FPGA industry particularly hard all of a sudden.

There are better FPGA options, they're just more expensive. The DE-10 Nano was strategically chosen as "powerful enough to meet most wants while still being within a reasonable budget".

No one's going to plunk down $10k for a 19 EV Zynq UltraScale+ with 1.1M LEs, but they will spend $200 on a Cylcone V with 210k LEs.

There are mpsoc ultra scale+ chips that are under 100$ these days, so I think that's not true anymore. Even low end mpsoc ultrascale fabric is way better than that old altera stuff, with lut4 clbs, ultraram, and better dsp blocks. I've had the fabric run at 500 mhz in my designs.

https://www.avnet.com/wps/portal/us/products/avnet-boards/av...

The issue with any other board is that the boards aren't going to have all the same ports and compatibility so you'd have to have potentially two largely separate forks of the cores and accessories which would be tough in a relatively small community like the Mister. For example your board doesn't have the large pin headers used by basically every Mister accessory so at a minimum you'd need an adaptor to go from some other port on your board to the pinouts that the mister ecosystem is built on.

What kills that board (and many like it) is the absolutely proprietary SYZYGY connector, which is surface-mount (so hobbyists won't develop a board ecosystem for it, and aliexpress circuit cloners won't do their thing unless there's a proven ecosystem), and probably $10 in high quantities (if it's even in stock). RIP.

I'm not even sure that board has enough overall I/O to connect a VGA output, controller inputs, and a SDRAM chip (all of which are essential to a viable MiSTer replacement - note that no one has figured out how to use DDR RAM for emulation yet, too much seek latency).

I also recommend the official dock. It basically turns it into an easy to use Mister.

My mind is blown but I'm also wondering if this isn't some kind of incredible over-engineering? Surely CPUs are fast enough to emulate these kind of devices in software. If they aren't, they must be an order of magnitude simpler in complexity.

I wouldn't ordinarily care about emulators, but actual hardware emulators is the craziest thing I've heard in a while. All that for a small handheld console?

If only I was not so broke...

Sure it would probably be cheaper to chuck a cortex-A* or similar mid-range MCU in there. One advantage of FPGAs that it can achieve "perfect" emulation of a Z80 (or other) since it's running on the logic gate level. No software task latency, no extra sound buffering, etc. It can re-create the original clock-per-clock.

It's impressive as well

Software is orders of magnitude simpler in complexity, yes. The difference between a software emulator and a logic level emulator are immense.

But take the example of the difficulties with a software NES emulator:

In hardware, there is one clock that is fed into the 3 main disparate systems; the CPU, APU (audio), and PPU (picture). They all use different clock dividers, but they're still fed off of the same source clock. Each of these chips operate in parallel to produce the output expected, and there's some bidirectional communication going on there as well.

In a software emulator, the only parallel you get is on multiple cores, but you can approximate it with threading (i.e. preemption). For simplicity, you stick with a single thread. You run 3 steps of the PPU at once, then one step of the CPU and APU. You've basically just sped through the first two steps, because who will notice those two cycles? They took no "real" time, they were performed as fast as the software could perform them. Probably doesn't matter, as no one could tell that for 10ns, this happened.

You need to add input. You use USB. That has a minimum polling interval of 1000Hz, plus your emulator processing time (is it going to have to go in the "next frame" packet?), but controls on systems like the NES were practically instantly available the moment the CPU read.

Now you need to produce output. You want to hook up your video, but wait, you need to feed it into a framebuffer. That's at least one frame of latency unless you're able to precompute everything for the next frame. Your input is delayed a frame, because it has to be fed into the next batch, the previous batch (for this frame) is already done. You use the basis of 60fps (which is actually slightly wrong) to time your ticking of your emulator.

Now you need to hook up audio. Audio must go into a buffer or it will under/overflow. This adds latency, and you need to stay on top of how close you are to falling outside of your bounds. But you were using FPS for pacing, so now how to you reconcile that?

----

Cycle accurate and low latency software solutions are certainly not easy, and it's impossible for true low latency on actual OS running CPUs. Embedded-style systems with RTOSes might be able to get pretty close, but it's still not going to be the same as being able to guarantee the exact same (or as near as we can tell) timing for every cycle.

I want to be clear that none of these hardware implementations are actually that accurate, but they could be, and people are working hard to improve them constantly

> You need to add input. You use USB

When using a dock, is it possible to get around this delay?

Analogue could support a SNAC type adapter with the Dock (I highly doubt it, those USB ports are almost definitely wired directly to a real USB chip). Users could develop a cart slot adapter (someone has, he's just lazy and hasn't finished it), but this won't work with any OS features, just the cores themselves.

The benefit of FPGAs is you can get nearly gate perfect emulation of an old games system. We've had emulators for years that get most things right but some games and minor things in old games require specific software patches to ensure the odd why they used the chips available produces the same output. There's a great old article from 2011 about the power required at the time to get a nearly perfect emulation of a NES. [0] The goal with the Pocket and all of Analogue's consoles isn't to be just another emulation machine but to run as close as possible to the original at a hardware level. That's their whole niche, hardware level 'emulation' of old consoles.

[0] https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...

Emulating “accurately” is so difficult that not even Nintendo’s Game Boy emulator on the Switch does it properly. I’ve been replaying old games and comparing some questionable moments with my original Game Boy, and the timings are not quite right in some cases.

For example in Link’s Awakening, there’s a wiggle screen effect done by writing to OAM during HBlank. On the Switch it lags very differently than my GB (try it by getting into the bed where you find the ocarina). Or with Metroid 2, the sound when you kill an Omega Metroid is different too. It pitch shifts along with the “win” jingle.

These have almost zero impact on playability. But for purists and emudevs it’s a popular pursuit.

> Emulating “accurately” is so difficult that not even Nintendo’s Game Boy emulator on the Switch does it properly.

The NSO emulators on Switch are particularly terrible, worse than past iterations on Wii etc. at least for some systems, for no obvious reason other than Nintendo being lazy and/or not preserving past emulation work on other systems and not wanting to reuse open source solutions.

There's a few good comparisons on Youtube such as youtube.com/watch?v=ounQZv1MFNA that go a bit more into the development history

They have a huge impact if you want to play light gun games on CRT, where timing being out by a few micro seconds prevents your light gun from registering at all

Has anyone made a light gun replacement that would work with modern LCDs? Or is the frame delay too inconsistent for such a thing to work?

You cannot make 80s lightguns work on an LCD. When you pulled the trigger, the system drew out a few white boxes where the targets are, and how long it took the gun to "see" white told you which box you were aiming at, because of the raster functionality of the electron gun. LCDs always output an entire screen at once, so that cannot work.

Yes, actually: https://sindenlightgun.com/