Hacker News Reader

Comment by DCKing | Hacker News Reader

One of the key advantages of FPGA retro game emulation is its low overhead processing input and audio. This is because the FPGA emulates hardware directly and doesn't have to go through OS abstraction layers built to accomodate multitasking.

I wonder if bare metal emulators can achieve similar latency for software emulation.

View on HN

With a 1982 commodore 64, a tight polling loop could detect a button press within 7 microseconds of its occurence. An onscreen change could be displayed with another 5 microseconds (more if the display happened to be in horizontal or vertical refresh at the event time, but still.) Can any modern system give such tight IO timing?

Yes but our default USB HID stack isn't made for it. USB is not good for sub millisecond latency.

If you make a keyboard that can send signals fast-clocked over wire to PCI interface card and use polling in the driver you can go as fast as you want. A microsecond poll is not a burden for the CPU core.

‘Input lag’ in games is rarely about input.

It’s usually all about the latencies involved in getting graphics onto the screen after responding to the input.

Even an FPGA-based ‘emulator’ or real retro hardware with the fanciest low-latency upscaler won’t feel truly responsive if connected to an LCD TV that adds 60-100ms of latency (yes, some are really that bad, especially if not in ‘game mode’)

Agreed. I might've put "human interface" as opposed to HID, to cover the output too.

We didn't design modern stacks to handle lowest latencies possible. Because everything is a tradeoff.

Take a look at audio I/O on normal PC in 2000s. Although input digitizing and output de-digitizing were always fast enough, the "DSP" (moving data to userspace, processing, and out) was slow. Because in software design it was given that millisecond latencies aren't a thing, we used a lot of locks and copying around to ensure the system works correctly for average use which isn't realtime IO. However when someone desired realtime IO they enhanced the drivers and/or the audio software stack.

That approach worked because there were no issues in electronics, so to speak. With gaming you have slow USB input and slow HDMI/whatever output.

In my view that is peripheral issue and not architecture issue, although you can also say it is a platform issue. The question is not that straightforward.

> With a 1982 commodore 64, a tight polling loop could detect a button press within 7 microseconds of its occurence.

Now if they just would have made multiprocessor C64s so that one could have been dedicated to that tight loop ...

In fast network processing on PC hardware, you process interrupts of NIC on a single core, automatically. That NIC is DMAing the data which you can poll and dequeue from memory via multiple consumer ring buffers. You have a single master core and N worker cores. If you go for performance and decide to dumb poll without any yields the system will be lightning fast (and max out your CPU usage)

But (as mentioned in reply above) good Ethernet cards have way less inherent I/O latency than USB input device<->HDMI screen chain.

So, I see the solution in a PCIx graphics card that can generate VGA signal and take PS/2 input via poll mode drivers. If you connect "real" peripherals to it you can go low-latency, if you connect HDMI/USB stuff via adapters you'll have arbitrary latency.

You could do processor offloading to the entirely separate 6502 in the CBM 1541 disk drive, like this fractal generator.

https://www.c64-wiki.de/wiki/Mandelbrot-Construction-Set

A particular point in the space I find very appealing is emulators running on RP2040 class microcontrollers such as Raspberry Pi Pico. These have most of the advantages of FPGA, including latency measured in microseconds, near instant boot, and "racing the beam," but at considerably lower cost.

Could you explain why latency is better on such system ? I fail to see why by just reading the tech spec... Thx.

It doesn't seem like it in this case. The article states there's 2-4 frames of video lag even on composite and 5-6 frames of audio lag.

yes and no. no or little OS abstraction, but still there's layers in the way, and it's still sequential in places where an FPGA could be parallel, etc.

a Pi etc has a huge advantage in raw clock speed. FPGAs are pretty slow. at least the ones that you and i can afford

What layers do you mean that would remain?

I wouldn't expect the experience to be identical nor quite as accurate [1], but if audio and input latency could be made indistinguishable between a Raspberry Pi and a Mister FPGA that would already be quite a significant feat :)

[1] FPGA emulation is not intrinsically more accurate, but most Mister cores are considered to be more accurate than popular Retropie cores.

Framebuffer is one such layer. The output from the emulator goes into a framebuffer before being rendered. It's not going to "race the beam" the same way a FGPA'd VIC-II would.

Same with USB input stack, though I guess MiST/Mister has that too.

Same with SID emulation, which would render into audio buffer samples of certain size (and therefore latency), whereas a hardware or FPGA SID could drive the DAC directly.

This is an interesting dichotomy: analogue vs digital - but I think there’s a third leg to it which is DSP. When your floor is a 1 MHz 6502 and you have a DSP running at many many multiples of that, you can mimic analogue circuits almost perfectly, with identical latency, but better reliability, serviceability, and cheaper parts. The key thing to remember here is that the 2040 is more like a DSP emulating the signals than a regular pi emulating the system. Something as simple as a c64 it should be possible to emulate with DSP indistinguishable from discrete circuits.

The key latencies you describe (frame buffer, audio) aren’t really an issue in the DSP scenario. Also, non linear components like the SID are going to be harder to reimplement in discrete circuits and in fact I’d expect DSP would do better.

DSP wins every time in all domains. Problem is you need to have a much more fine-grained knowledge of the physical underpinnings of the system, not just the system itself.

MiSTer is quite successful FPGA in the retrogaming scene though.

Every modern Xilinx FPGA with enough logic to implement a Commodore 64's functions can more than clock at the 1MHz required. 50MHz-200MHz is reasonable. A $40 Artix A35T can handle this.

Why do you need more?

You don't, for a C64. We weren't talking in this subthread specifically about the C64 but about the broader idea of FPGA vs CPU driven emulation.

When you get into higher spec machines, esp from the 90s, FPGA starts to not be the best choice $$ per clock.

Reply on news.ycombinator.com