The current list of what it can do with FPGA is listed here - https://openfpga-cores-inventory.github.io/analogue-pocket/ and the inevitable sub-reddit is a good resource. https://old.reddit.com/r/AnaloguePocket/
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.
I've always wanted to get more involved in emulation and this seems like a perfect scene to get involved through
The workflow of testing new cores on AP if you don't have Developer Pocket seems kind of nasty.
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’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.
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...
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
When using a dock, is it possible to get around this delay?
[0] https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...
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.
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
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.
https://www.avnet.com/wps/portal/us/products/avnet-boards/av...
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).
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.
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.
mA? You're not very convincing here.
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
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.
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].
Guessing that's a generalization of using it as the main CPU. There's a Lattice ICE5LP4K FPGA in the iPhone7.