Mail Archives: djgpp/1997/05/12/02:48:00
Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk> writes:
> Win95 doesn't mind them any more, because I fixed the code to work
> around the things that upset it in Allegro 2.1, but they aren't as
> accurate when used under Win95. In DOS, the clock is programmed right
> down to the hardware resolution (1/1193181 of a second, although in
> practice not quite that accurate due to interrupt latency), but in Win95
> it is only accurate to the nearest 1/200 of a second (5 msec).
Pardon my Win95 ignorance, but just what is Win95 requiring from the
timer? It sounds like it's more difficult than calling the original
interrupt every 1/200, but I can only see three issues: setting the
timer at all, handling/calling back int 0x08, and handling/calling back
0x1c. Naively, none of the three look so hard, but I'm not at all
familiar with what Win95 wants from the timer.
I thought the user-defined timer-tick (int 0x1c) was called by the
original 0x08 handler, but it's been years since I tested that so I may
have forgotten. Anyways, if that's the problem, I'd think giving 0x1c
its own handler (co-operating with the other handler) to call 0x1c
200/second could let the timer run free again?
Also, I have been thinking that where read_timer isn't reliable enough
to simulate retraces (as you describe in allegro.txt), they might still
be simulated if multiple trials could be made cheaper. Hypothetically,
my_timer_int would look at one more volatile flag that would indicate
"This new tick is *only* looking for a retrace", and it would branch,
test for retrace in progress just once, and either fire (do the
retrace-stuff, EOI, and return) or set up to try again after a short
interval. That would cost a few more calls, but would eliminate long
waits for the retrace with interrupts disabled. There'd be a bit more
calculating, but it seems doable. I want to get feedback on how
reasonable this is before I jump in. What do you think, worth doing?
Tom
- Raw text -