> Yes, I have thought of this also. But the RTC is more limited in
> that it only allows intervals that is the 32768 Khz clock
> diveded by some power of two,

BTW, divisors 1 and 2 don't work on my system,  so the maximum
interrupt rate is 8192 Hz.  Is this normal?  I wish my system
could keep up with 32768 KHz :-).

> that could give us a timer of 64
> or 128 Hz, this is a somewhat "unusual" HZ value, but I think
> taht should be OK.

Yes, provided gettimeofday() can be implemented.  The system uses
microseconds counters for almost everything, and the resolution
is closer to microseconds than to ticks.

> This second thing is that the RTC interrupt
> is at priority 2, that is after TIMER1, keyboard then RTC. That
> could be rearranged though, leaving TIMER1 and keyboard at the
> lowest priority.....

It is already rearranged, leaving things on the slave IRQ at the
lowest priorities, the keyboard on the next lowest, and TIMER1
on the next lowest.  However, the hardware priorities are almost
irrelevant if no fast interrupt handlers are involved.  The
software priorities (highmask, ttymask, ...) control everything
except whethere there is an extra few usec of latency when two
interrupts occur at the "same" time.

Since the current clock interrupt handler has to run at the
"highest" priority, there is no room for another clock priority,
except by carefully coding the new handler to run as a fast
interrupt handler so that it runs at higher than the highest
priority :-).  This is probably the right approach.

Bruce

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