You'd also need to add the video accesses into what you communicate outward, I guess, as they're surely observable. Then the emulation processing needs to happen very promptly to get to the next cycle, ideally in zero microseconds. So for real hardware you need to then replay the whole bus cycle, possibly sampling the real bus to supply back to the virtual one. Which is the processor telling you what it did for the last clock cycle to get up to now, when it expects either to sample the bus again or else is currently actively loading something that somebody else could sample. in the Oric specifically you've got the function that receives a complete clock-cycle of activity from the 6502 in one fell swoop. Most of the machines work similarly, but e.g. Re: potentially attaching real hardware, I think the main constraint as currently arranged would be timing. I'm hoping to work up to adding a 16-bit floppy-based machine to my emulator at some point, as I think that'll really help me to figure out how well my handling of this stuff works there's a lot more there to test with in terms of protection schemes. Capture devices like the Kryoflux will provide the big versions if you want them, but the summarised forms have the critical mass.

Where 'very large' is large enough to be problematic for devices like floppy emulators to stream in real time from an SD card. My understanding of the problem with disk images, even now that a lot of very clever people have a very thorough understanding of all the analogue issues and emulator authors tend to talk to one another, is that they can either be very large or not completely descriptive.

Oric emulator mac