hail-to-the-ryzen wrote:Further tested the real time meter. I have two questions.
First, is the internal timings meter necessary now that the real time meter is now included in dosbox-x? I may have this wrong, but it seems that the real time meter is measuring the rate of ticks assigned to the emulator versus real time; and the internal timings meter is measuring the rate of ticks processed by the emulator versus that expected to occur in the emulator. So, the internal timings is internal to the emulator only while the real time meter is comparing against a real clock. If this is correct, then what would cause the emulation to fall behind on processing ticks?
The second question is about the real time meter in practice. I compared the dosbox-x page fault method (core=normal) to the vanilla dosbox method in the Quake timedemo. While the FPS was low, the vanilla dosbox method shows the real time meter at 100% with small deviations. It would sometimes show a value as low as 95%. However, in the dosbox-x method, it would deviate by values that were a bit larger, but more obvious are the dips to 92%. Could this be caused by a 5% difference in performance between the methods or is it possible that the page fault method could influence the emulation timings as compared to real time?
Many things can slow down emulation speed vs realtime, including disk I/O, idle loops that check a variable constantly, or anything that doesn't decrement the CPU cycles count more than one value.
In vanilla DOSBox (and the code I just replaced) the FPS timing is checked once per instruction (in the inner normal loop before executing another instruction, while in DOSBox-X performance is gained (theoretically at least) by checking only once before going into a loop executing instructions. This loop can execute anywhere from a very short time to up to 1ms (one tick) in emulator time. The cost of this change is that the FPS and RT timing code cannot assume that they are executed exactly 500ms apart in emulation time.
Looking at how I have the internal timing code arranged right now, a guest page fault will prevent the "increaseticks" code from executing. I did that to avoid a goto jump from within to without an exception handler. It seems to me though the "increaseticks" label could be removed, and the "goto increaseticks" could be replaced with a "break" statement to just break out of the while(1) loop. If that's true, then the internal timing code could be moved out to the bottom of the function so that it always executes even after a guest page fault.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.