[agg23]

In theory yes, but in practice there's many sources of latency introduced by a modern system with OS, and even an emulator running on bare metal has additional latency. Framebuffers and input are the main sources, and there's no real parallel in emulators, unless you're going to multithread on dedicated separate cores, dedicating one to input, one to video, one to CPU, etc.

Now for the vast majority of users, this does not matter at all. As much as I like to think I can tell, it's probably placebo or the slightest feeling like something is not right. But I think it's a worthwhile reason to have a different method of replicating these old and eventually dying machines, and it's much more intellectually interesting as you say.

[musicale]

I was intrigued by the microcorelabs examples since they seem to be drop-in replacements for the hardware and are capable of running timing-dependent games and demos. Basically equivalent to the hardware, with the same input and output signals and timing. Note the 68K emulator was implemented on an Arduino-compatible Teensy microcontroller board rather than a full-blown Linux PC - though it does support 8GB of RAM, much more than the Mac it was plugged into!

If a device has the same input and output signal timing as the original hardware, then the implementation - be it custom silicon, FPGA, or software - is largely irrelevant to its functionality.

Regarding parallelism, it doesn't really matter as long as the output signals settle in time to meet the clock boundary.

I agree completely regarding the difficulty of getting input and display timing to work properly in a software emulator, especially running on a PC with a modern OS.

[musicale]

MB, darn those autocorrecting fingers ;-) I guess potentially the Mac in question could support 8MB, perhaps via a similar CPU daughterboard; of course now people complain about 8GB not being enough in entry-level Mac configurations.