| |
Krill
Registered: Apr 2002
Posts: 2980 |
TIL: The instruction after SEI can be executed before a pending IRQ is handled
As described here: http://visual6502.org/wiki/index.php?title=6502_Timing_of_Inter..
I never knew this, after all those years, and thought i'd share this as a heads-up.
Thanks to Bubis for pointing it out to me! |
|
... 90 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting MagerValpIf simple stuff like this didn't work correctly in VICE there'd be tons of glitching demos Of course the general behaviour can easily be verified on the real thing and implemented in an emulator. But the question was something in the realm of 1-cycle delay or not, i.e., if an IRQ that is triggered pretty much at the exact cycle the IRQ mask is set would cause the CPU to execute the interrupt handler right away or only an instruction later. This requires a much more complicated setup to determine and verify. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
also, i was referring to the reset behaviour mostly :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I thought it was established that the instr is only fetched ?
"Since the succeeding opcode is merely fetched, and not executed, then the pipeline flushed and the interrupt handled, then the opcode re-fetched and finally executed.." |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I was referring to Copyfault's last question in post #85. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: Quoting MagerValpIf simple stuff like this didn't work correctly in VICE there'd be tons of glitching demos Of course the general behaviour can easily be verified on the real thing and implemented in an emulator. But the question was something in the realm of 1-cycle delay or not, i.e., if an IRQ that is triggered pretty much at the exact cycle the IRQ mask is set would cause the CPU to execute the interrupt handler right away or only an instruction later. This requires a much more complicated setup to determine and verify.
Sure, and while it's an interesting question, we're then beyond the simple needs of an initial, unstable, raster IRQ setup. Whatever synchronization method you use for the stable IRQ will make it moot. I would still be very surprised if x64sc didn't emulate this particular detail accurately. I can't be arsed to build a test program for that detail right now anyway :)
Oh, and regarding Copyfault's question in #85, the VIC-II can trigger a raster IRQ during the sta $d01a instruction, so no, you're never guaranteed to execute the following instruction before the first IRQ. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting MagerValpthe VIC-II can trigger a raster IRQ during the sta $d01a instruction, so no, you're never guaranteed to execute the following instruction before the first IRQ. It wouldn't pull down the IRQ line going to the processor before the LSB of $d01a is set, though, and then at least i wouldn't know when exactly this takes effect in the form of executing the first instruction of the interrupt handler. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Just some idle thoughts: When sprites 3-7 are enabled, the earliest start of a raster interrupt handler happens nine cycles later than if those sprites are disabled. Not ten, which would be expected if the CPU responded immediately. So the first cycle of interrupt latency is due to something that happens in parallel to what the cpu is doing, and is unaffected by whether it's halted or running. It could be latching the signal, for instance.
So even if the interrupt is triggered by writing to d01a, at least one more cycle (fetching the next opcode) should happen before the main program is interrupted. And then it seems reasonable that the fetched instruction is executed. But the recent discussion makes me uncertain.
This should be tested. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Good points, and easy enough to test: pendingirq2.prg, same sequence of SYS calls as in comment #91. The instruction immediately following the sta $d01a, dey, is executed before the IRQ triggers (verified that VICE matches my C64). So this means that immediately writing the register in the VICE monitor with > d01a 01 doesn't match the behavior of sta $d01a, but I suppose that isn't too surprising.
It makes sense too - at least on the 65c02 IRQs are evaluated during the last cycle of the previous instruction, and what happens is that the next opcode is replaced by $00, forcing a BRK. NMOS 6502 presumably works the same. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
So my assumption was correct :)
Thanks to everyone for clarification, esp. to MagerValp for quickly mocking up a test prg. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
