Let me see. Assuming that we push A to the stack during abort interrupt handling and then pull it back again, we return with the old status of of channel A, and have no idea what has happened in the meantime. For example, if the FIFO was not full, we'll still think it is not full, and BIT immediate will give us the z flag for the old value. However, depending on what happened in the meantime, the FIFO could be anything by now. We need to make sure that the handler always gets the current status of channel A by protecting this part from interrupts.

I, ah, think.

Exactly. If you abort in code that manages I/O devices there's no telling what will happen when you re-execute the aborted instruction, since as you surmised, the condition being tested could have changed during the servicing of the abort interrupt.


You can't "protect" your code from an abort interrupt except by somehow forcing ABORTB to stay high no matter what. An abort is non-maskable and is the top dog in the 65C816 interrupt kennel.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, that was what that paragraph was meant to say, we can't use ABORT.

Whole thing sounds fun. But first computer needs to be done first!

It's an interesting thread that Garth has just linked to. I didn't see any implementation of this here so thought I'd show a way I've done it for a similar purpose - this is to implement accurate split screen on a BBC Micro, using a VIA timer to wait until a point somewhat earlier than the target time and then a loop in the ISR to wait for an exact time point:


In this context, at "topstart" a VIA Timer 1 interrupt has just fired and "time2-time1" is the value that was in the latches, and loaded into the timer at the time of the interrupt. "timerbias" is a small value, e.g. 10, used to make the interrupts occur slightly early so that latency in the interrupt can be tolerated more or less. If an interrupt was being serviced when the time elapsed for example then some of this tolerance would be used up. (Looking back, 10 seems a really small number so I might have misremembered this bit. )

So A gets loaded with a value we'd like to see on T1, and "timersync" compares it against the current count in T1 and adds a variable delay so that by its end we are at a consistent offset from that time point.

It's worth noting that the VIAs in the BBC Micro are clocked at half of the usual CPU frequency, and any access to them aligns the CPU with that slower clock. So this loop actually has to wait for twice as many CPU cycles than the T1 difference that was calculated. (Edit - I suspect adding an extra "LSR" and "BCS P%+2" after line 1550 would make it work for cases where the VIA shares the usual CPU clock.)

If you're interested in the wider use case for this or the rest of the code, please see here: https://stardot.org.uk/forums/viewtopic ... 12#p356012