Re: [AD] Timer problems on 4.3.10

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Sun, 2009-01-25 at 10:41 +0000, Colin Ward wrote:
> Hi all.
> 
> I just had a user report a problem that rest() wasn't working and when I
> looked into it, surely enough it was broken.  The odd thing is that when I
> looked at my timer implementation it doesn't make much sense.  Fair enough,
> I remember I wrote that when I was new to Allegro.
> 
> So I started to dig deeper and found that when requesting a timer using
> install_int(), it uses a magic formula to convert the millisecond wait to
> timer ticks:
> 
> #define MSEC_TO_TIMER(x)      ((long)(x) * (TIMERS_PER_SECOND / 1000))
> 
> Where TIMERS_PER_SECOND is 1193181L.
> 
> What precisely is this?  Is is an old PC clock time that all Allegro timing
> is based on?

Yes. Allegro 4 measures time in units of 1/1193181.

>   When I call timer.c:_handle_timer_tick() starts calculating
> the delay to the next time with a variable that is set to 0x8000.  I can't
> see how this 0x8000 fits into a timer that has a frequency of 1193181L
> times per second.

Reading the code, I'd say _handle_timer_tick takes as parameter the
time, in above units, since the last call to the function. Then returns
an approximate time when it should next be called. The 0x8000 seems to
be the largest possible value returned, so it requests to be called at
least 1193181 / 32768 = 36.4 times per second. Completely arbitrary of
course (well, likely some DOS device at the time this code was first
written used this frequency for something), but drivers are free to
ignore it anyway.

All your platform specific code needs to do is call the function
regularly with the correct parameter, look at src/win/wtimer.c or
src/unix/uptimer.c to see how it is called.

-- 
Elias Pschernig <elias@xxxxxxxxxx>