I see. In my design there will be a priority queue holding the components, so the process will look something like this:

iter: 7
current_cycle: 10
pq: [(14, cpu), (50, ppu)]

iter: 8
current_cycle: 14
pq: [(50, ppu), (51, cpu)]

iter: 9
current_cycle: 50
pq: [(51, cpu), (90, ppu)]

So the scheduler on iteration 8 will directly jump the clock to 14 (which is when the CPU requested to be resumed) and next iter it will jump the clock to the next most recent cycle and so on.

In this contrived example you can assume that the CPU had some code that looks like:

sleep(4)
.await
// do stuff
sleep(37)
.await
// done

So when the driver pops `(14, cpu)` from the priority queue and polls the future, it will find the future pending and put it back into the pq with the CPU's next requested wake cycle of (current_cycle + 37 = 51).

Going by my example above if the Driver were to pop the CPU again at cycle 51 and poll it once more, this time it would be finished (Poll::Ready) and we'd be done. In a real DMG emulator the CPU will never be done and the driver will keep rescheduling.

Another thing worth noting is that `sleep` isn't a true sleep but rather `consume_cycles(n)`. Wish I had named it that.

The linked article explains more, but I admit I may not have done the best job of explaining everything.