>> 1. We need a method that allows one to "steal" an interrupt
>>    vector, and restore it again. 
>>    This is because I need to reprogram TIMER1 to give me ~20000
>>    interrupts pr sec. for the player, but ONLY when it plays as
>>    this imposes _some_ load on the system...

> Cranking the timer rate intermittently while the timer is used for
> other things really isn't practical -- you'd pretty much need to crank
> it all the time unless you pushed the other activity elsewhere (onto
> another timer).

It's very practical.  Just divide down the clock.  However, this ought
to be handled by the standard clock driver changing the clock speed
and attaching itself to special interrupt handler(s) and not by stealing
vectors.  I'd also like the clock driver to allow variable (faster)
profiling rates.

> This is pretty much the timer code rewrite I occasionally suggest.
> Since the internal timer has a much higher resoloution than the RTC
> timers, but the resoloution at which it is used is lower than the RTC
> timers, I once again suggest moving the main clock off to an RTC to
> free up the internal time for one-shot use ...like running timer
> events at a 20k rate for short periods of time as interval timer
> events.

I've suggested this too, but I no longer think it's a good idea.  You
can't read the internal counters of the RTC, so it is inconvenient to
implement gettimeofday() using it.  You would have to combine the RTC
tick with the internal counter of the 8254 timer, and the book-
keeping for this would probably be slower and more complicated than 
using the 8254 timer for everything.

I've also suggested reprogramming the 8254 timer to support sub-
millisecond resolution for timeouts.  This would make it very easy
to attach new high frequency interrupt handlers to the clock
interrupt.  However, the extra overhead for the timeout mechanism
would be unacceptable at an interrupt rate of 20 KHz.

Bruce

------------------------------------------------------------------------------