NOTE: DCTEdit v0.04 [18]
 GW> What you've written clarifies things a bit, but my comment still
 GW> stands. You do _NOT_ wait for an interrupt in an interrupt. There is no
 GW> guarantee that the required interrupt will occur before the interrupt
 GW> you are sitting in requires servicing again. You have to do it by
 GW> setting flags in global data space to show the status of the interrupts
 GW> that you can test.
But if you disable the timer interrupt while in it's ISR by clearing it's bit 
in the PIT, then it doesn't matter if it tries to be called again because it 
will just be ignored, that being a worst case senario, most of the time the 
timer ISR will finish well before the next interurpt.
 GW> I see in another message in the thread that you are doing much of your
 GW> processing inside the timer tick interrupt. This is potentially
 GW> dangerous, and you should only do what is _essential_ within a hardware
 GW> interrupt service routine. This should really be limited to
 GW> reading/writing data and setting/clearing status flags. With proper
 GW> design everything else can be done within the main program.
 GW> Why do you find it necessary to do so much within the timer tick
 GW> interrupt?
Everything in the timer interrupt requires to be executed at the right 
speed(approximatly). If I just set flags telling the main program what to do 
when it's not in the interrupt, I'll have to populate it with calls to the 
function(s) that need executing, that isn't very nice since it's... well I 
think you can see why it's not nice expecially with lots of inline ASM.
The main loop of the main program can take anywhere from a few milliseconds 
to several seconds to go through once, so simply putting those function calls 
in the main loop won't do at all, in fact it will remove a lot of the 
usefulness of having the timer interrupt at all. But my reasoning for so much 
stuff in the ISR is what could possibly go wrong?(apart from re-entering some 
functions which is not really related to execution time.) This isn't a TSR so 
other unknown programs don't need to be considered, including TSRs hooked 
onto the same interrupt.
If you see another way of doing it, please tell me, although there's a good 
chance I won't use it unless it's similar to mine because this project is 
almost complete.
... There's always one weirdo on the bus, and I couldn't find him!
--- Maximus 3.01
---------------