I have problems using the mouse in parallel to the MockingBoard on my IIgs (ROM 01). It seems like there is a conflict of interrupts toggled either by the mouse or the mockingboard. Is there a chance to detect if the current interrupt was toggled by the
mouse or not? Any RAM address I can check if the mouse interrupt is active - so I may exit my own interrupt hanlder for the MockingBoard?

Thx for any advice!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Yes, read $7F8+mouse slot to determine the interrupt source.
If &8 != 0 then it's VBL
If &4 != 0 then it's a mouse button
if &2 != 0 then it's a mouse move.
If the byte is zero then it wasn't the mouse that triggered.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thx for your advice! I have tried to set the mouse to polling mode and disable interrupts. Everything works fine until I start the timer of the mockingboard for calling my interrupt handler. Then the system hangs.I replaced my interrupt handler with an
empty stub (just an RTI) to cancel out any effects of my interrupt code but even that did not work. I am wondering what really happens when the MockingBoard triggers an IRQ and leads to the system hang? If I disable the mouse port on Slot 4 (Your Card)
the MockingBoard works as expected. Hmmmm....


qkumba schrieb am Sonntag, 27. Februar 2022 um 18:03:43 UTC+1:

Yes, read $7F8+mouse slot to determine the interrupt source.
If &8 != 0 then it's VBL
If &4 != 0 then it's a mouse button
if &2 != 0 then it's a mouse move.
If the byte is zero then it wasn't the mouse that triggered.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Marc,

Maybe there's a misunderstanding how 65xx IRQs work...

The 65xx IRQ is level-triggered. That means that an empty IRQ handler
results in the IRQ still being asserted when it returns. The RTI
instruction restores the IRQ mask so the 65xx "sees" the IRQ again and re-enters the IRQ handler. Therefore the foreground program has no way to advance - the machine "hangs".

So an IRQ handler _MUST_ do "something" about the hardware that asserted
the IRQ making that hardware to de-assert the IRQ.

If there are several potential IRQ sources, the IRQ handler _MUST_ do two things before returning:

1. Find out which hardware asserted the IRQ.
2. Make that hardware de-assert the IRQ.

Usually the IRQ handler will additionally interact with the hardware in question to do its actual business logic. But in contrast, the 1.) and 2.) above are obligatory housekeeping tasks to keep the whole thing running.

Regards,
Oliver

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)