The first thing to remember is that due to the limitations of a 48-pin case, the 68008 used in the QL has only 2 interrupt pins, but one of them is bonded internally to two inputs, so there is IPL0/2L and IPL1L. The pins are active LOW. IPL0/2 is a bit of a misnomer, as IPL2/0 would have been more intuitive - this pin generates the higher interrupt levels with respect to IPL1L.
Therefore, on the QL interrupt levels 2 (IPL1L = L), 5 (IPL2/0 = L) and 7 (NMI) (both IPL lines = L) are implemented.
Now things get complicated because the 8302 ULA only has one interrupt output pin, and it is tied to IPL1L. The IPC has 2 pins tied to an interrupt line each. The problem is that the 8302 is not aware of the IPC pins so strange combinations can happen which must be taken care of in the software.
As far as I remember, CTRL-ALT 2, 5 and 7 are all implemented in the IPC (though this may depend on the version), and were used in some sort of debug mode to cause the corresponding level interrupts. Other than that, ALL normally used interrupts on the QL are level 2, and are generated by the 8302. Because the 68k CPU is level sensitive as interrupts go, when an interrupt is handled, part of the handler must find out what the actual interrupt source was, and clear and handle that interrupt. Not clearing it (via the already mentioned interrupt register in the 8302) will just cause re-interrupting the CPU as soon as it comes out of interrupt processing.
Here is where things get complicated - the IPC communications are also handled via interrupt. Hence, when something like CTRL-ALT-7 occurs, if the IPC resets itself, there might be an interrupt condition left hanging inside the 8302, which needs to be cleared 'blindly'. The reason for this is the IPC sets both IPL lines low and waits for a while to insure the CPU recognizes them. However, because there is no way to mask interrupt level 7 (except implicitly when the CPU enters the interrupt 7 handler), it may well be expected that the interrupt handler may be invoked repeatedly while the IPC keeps the interrupt lines low, as there is no way to tell it (easily) to reset them high unless the IPC is re-initialized in the handler routine (which will release the interrupt lines).
That being said, things are much more complicated with interrupt level 5. This is normally ignored by the OS but because (again) the 8302 is not aware of the IPL lines on the IPC, under certain circumstances a level 2 interrupt can be generated (say, if the MDV is spinning or frame interrupt occurs) which will make the 8302 pull down the IPL1 line indicating it wants a level 2 interrupt serviced, but because the IPC might be keeping IPL2/0 low, this will now turn into a level 7 interrupt - and make a mess.
It may well be possible (though I have not tested this) that key roll-over (for example CTRL-ALT pressed, while pressing 4 and 5 simultaneously) may result in the above condition as CTRL-ALT-4 is a regular key-press and will be signaled via IPC comms through 8302 IPL1, and then IPL0/2 will occur when 5 being pressed is detected.
The main problem here is within the IPC, the fact it re-initializes. Unfortunately I have no idea how Hermes does it (no doubt much more clever), but a look into Minerva code might shed some light.
It is a pity the interrupt levels are not properly priority encoded, having a well controlled higher priority and a non-maskable interrupt would be a nice addition to the OS.
Last edited by Nasta
on Fri Nov 17, 2017 12:33 pm, edited 1 time in total.