Software is orders of magnitude simpler in complexity, yes. The difference between a software emulator and a logic level emulator are immense.
But take the example of the difficulties with a software NES emulator:
In hardware, there is one clock that is fed into the 3 main disparate systems; the CPU, APU (audio), and PPU (picture). They all use different clock dividers, but they're still fed off of the same source clock. Each of these chips operate in parallel to produce the output expected, and there's some bidirectional communication going on there as well.
In a software emulator, the only parallel you get is on multiple cores, but you can approximate it with threading (i.e. preemption). For simplicity, you stick with a single thread. You run 3 steps of the PPU at once, then one step of the CPU and APU. You've basically just sped through the first two steps, because who will notice those two cycles? They took no "real" time, they were performed as fast as the software could perform them. Probably doesn't matter, as no one could tell that for 10ns, this happened.
You need to add input. You use USB. That has a minimum polling interval of 1000Hz, plus your emulator processing time (is it going to have to go in the "next frame" packet?), but controls on systems like the NES were practically instantly available the moment the CPU read.
Now you need to produce output. You want to hook up your video, but wait, you need to feed it into a framebuffer. That's at least one frame of latency unless you're able to precompute everything for the next frame. Your input is delayed a frame, because it has to be fed into the next batch, the previous batch (for this frame) is already done. You use the basis of 60fps (which is actually slightly wrong) to time your ticking of your emulator.
Now you need to hook up audio. Audio must go into a buffer or it will under/overflow. This adds latency, and you need to stay on top of how close you are to falling outside of your bounds. But you were using FPS for pacing, so now how to you reconcile that?
----
Cycle accurate and low latency software solutions are certainly not easy, and it's impossible for true low latency on actual OS running CPUs. Embedded-style systems with RTOSes might be able to get pretty close, but it's still not going to be the same as being able to guarantee the exact same (or as near as we can tell) timing for every cycle.
I want to be clear that none of these hardware implementations are actually that accurate, but they could be, and people are working hard to improve them constantly
Analogue could support a SNAC type adapter with the Dock (I highly doubt it, those USB ports are almost definitely wired directly to a real USB chip). Users could develop a cart slot adapter (someone has, he's just lazy and hasn't finished it), but this won't work with any OS features, just the cores themselves.
But take the example of the difficulties with a software NES emulator:
In hardware, there is one clock that is fed into the 3 main disparate systems; the CPU, APU (audio), and PPU (picture). They all use different clock dividers, but they're still fed off of the same source clock. Each of these chips operate in parallel to produce the output expected, and there's some bidirectional communication going on there as well.
In a software emulator, the only parallel you get is on multiple cores, but you can approximate it with threading (i.e. preemption). For simplicity, you stick with a single thread. You run 3 steps of the PPU at once, then one step of the CPU and APU. You've basically just sped through the first two steps, because who will notice those two cycles? They took no "real" time, they were performed as fast as the software could perform them. Probably doesn't matter, as no one could tell that for 10ns, this happened.
You need to add input. You use USB. That has a minimum polling interval of 1000Hz, plus your emulator processing time (is it going to have to go in the "next frame" packet?), but controls on systems like the NES were practically instantly available the moment the CPU read.
Now you need to produce output. You want to hook up your video, but wait, you need to feed it into a framebuffer. That's at least one frame of latency unless you're able to precompute everything for the next frame. Your input is delayed a frame, because it has to be fed into the next batch, the previous batch (for this frame) is already done. You use the basis of 60fps (which is actually slightly wrong) to time your ticking of your emulator.
Now you need to hook up audio. Audio must go into a buffer or it will under/overflow. This adds latency, and you need to stay on top of how close you are to falling outside of your bounds. But you were using FPS for pacing, so now how to you reconcile that?
----
Cycle accurate and low latency software solutions are certainly not easy, and it's impossible for true low latency on actual OS running CPUs. Embedded-style systems with RTOSes might be able to get pretty close, but it's still not going to be the same as being able to guarantee the exact same (or as near as we can tell) timing for every cycle.
I want to be clear that none of these hardware implementations are actually that accurate, but they could be, and people are working hard to improve them constantly