Mice and mouse queues...

[mk79]

There is no defined interface nor documentation, drivers write directly into the driver variables.

I think it would be of general interest where to find those variables within the driver definition block.
Can the PE variables be updated any time, or is there a synchronisation?

Depends on the variable I guess. Some can be updated during a hardware interrupt, the mouse increments for example, many others can and are updated during a poll interrupt.

If I can find the variables, I hope my rusted assembler knowledge is still sufficient.
(Maybe it can also be seen in the Sermouse sources, if they are available somewhere?)

No worries, you'll probably still need your assembler knowledge to debug this I took the Q68 mouse code out of SMSQ/E (which is interrupt based), made the data handling a bit cleaner, and wrote the whole setup stuff for it. But I wrote this mostly from scratch and it is completely untested, so some debugging may be required. The code to get to the CON variables is of course included, too. It does assemble without errors at least I have commented out the mouse wheel code for now as it uses some SMSQ/E specific variable and I'm too lazy to think about how to do it on QDOS. But that is a luxury problem I think.

[Peter]

Thank you. It just crashes, even if I don't link the interrupt routine, so it must be something Q68-independant. I'm not familiar with the SMSQ/E style names, so I didn't understand much yet. More complex than I hoped. Except the mouse specific stuff which I remember from the time I helped Wolfgang to write it.

I've made the code independent from the SMSQ/E sources, so it compiles stand-alone. Posting it back here, in case someone else interested in Q68 Minerva wants to try:

mouse_asm.zip

(2.81 KiB) Downloaded 120 times

[ppe]

The code to get to the CON variables is of course included, too.

Many thanks for taking the time to post the example!

[dilwyn]

Thanks everyone, so good to see all this development work still going on for QL and related systems.

[dden]

Thanks everyone, so good to see all this development work still going on for QL and related systems.

Yes, I agree Dylwin. Having been out of action for a few months after a fall at home (I can't sit at a computer for long because of the pain), it's great to be able to follow the developments on the QL scene even though I can't participate much. Thank you everyone.

[vanpeebles]

Thanks everyone, so good to see all this development work still going on for QL and related systems.

Yes, I agree Dylwin. Having been out of action for a few months after a fall at home (I can't sit at a computer for long because of the pain), it's great to be able to follow the developments on the QL scene even though I can't participate much. Thank you everyone.

Get well soon

[Peter]

Many thanks for taking the time to post the example!

Keep in mind it is not working, so better not use as example until I've debugged it.
Probably I can not look into this before Monday.

[mk79]

Just exchange the first two "a6" with "a5" and the setup code is fine. Can't debug the interrupt handler for lack of hardware.

[Peter]

It looks something is wrong in the code that links the interrupt routine or the address gets corrupted somehow. The interrupt handler is never reached, and I don't see why that's hardware specific. If I replace the handler by empty code, just turning on the LED, and enable the mouse interrupt, I get a crash as soon as I move the mouse, but no LED. (I'd prefer the routine in the polled list instead of using interrupt later on, but that's minor.) I hope to have a closer look on Monday.

[Peter]

Update: I wrote the driver from scratch in C and it basically worked with a polled or scheduled task routine, but not with an interrupt routine.
Like the assembler driver, the interrupt routine is not reached, but system hangs when the mouse is moved and the interrupt fires.

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.