Date : Mon, 15 Mar 2004 22:36:45 -0000
From : tom@...
Subject: Re: CLI then SEI
On 14 Mar 2004 at 23:22, Thomas Harte wrote:
>Therefore, as far as I can tell, a CLI/SEI pair should result in the
> following:
> 1) read cli instruction
> 2) read sei instruction, clear interrupt flag
> 3) spot pending interrupt, wait for end of sei to execute it
> 4) complete sei
I'd not noticed that bit of 64doc -- that would have saved me some
heartache. I was handling the IRQ at between points 2 and 3, counting
that as "after CLI" rather than "starting SEI" as I should have done.
And since the I flag was clear at that point, the CPU did took the
interrupt there and then, causing all the problems.
> Implied by that, shouldn't cli/sei (with interrupt pending) result in
> an interrupt in which the P left on the stack has the I flag set? In
> which case you get the 'interrupt after the instruction after'
> behaviour that Tom notes, whilst maintaining the behaviour jgh
> mentions (i.e. cli/sei used to let in a single interrupt) whilst
> suggesting a new emulator bug which might have been preventing Empire
> Strike Back from executing correctly?
Yes, I'm pretty sure that's exactly whan happens. That's what model-b
does now, anyway, and it seems to work (!); on a real Beeb, though, I
only checked the return address on the stack. But if I wasn't set in
the copy of P on the stack, you'd get the IRQ again straight after
RTI. I didn't get that in my test program, but rather one IRQ for
each CLI:SEI.
> Has the interrupt routine been checked to see that it isn't just
> trivially rejecting any interrupt that leaves a P with I set on the
> stack?
Empire Strikes Back is weird... it doesn't have its own IRQ handler.
Just uses the standard OS one. It doesn't check the stacked P other
than to see if B is set.
(Interestingly, now I've fixed this problem, Brian Jacks magically
started working, and Uridium doesn't randomly mess itself up any
more. So it seems this is helping more than just Empire Strikes
Back.)
--Tom