Timings are usually documented as well, usually at the clock cycle level.

Beyond that, you have to worry about hardware peculiarities that happen to affect maybe a few games, and at that point, you might start reverse engineering the behavior of those games!

Take a look at this article talking about exactly those thinking issues: https://www.tested.com/tech/gaming/2712-why-perfect-hardware...

Why not link to the original article?

https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...

Oops! I searched for the article, then picked one of the results. I didn't realize the one I linked wasn't the original because I only looked through it enough to make sure the right content was present.

Thanks for the correction!

One way is to keep track of the emulated CPU clock cycle count, and each emulated instruction adds to this count. In each host system frame, run the emulation for the number of cycles the 'real' emulated system would be able to run in that time.

The number of cycles per instructions can be either looked up from a table, hardwired into the emulation code, or if your emulated CPU is working on a "sub-instruction" granularity, the cycles per instructions "fall into place" automatically.

For instance if your host system's frame duration is 16.6ms (for a 60Hz framerate) and your emulated CPU needs to run at 1 MHz you compute the number of clock cycles as (1000000 / 60), that's about 16k cycles per second. Run the system emulation until the accumulated cycle count is >= that number each frame, and if you're emulation is fast enough you still have plenty of time left in the host system frame to render the emulator's video output, audio and an UI on top.