Effects of SEI and CLI delayed by one opcode?

For discussing the 65xx hardware itself or electronics projects.
Post Reply
fachat
Posts: 1123
Joined: 05 Jul 2005
Location: near Heidelberg, Germany
Contact:

Effects of SEI and CLI delayed by one opcode?

Post by fachat »

Today I found an interesting post here http://www.commodore128.org/index.php?P ... icseen#new

It says that the effects of SEI and CLI are delayed by one opcode. I.e. the opcode after a SEI can be interrupted - and the author says that he (and the VICE emulator) does not interrupt the opcode after a CLI.

Well, I didn't know this fact, and these days I can probably try it with the visual6502 emulator. And thinking about the 6502 architecture, this seems plausible.

But the question in the post it seems is that the 8502, the 6502 derivative in the C64 seems to actually be able to interrupt the opcode after the CLI.

Anyone of you know this?

Cheers,
André
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Effects of SEI and CLI delayed by one opcode?

Post by BigDumbDinosaur »

fachat wrote:
Today I found an interesting post here http://www.commodore128.org/index.php?P ... icseen#new

It says that the effects of SEI and CLI are delayed by one opcode. I.e. the opcode after a SEI can be interrupted - and the author says that he (and the VICE emulator) does not interrupt the opcode after a CLI.

Well, I didn't know this fact, and these days I can probably try it with the visual6502 emulator. And thinking about the 6502 architecture, this seems plausible.

But the question in the post it seems is that the 8502, the 6502 derivative in the C64 seems to actually be able to interrupt the opcode after the CLI.

Anyone of you know this?

Cheers,
André
Here's my response to that question. In short, I've never heard of it. It could be errata in the 8502, but I wrote a lot of C-128 code in years past that tinkered with the interrupt handler (e.g., Clock-Calendar 128, which is entirely interrupt-driven). Surely I would have tripped over this anomaly if it did in fact exist.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
fachat
Posts: 1123
Joined: 05 Jul 2005
Location: near Heidelberg, Germany
Contact:

Post by fachat »

Hm, in fact even if IRQ goes low directly during the CLI, the opcode after the CLI is still executed, and only then the IRQ sequence is started!

See http://visual6502.org/JSSim/expert.html ... ogmore=irq

So the claim, that the effect of CLI is delayed by one opcode is verified by visual6502.

André
fachat
Posts: 1123
Joined: 05 Jul 2005
Location: near Heidelberg, Germany
Contact:

Post by fachat »

This link http://visual6502.org/JSSim/expert.html ... =0014&d=78 shows that although the SEI is fetched as part of the last cycle of the preceding INC zp, the interrupt routines is started when the interrupt happens mid way of T4 in the INC opcode.

This link http://visual6502.org/JSSim/expert.html ... =0014&d=78 shows that the IRQ is _not_ started when the interrupt happens midway T0 of SEI - but this link shows that half a cycle earlier, the IRQ _does_ happen: http://visual6502.org/JSSim/expert.html ... =0014&d=78
I.e. if the interrupt happens at the beginning of the SEI opcode, the interrupt still is executed, but not if the interrupt happens later, which counters the claim made in the original post.

But, there still may be differences in the 1MHz NMOS version compared to the 4MHz version used for visual6502, and between those and the 8502 version.

André
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Post by BigEd »

Nice work!
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Post by BigEd »

Hydrophilic has posted an update on that thread with an extensive analysis of the existing docs and the behaviour of visual6502:

http://www.commodore128.org/index.php?t ... 0#msg19270

(I think a common cause of difficulty is to ask questions like "in which cycle does the CPU decide to do X" or "in which cycle does the CPU care about X" because there could be several answers, depending on which mechanism within the CPU is under discussion. We've seen that the CPU may embark on interrupt handling because of IRQ but actually fetch the vectors according to NMI - the CPU is not a single entity.)
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Post by BigEd »

Hi André
I'm writing up a wiki article on interrupt handling - it's a minefield of details, so I'm not sure if it will ever be definitive, but a set of links to useful visual6502 simulations should be a resource.

Are you OK for me to use material from your posts?

Ed
fachat
Posts: 1123
Joined: 05 Jul 2005
Location: near Heidelberg, Germany
Contact:

Post by fachat »

BigEd wrote:
Are you OK for me to use material from your posts?

Ed
Yes, absolutely.

André
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Post by BigEd »

Thanks!
fachat
Posts: 1123
Joined: 05 Jul 2005
Location: near Heidelberg, Germany
Contact:

Post by fachat »

fachat wrote:
... shows that the IRQ is _not_ started when the interrupt happens midway T0 of SEI - but this link shows that half a cycle earlier, the IRQ _does_ happen: http://visual6502.org/JSSim/expert.html ... =0014&d=78
I.e. if the interrupt happens at the beginning of the SEI opcode, the interrupt still is executed, but not if the interrupt happens later, which counters the claim made in the original post
In a side note to this post. If you examine the log, you can see that the interrupt handling pushes a status register with the interrupt flag I _set_ in this case! Which is also faithfully restored by RTI to avoid any following interrupts.

I don't think any of the emulators does that :-)

André
Post Reply