I ran into this when I started to work on a serial driver (which is still far from finished btw).Peter wrote: Q68 Minerva does not yet deal with the missing hardware implementation of PC.INTRE (bit 4) in PC.INTR, which is always inactive = 0.
I have implemented this bit in hardware now, and then my driver also works with interrupts. But I think this would better be fixed in Q68 Minerva, because FPGA updates requqire an adaptor or sending boards to Derek.
I first thought it's sufficient to act like the bit was always set. But it appears that Minerva re-uses the same vector address as level 2 autovec. for the non-OS traps. Jan, if you read this, please comment.
Minerva, like the legacy QDOS ROMs, checks the bits on PC.INTR, executes the appropriate handler and then clears the interrupt by writing to PC.INTR with the same bit that was set when it was read.
So, when an external interrupt occurs, it executes the external interrupt linked list and then writes the content of SV.PCINT to PC.INTR ORed with bit 4 set, which should clear the external interrupt.
Since the Q68 doesn't implement this bit, Minerva won't have a clue what to do with the interrupt and just return without clearing it.
If the Q68 doesn't implement bit 4 of PC.INTR then you have to redirect the INT2 vector to your own interrupt code and do the appropriate things if it's really caused by your hardware, including clearing the interrupt. If it's not caused by your hardware, then jump to Minerva's original handler's address (which you should have saved when installing your driver).
Fortunately, on the Q68 all the vectors are in writable RAM so it's easily redefinable. On the other hand, like you said, implementing bit 4 of PC.INTR would be a much cleaner solution...