Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > TIL: The instruction after SEI can be executed before a pending IRQ is handled
2017-11-07 15:56
Krill

Registered: Apr 2002
Posts: 2804
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!
 
... 92 posts hidden. Click here to view all posts....
 
2017-11-15 14:05
Oswald

Registered: Apr 2002
Posts: 5007
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.."
2017-11-15 14:21
Krill

Registered: Apr 2002
Posts: 2804
I was referring to Copyfault's last question in post #85.
2017-11-15 15:38
MagerValp

Registered: Dec 2001
Posts: 1055
Quote: Quoting MagerValp
If 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.
2017-11-15 16:10
Krill

Registered: Apr 2002
Posts: 2804
Quoting MagerValp
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.
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.
2017-11-15 16:30
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.
2017-11-15 21:44
MagerValp

Registered: Dec 2001
Posts: 1055
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.
2017-11-17 22:07
Copyfault

Registered: Dec 2001
Posts: 466
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 | 11 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
hedning/G★P
t0m3000/ibex-crew
algorithm
ϵʟʞ/ₐтₐ
Kickback
celticdesign/G★P/M..
jmin
Didi/Laxity
Mason/Unicess
Low Spirit
Slimex
Freeze/Blazon
Martin Piper
iceout/Avatar/HF
jcompton
Guests online: 345
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Graphicians
1 Sulevi  (10)
2 Mirage  (9.8)
3 Lobo  (9.7)
4 Mikael  (9.7)
5 Archmage  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.061 sec.