5 ms·

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 d

• cmrdporcupine 3y ago
  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
  • DCKing 3y ago
    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.
    • cmrdporcupine 3y ago
      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.
      • rusk 3y ago
        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.
  • pjmlp 3y ago
    MiSTer is quite successful FPGA in the retrogaming scene though.
  • 15155 3y ago
    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?
    • cmrdporcupine 3y ago
      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.
• dzdt 3y ago
  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?
  • zare_st 3y ago
    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.
    • bluescrn 3y ago
      ‘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’)
      • zare_st 3y ago
        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.
• raphlinus 3y ago
  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.
  • wiz21c 3y ago
    Could you explain why latency is better on such system ? I fail to see why by just reading the tech spec... Thx.
• ghusbands 3y ago
  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.