4 ms·
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 an
by 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 agoYes 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 agoAgreed. 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.
- guenthert 3y ago> 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 ...
- zare_st 3y agoIn 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.
- lproven 3y agoYou 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 https://www.c64-wiki.de/wiki/Mandelbrot-Construction-Set