93143 wrote:Good luck emulating a fully accurate Super Accelerator System with sub-pixel latency (ie: "none"), or even a few scanlines of latency, on any modern system. A Raspberry Pi isn't powerful enough, and a full-scale PC isn't real-time enough (I'm not sure it's powerful enough either). Just using a framebuffer adds a whole frame of latency by itself. You'd basically have to completely take over a powerful PC at the hardware level, bypassing the OS and drivers, and probably write parts of the emulator in shader language, to get anywhere near what an FPGA could do if properly programmed.
This is kind of a bizarre statement. What is "sub-pixel latency" supposed to mean?
If you want 2 simulated chips to correlate with cycle-accurate timing, that's entirely doable on PCs and RPis with emulators. This is not a performance problem, and I don't know why you think it must be. Many emulators are already doing this kind of thing just fine.
Otherwise I have no idea what the relevance is, like you want the video output (i.e. light emitted from your screen) to change at some level smaller than a pixel? What are you even talking about?
Even outputting video scanline by scanline has very little relevance at the FPGA or PC emulator level, that's a video device problem, kind of a different domain. Sure, an FPGA could
be used to generate a composite video signal, but so could a suitable generator attached to a PC-- but it wouldn't make any difference unless you were connected to a CRT. Otherwise your monitor will process and display the video signal with its own process that has very little to do with that. Incidentally, you could probably do scanline-by-scanline output on many PCs' built-in video hardware in VGA mode while connected to a CRT, if you really wanted to go down this road. (Shader language would not help with this in any way, IMO.)
But even if you did this, this concept of zero latency vs 1 frame of latency is almost meaningless. The main place it matters is if you want to use an original light gun device that needs to sense light in a very immediate way, much faster than human perception. Like I said in my summary though, emulators don't work with original hardware anyway, all aspects of that have to be simulated, and there are plenty
of emulators that simulate a light gun in a very accurate way. (There are even ways to go the other way and use modern pointing devices to connect with the original light gun hardware
5 frames of lag on video output is something to care about. <=1 frame of lag? Hardly significant. Scanline by scanline only matters if you're trying to interface with some original hardware that can see light changes that fast (not relevant
when you're simulating the hardware). Pixel by pixel, I don't think many things are meaningfully sensitive to this. Sub-pixel? No, that's not a thing.
So the light gun thing is an important point for FPGA clones. That was in my list of features in my earlier post: if you want to interoperate with original hardware (carts, peripherals, etc.) then these are capable of that. If you want to replace a system but otherwise keep all the same hardware connected, this is the
If you're simulating
the hardware (ROM file instead of cartridge, USB joystick instead of original gamepad, mouse instead of lightgun, window on a desktop instead of a dedicated television, etc.), the simulation
can certainly be as accurate as any FPGA clone could, and plenty of emulators do accomplish this.
Latency on a scale relevant to human interaction is definitely a persistent problem on PCs, but not unsolvable. It's generally down to operating systems, video hardware interfaces, monitors, and the parts of the software that interact with those. Much of what affects that can't be solved at the level of the emulator's software (e.g. video drivers, processing in the monitor itself, operating system settings, USB drivers, etc.) and unfortunately needs work from the user to address. (Fullscreen mode instead of windowed can often help. A 120Hz monitor may address the issue too. This is a whole system configuration topic of its own though.)
CPU power also doesn't really help here. Very little of the latency problem has to do with CPU speed, generally it's all upstream/downstream from the emulator itself.
...but all of that is unrelated to accuracy of emulation. Latency is its own separate issue. If you don't have a CRT and original peripherals to hook up to your FPGA system then it's going to have the same monitor latency issue anyway, at the very least.
The FPGA clones I've seen are good stuff
, but you shouldn't conflate output (or input) latency with emulation timing accuracy. You can have one and not the other, and that goes both ways. There are
low latency emulator setups, but FPGA systems will have that by default. Cycle accuracy, on the other hand, good emulators already have. FPGAs have no monopoly on that.
The main advantage of emulators is that they're free
and run on a computer you already have, which is something FPGA clones can't compete with. The converse is also true, your PC is never going to run an NES cartridge, it needs ROM dumps. That's
the main tradeoff. Accuracy is not an issue, a good emulator is just as good as an FPGA for this.
an issue, and an FPGA clone might be worth its cost to just not have to try and figure out your PC latency problems. It's solvable, though. Many people do manage to get good low-latency setups using emulators.