Earlier quoted context omitted.
> It’s not harder to do in software. It’s just hard to get the timing correct, regardless of whether you are using software or hardware. I am disagreeing with this.
The statement is about relative timings, to be clear, and you agreed with that. I'm not trying to be clever here to win an argument, I really just think that good relative timing is implied by "accuracy", and good wall-clock timing is not--that's "performance". It makes sense to me that these terms are separate, so I can say something like "I have a cycle-accurate emulator that runs at 25x realtime". For stuff like g…
As for how much wall-clock accuracy you need... Eh, as said, it depends on how much of a preservationist you are. If you plan to actually generate an NTSC or PAL signal on a low level (including actually performing the quadrature amplitude modulation), it can well become relevant, and phase noise affects color.
Otherwise maybe not, though again I'm not surprised if some standard Linux on some RPi actually shows visible glitches from time to time. Irrelevant for most users, but then again most users may also just want to play the game on a rudimentary emulator, or even a more modern version of the game. This is all either for fun or for preservation, after all.
If you do need (video signal) or want (anal retentiveness) high wall-clock accuracy, an FPGA then also has the advantage that whatever ARM core or whatever you have next to it can implement UI and control in whatever is most convenient, on any non-RT run of the mill OS, without any risk to negatively affect the rock-solid, cycle-locked emulation in the FPGA. On an overall weaker overall SoC at lower frequency, even.
An FPGA does make things easier, is my point.