CIAB A-timer interrupt confusion?

[hooverphonique]

Originally Posted by ross

But this usually works properly (every other CIA IRQ6 that doesn't matter is cleaned up and so for PAULA):

 btst #0,ICR(ciab)
 beq.b .x
...

.x
 move.w #$2000,INTREQ
 rte

That example still loses other cia int flags - I think you should do this if you care about multiple flags:

 move.b ICR(ciab),d0
 btst #0,d0
 beq .x
...
 btst #1,d0
 beq .x
...
.x
 move.w #$2000,INTREQ
 rte

[ross]

Originally Posted by hooverphonique

That example still loses other cia int flags

That's right, that's exactly the purpose in the case of testing a single CIA source and ignoring all the others.
It's the only case where the direct register test makes sense and that's why I put it

I think you should do this if you care about multiple flags

Not fully right, you need a sequential test

[Jobbo]

Most code I've seen will acknowledge the intreq as soon as possible. It's clear thought that it needs to be after the cia acknowledgement.

However, in your example if the code in the handler takes some significant amount of time what is the consequence of waiting until the end to clear intreq?

In more general cases I would have thought there is some chance you will miss an interrupt or handle it incorrectly?

I'm fuzzy on what happens when an interrupt happens during handling of an existing interrupt of the same level.

[ross]

Originally Posted by Jobbo

Most code I've seen will acknowledge the intreq as soon as possible. It's clear thought that it needs to be after the cia acknowledgement.

However, in your example if the code in the handler takes some significant amount of time what is the consequence of waiting until the end to clear intreq?

In more general cases I would have thought there is some chance you will miss an interrupt or handle it incorrectly?

I'm fuzzy on what happens when an interrupt happens during handling of an existing interrupt of the same level.

Usually nothing changes because it is almost impossible for the same IRQ to arrive before you have finished the management code (if this happens it means that higher level IRQs have taken control and are executing code that lasts really long..., the same for the code of your own routine; in case it would go completely rethought the IRQ scheduler..).

Also in the case of the CIA you need double acknoledment (ICR re-set itself) so the problem never arises.
But take for example a VBI IRQ3 running code for more than 20ms and you write INTREQ at the end of the routine.
What's up? You simply missed an IRQ, but maybe it was just what you wanted

[Jobbo]

Thanks Ross

That makes sense and I think my understanding is accurate.

It's really great to have you and others on here to answer questions about these details!

[Wepl]

Originally Posted by ross

 btst #0,ICR(ciab)
 beq.b .x
...

.x
 move.w #$2000,INTREQ
 rte

For the 68040/68060 there has to be at least one additional cia/custom access between clearing intreq and rte!
Otherwise the IPL lines may still be unchanged and the same interrupt is triggered again.

[ross]

Originally Posted by Wepl

For the 68040/68060 there has to be at least one additional cia/custom access between clearing intreq and rte!
Otherwise the IPL lines may still be unchanged and the same interrupt is triggered again.

Of course, I just put simplified code to give the idea of the procedure

[mc6809e]

Originally Posted by Wepl

For the 68040/68060 there has to be at least one additional cia/custom access between clearing intreq and rte!
Otherwise the IPL lines may still be unchanged and the same interrupt is triggered again.

Pointless microoptimization:

move.l #$02000000, INTREQ

[ross]

Originally Posted by mc6809e

Pointless microoptimization:

move.l #$20000000, INTREQ

Nice

[leonard]

just read this interesting thread. I'm a bit surprised. does it mean LSP (the cia versionà is entering the CIA interrupt code two times instead of 1? Or is it potentially happening on specific amiga configuration? ( CPU, memory etc). I never noticed entering CIA handler two times instead of one when using winuae debugger. ( but maybe I miss something )

[paraj]

Originally Posted by leonard

just read this interesting thread. I'm a bit surprised. does it mean LSP (the cia versionà is entering the CIA interrupt code two times instead of 1? Or is it potentially happening on specific amiga configuration? ( CPU, memory etc). I never noticed entering CIA handler two times instead of one when using winuae debugger. ( but maybe I miss something )

The interrupt handler will run twice, but the second time it'll notice that no CIA IRQ has actually been triggered, so depending on what you mean by "CIA handler" that won't be called twice. I.e.

InterruptHandler:
    move.w    #$2000,$dff09c  ; runs twice
    btst.b    #0,$bfdd00 ; so does this 
    beq.s    .skipa  ; and this 
 ; but not this part
.skipa:
    rte ; runs twice

[leonard]

Originally Posted by paraj

The interrupt handler will run twice

Damn I just checked and you're right interrupt occurs as soon as RTE exits. ( of course the btst/beq early out but still interrupts occurs two times!

Thanks for heads up, I'll fix the CIA version of LSP