Mice and mouse queues...

[janbredenbeek]

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.

I ran into this when I started to work on a serial driver (which is still far from finished btw).
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...

[mk79]

Maybe I don't understand the problem correctly, but SMSQ/E just checks for the frame interrupt and if it's not that, executes the external interrupt handlers no matter what. Why not just do that, too? I think it's too late to fix this in the FPGA code.

[Peter]

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.

If Minerva could actually clear this bit for external interrupts, it would lead to a race condition if some hardware (there could be several devices) fires the next interrupt at an unlucky time. The right way is to clear the bit when the hardware removes the request, which is how I implement it now and it works.

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, ...

Yes.

... which should clear the external interrupt.

I don't think so, but it's irrelevant for our issue.

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.

Yes, and since the hardware request is still there, it will cycle in an endless loop.

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).

That's of course what I also did, and it works. But I hate this workaround because a mere hardware reset without power-on does not invoke the bootloader and the vector would remain redirected.

On the other hand, like you said, implementing bit 4 of PC.INTR would be a much cleaner solution...

For the mouse driver I won't actually use interupts, because I find the scheduler task the best way. Works perfectly. (It seemed to me the PE would use the scheduler task anyway.)
So as long as the persons looking for a Q68 Minerva serial driver are okay with a hardware update, we could leave the OS untouched.

[Peter]

Maybe I don't understand the problem correctly, but SMSQ/E just checks for the frame interrupt and if it's not that, executes the external interrupt handlers no matter what.

For the Q68 this would be fine. Even also calling the external interrupt handlers on every frame interrupt is marginal overhead.

Why not just do that, too? I think it's too late to fix this in the FPGA code.

The problem I see is Minerva's re-use of code for TRAP 5..15 etc. which I have not fully understood. Even small code changes need to be done very carefully. (E.g. I don't want to risk debuggers using those TRAPs triggering external interrupt routines.)

[mk79]

Why not just do that, too? I think it's too late to fix this in the FPGA code.

The problem I see is Minerva's re-use of code for TRAP 5..15 etc. which I have not fully understood. Even small code changes need to be done very carefully. (E.g. I don't want to risk debuggers using those TRAPs triggering external interrupt routines.)

If you refer to ss_intrd, that is only executed when the trap is explicitly not redirected, so only on abnormal conditions.

Using the scheduler task is ok. Of course under load the scheduler will decay into the polled task. As I understand it the mouse update frequency would then be limited to 12/16Hz, which is a bit on the low side, but under normal conditions it should be smooth.

[Peter]

Using the scheduler task is ok. Of course under load the scheduler will decay into the polled task. As I understand it the mouse update frequency would then be limited to 12/16Hz, which is a bit on the low side, but under normal conditions it should be smooth.

Yes I know, but my practical experience on any hardware, and also under SMSQ/E, is that the mouse movement slows down below that rate under heavy load anyway.

Thanks again for your attempted assembler-written driver. Unfortunately my time spent debugging it has much exceeded rewriting from scratch in C68. So I'm not sure I'll continue that path. I'm pretty bad debugging assembler code I didn't write myself, and also it's a realtime routine.

I hope to publish my C-written driver soon, after adding some safety checks.

[janbredenbeek]

If Minerva could actually clear this bit for external interrupts, it would lead to a race condition if some hardware (there could be several devices) fires the next interrupt at an unlucky time. The right way is to clear the bit when the hardware removes the request, which is how I implement it now and it works.

I'm not sure if a BBQL will have the same behaviour when the EXTINTL line is deactivated. Of course, it is the responsibility of an external interrupt handler to clear its own device's interrupt. But I don't know if this would also reset bit 4 of PC.INTR, or an explicit clear action would be needed. It all depends on the logic in the 8302...

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).

That's of course what I also did, and it works. But I hate this workaround because a mere hardware reset without power-on does not invoke the bootloader and the vector would remain redirected.

That's an interesting issue. It would probably not be a problem if the external interrupt handler would be in extension ROM space, provided that you don't redirect an already redirected vector at initialisation.

[Peter]

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).

That's of course what I also did, and it works. But I hate this workaround because a mere hardware reset without power-on does not invoke the bootloader and the vector would remain redirected.

That's an interesting issue. It would probably not be a problem if the external interrupt handler would be in extension ROM space, provided that you don't redirect an already redirected vector at initialisation.

I don't even know if there is still a reset button on the Q68 Derek builds. Most, including myself only use power-on reset. Being able to reset without reloading the OS was mainly a development tool. So the practical relevance of my concern is not very high.

[Derek_Stewart]

Hi,

There was a reset button fitted to the first 9 Q68 boards produced. I stopped fitting the the reset switch because, the Reset signal did not reset the Q68 and load the boot loader. Thee piwer switch seemed the best solution.

The connections for the reset switch are on the PCB, unpopulated.

I have a bag of switches that could be fitted to the Q68 PCB.

[janbredenbeek]

I don't even know if there is still a reset button on the Q68 Derek builds. Most, including myself only use power-on reset. Being able to reset without reloading the OS was mainly a development tool. So the practical relevance of my concern is not very high.

And Minerva doesn't have a RESET command either
Besides, since Minerva and extension ROMs are in writable RAM, a warm reset after a crash might leave you with a corrupted OS.