Bug in the 6525 chip / CBM-II KERNAL

A strange behavior of my CBM-II has been plaguing me for months. When
working with the 8088 card, resetting the computer would leave it in an
unusable state - the startup banner would show up, but the computer
would not respond to the keyboard. It would happen randomly, mostly when
the 8088 software was waiting for the keyboard input.

Finally I became fed up with this, so I fired up the oscilloscope to see
what's going on. As you know, the TPI chip is responsible for handling
and prioritizing the interrupts in the system. And the 8088 uses IRQ3 to
request services from the 6509.

Apparently, if the reset signal comes when the 6509 is servicing IRQ
from the 8088, after reset there are no interrupts at all. This means
there is no 50 Hz interrupt to read the keyboard. And when the 8088 is
polling the keyboard, it calls the 6509 all the time, so there was a big
probability that the machine would end up in this state. Of course it
could also happen in other circumstances, for example when writing to
the screen and doing whatever else the 8088 needs the 6509 for.

But why are there no interrupts? It appears that the TPI chip requires a
specific sequence of operations in order to service and prioritize the
interrupts. The interrupt service routine must read register 7 in the
beginning and write to this register when it is done, in order to
re-trigger lower priority interrupts which could have arrived in the
meantime. Otherwise the chip will not know that the higher priority
interrupt has already been serviced.

And here comes the bug in the chip: the interrupt priority latch is NOT
reset when the chip receives the reset signal [*]. Therefore, if the
chip is reset when the CPU is servicing an interrupt of a certain
priority, then after the reset all the lower priority interrupts will
not be arriving. And so it happens that the 8088 interrupt has higher
priority then the 50Hz interrupt (and also tape and IEE-488 SRQ
interrupts, for all that it matters).

This also means that theoretically, this situation could happen on a
machine without the 8088 card too, because there is yet another IRQ with
even higher priority: the ACIA interrupt. So if you are sending tons of
data over the RS-232 port and get into the habit of resetting your
computer in the middle of the transmission, you can also end up with an
unresponsive computer. The chances of this are extremely low though, as
the code servicing the ACIA IRQ is very short.

This is probably why it did not occur to the KERNAL authors that the TPI
chip is buggy and requires workaround code. The code is simple: just
write anything to $DE07 to reset the interrupt priority queue.

[*] I consider this a bug in the chip because (a) all other things in
the chip are reset, so why not this latch? and (b) because it is not
described in the datasheet. Quite the contrary, the datasheet claims
that ALL internal registers are reset, which is clearly not the case.