Posts: 3,522
Threads: 189
Joined: Dec 2003
If you have a code somewhat like this:
t!=TIMER
do.some.stuff.very.fast
m!=TIMER
PRINT m!-t!
And the output will sometimes be 0 (it isn't 0, but obviously it is too small for TIMER to detect)
So what is the resolution of TIMER? I have a vague memory of 0.182sec but it could be wrong.
Posts: 137
Threads: 9
Joined: Feb 2004
Actually, it's about .05 - .06, and it ticks 18.2 times a second. Easy to see where you got that number from. I generally consider timer to be accurate to 1/10, at least, but beyond that not very accurate. Another thing to watch for is that even if you get the lowest possible non-zero return value, you won't always get the same value. I'm not entirely sure about the reasons for this, but I would bet it has to do with the fact that timer ticks an uneven number of timer per second, so from second to second the exact time that it ticks varies a bit.
Jonathan Simpson
onathan Simpson
Posts: 451
Threads: 16
Joined: Feb 2003
The exact frequency of the PIT (programmable Interrupt Timer) which TIMER gets its value from is....*drum roll*...
1193181 / 65536 Ticks per second. (1.193181KHz / 64K)
This works out to 18.2064971923828125. But that is an aproximation (thank-you Mr. Spock).
All those "millisecond timer" libraries you see just change the divisor to a smaller value causing more interrupts per second. This allows for more precise timing.
Anyway, now you know.
Life is like a box of chocolates', hrm, WTF, no it isn't, more like, 'life is like a steaming pile of horse crap.'
Posts: 292
Threads: 31
Joined: Apr 2003
The 65536 kind of makes sense in computer terms (2^16), but 1193181? Where do these numbers come from?
Posts: 1,752
Threads: 21
Joined: Jun 2002
