Mechanical drive timing? You mean the tape deck?
That would be a mechanical drive, yes. There also appears to be a floppy disk. I remember trying to model the timing of the CD drive in PCE-CD (based on some test data), and was frustrated at how difficult it was. Of course there's no such thing as perfect since the timing is not in discrete units, and real performance will vary from drive to drive within some tolerance (which will vary due to environmental conditions, aging, etc), but at the same time it still has to be right enough or some games won't work. You wouldn't think such games would be so sloppy but badly written games are good at finding ways to unintentionally rely on very particular behavior, or maybe I should say they're good at accidentally working. No idea how much this is true with Speccy games though.
Seriously, we've been emulating the z80/ULA combination at 99% accuracy for years at a software level - there isn't any software available now that can tell the difference between a 48k/128k Spectrum and an emulator. The aforementioned remaining CCF flag affector is unreliable and changes between z80 manufacturers... Timing is measured in T-States, and current emulators are now accurate to 1T accuracy, and you really can't get any lower than that. And the only instance of a 1T difference between machines is in the ULA frame start period and depends on how warm the Spectrum is - and we emulate that too.
Edit: We also emulate DRAM refresh (and the corresponding fade in the RAM chips if the refresh is witheld) too - and that's about as extreme as we go.
99% accuracy isn't quite the same as 100% though
And of course I have no doubt that very, very accurate emulation has existed for a long time now. I just wondered how much overhead it takes to get that level of accuracy, even with very clever implementations. I might be overestimating the demand based on what I'm used to with consoles where graphics and sound chips have relatively complex state machines and all of the components interact with each other in complex ways. ZXSpectrum may be simpler than that (if the huge number of clones are any indication), and if you only have to worry about tightly timing the CPU and stuff like DRAM refreshes then yes, a microcontroller may suffice. What I'm thinking about is things like having to capture exactly how the graphics chip accesses memory (running a state machine that is often a lot faster than how the CPU processes instructions) in order to properly emulate delay cycles added due to contention between it and the CPU. Or worse, something like multiple CPUs sharing memory, or emulating cache and writeback timing (or worse, doing both). Now from what I can see, ULA and Z80 does have contention in accessing VRAM, but the access patterns seem more fixed and straightforward than some other platforms I'm thinking of, since video is not much more than a framebuffer.
Let's just say, if you were trying to do an NES emulator that was very close to perfectly accurate (based on the extensive reverse engineering done on the NES), you'd have a very hard time doing it on a microcontroller. Especially something that's not a high end ~200MHz Cortex-M4, M7, or microAptiv or whatever, but more mid-range like a 72MHz Cortex-M3 or something. But if you think this is pretty doable for ZXSpectrum I'll take your word for it. On the other hand, if very very few games rely on such incredible accuracy it might not really matter very much. I guess you guys will get to see how good it is with tech demos.
