Busy main loop?

[Larswad]

It looks to me like the main emulation loop is busy-active while waiting for the next tick (no wait-points, wasting cpu).
I do realise the narrow timing required for the cycles, but wonder if it really has to be timed between each tick at all?
Thinking a little about what actually do rely on actual time, is probably then the cia timers (or maybe something else as well)?

If not, a frame I would guess could be rendered full-speed, just a long as each peripheral involved is correctly sharing the cycles per all rules (which the emulation does very nicely already).
But, that way I suppose the only thing that has to be timed well is the actual full framebuffer to be rendered at the correct interval.
Probably double-buffering of the frame would be needed (unless that cause a slight latency problem).

Maybe a sort of "virtual" tick can be counted through the cycles, since we do know the "worth" of each cycle in actual time.

I know it is hard to be very exact, for instance PAL is 50.12 Hz, not exactly 50 so a skip is done approximately every 8'th frame or
so due to the leftover time. The VIC dot clock doesn't even up to 50Hz for PAL och 60Hz for NTSC either for that matter.

If the frame buffer flip itself can be timed to the exact framerate, the video-driver can be tweaked to use that frequency. Well, at least with some tweaking in nvida / amd drivers.

Very interesting code and take on c64 emulation, I love the Rust beauty of it.
Right now doing my own in c++ just for my own sake (very near ready with the cpu), but then hell starts with the rest.
I try to do as much abstraction and interface separation as I can, to make the structure very general and extensible.

I have done a little rust at during a work assignment, but not yet very strong in it.
Thanks for the very nice project you've shared on github.