> > 
> > Various drivers (mostly the scsi disk driver i believe) disables interrupts
> > and then calls delay() for various reasons.  This causes the clock to loose
> > time.
> 
> This is close.  One of the VIA1 interrupts is being used for timing.  The
> m86k interrupt structure is such that you have 7 interrupt priority
> levels honored in the hardware.  Higher levels mask interrupts from the
> same and lower levels.  So if you're running at level 2 due to a level 2
> interrupt, you will not receive other level 2 or any level 1 interrupts,
> but you might receive level 3-7 interrupts.  On the mac, level 1
> interrupts are from VIA1, level 2 from VIA2/RBV, level 4 from the SCC,
> and level 7 from the debugger (NMI) switch.  The SCSI and ethernet
> (NuBus) interrupts are on VIA2.  Most everything else is on VIA1.  If
> any interrupt handler is running, it's masked off the clock interrupts.

Another part of the problem is how we deal with software interrutps
and levels, like spltty, splbio (sp?) and others. Right now, most of them
mask hardware level 1 interrupts. So if we hang out at spltty for a while,
we loose the clock.

A better solution, IMHO, would be to impliment a true software interrupt
level handler. Hmm. Those words don't quite work, but my thought is
to add a whole bunch of interrupt levels below the hardware interrutps.

A first, crue, idea would be something like define spl1 through spl8
to be software levels (the CPU runs w/ interrupts enabled), and
spl9 through spl15 correspond to interrupts masked at level 1 through
7 (for splX, interrupt mask = X-8). It's gross, and probably impractical,
but it's an idea.

So then spltty (stop input to the tty subsytem), splnet (stop input to
the networking system ?), and splbio (stop input to block io system)
actually happen w/ hardware interrutps enabled. :-)

Other ports somehow manage to put a lot of software interrupt levels in
(according to comments in some of the psl.h's), so there should be
examples around somewhere.

> > Does any of this make sense?
> 
> Yes.  One option you didn't mention is to do a sort of software masking
> of interrupts and basically put all interrupts on the same priority
> level.  I don't think that that's a viable option--especially if the
> SCC is to keep up at all, but it's another option.

Eeewww!

On the origonal question (how to clear video interrupts), try debugging
what a live MacOS system does to clear interrupts. It's a bit gross
to do w/ Macsbugs, but it's doable. Just get the address pointed to by
the interrupt dispatch table for interrupt level 1, and start disassembling.
Also, you can use the logging capability (and something like Save A Tree
for 2-up printing) to get a hardcopy of the results.

Take care,

Bill