41–50 of 69 posts
A very bare-bones linux or BSD should add minimum overhead and make things much easier
Earlier quoted context omitted.
Hey… it could run ARM code.
It can, it does.
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.
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.
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
Why do you need more?
Earlier quoted context omitted.
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’)
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.
Earlier quoted context omitted.
It can, it does.
I mean, these Z80 cards used the host computer as IO. Instead of emulating a CPU on the raspi, one could run native raspi code and use the host computer for IO... basically make the ancient host computer a graphics and sound card for a modern CPU.
Earlier quoted context omitted.
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?
> 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 ...
But (as mentioned in reply above) good Ethernet cards have way less inherent I/O latency than USB input deviceHDMI 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.
There is a back and forth in the YT comments where one commenter insists that Linux OS is still running under the hood… So the Linux OS never boots, correct? It’s booting directly from the c64 bin so to speak? Feels very Justine Tunneyish almost..
I'm not sure I get this reference
Very cool project! I've been getting more and more interested in "bare metal" projects, and one day am just going to dive right in. There's something weirdly unsatisfying about building a Raspberry Pi appliance that boots to Linux just to do a Thing, when it could just boot to the Thing.
> There's something weirdly unsatisfying about building a Raspberry Pi appliance that boots to Linux just to do a Thing, when it could just boot to the Thing. Well, I think here the distinction between Linux the kernel and Linux the OS (may RMS forgive me) is important. I agree that booting a Linux OS to run a single application seems overkill and adds little other than maintenance burden and boot time. The Linux ker…