Yeah, I suppose on the Windows build, some of the discrepancy could be
related to I/O "wait" timing reading the hardware in the background task
or something, causing loops to execute faster than they normally would.
I know for a fact that when performing I/O with the LCD controllers, the
ROM definitely has added delay waiting for the BUSY bit to go inactive.
I even added delays in VirtualT trying to approximate that delay a bit
(LCD scrolling was way faster than real hardware, even at 2.4 MHz).
But in terms of the difference between Windows and Linux timing, that
sounds more like a bug in the code for Linux ... the emulation should be
able to make those nearly the same. The two implementations use totally
different code (using #ifdefs) since timers are different between the
two OSes.
Ken
On 2/10/26 6:19 PM, John R. Hogerhuis wrote:
How much accuracy can be expected though?
Some of what the rom does is background poll hardware. I know I didn't
account for any hardware speed in Cloudt other than the CPU.
A for loop doesn't do anything hardware wise but the ISRs are still
running and basic ROM and Any TSRs (usually optroms) do their own
housekeeping, which may interface with hardware.
I guess all background has some I/o instructions. If they always only
hit once each and don't result in any looping (or always the same
amount of looping) it will be a consistent amount of time for the
background. At the very least I would think a fudge factor would be
needed to get parity with real world if we are compounding overhead
error with big loops .
Rex is an interesting variable because it hooks some callbacks for its
own housekeeping code (I think to recover from warm resets) so it is
expected to change the background overhead.
-- John .
