| |
Hypnosis
Registered: Mar 2015
Posts: 36 |
Cycles to get into IRQ routine
How many cycles does it take from an IRQ trigger to the start of the IRQ routine, assuming the CPU finished the instruction when it triggers? It should be around 6-9 cycles but I'm not sure how many. |
|
... 53 posts hidden. Click here to view all posts....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1074 |
Quoting lftBut what about an infinite branch-to-self? Surely it can be interrupted? Has anybody investigated?
Of course. If I'm reading the 6502.org thread correctly the only gotcha is that if the IRQ is activated during cycle 3 of a taken branch it'll loop one more time before the IRQ handler is triggered, compared to an IRQ activating during other cycles.
Is there perhaps a test program in the VICE repo for this? |
| |
lft
Registered: Jul 2007
Posts: 369 |
This nesdev page is also interesting:
Quote:The branch instructions have more subtle interrupt polling behavior. Interrupts are always polled before the second CPU cycle (the operand fetch). Additionally, for taken branches that cross a page boundary, interrupts are polled before the PCH fixup cycle
This confirms the observed behaviour, but it doesn't explain the design rationale. My post is an attempt at that. |
| |
MagerValp
Registered: Dec 2001
Posts: 1074 |
Quoting lft@MagerValp: I'm not sure if that was a response to my post
No, that was a response to Oswald, your post happened while I was writing :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Quoting lftBut what about an infinite branch-to-self? Surely it can be interrupted? Has anybody investigated?
Of course. If I'm reading the 6502.org thread correctly the only gotcha is that if the IRQ is activated during cycle 3 of a taken branch it'll loop one more time before the IRQ handler is triggered, compared to an IRQ activating during other cycles.
Is there perhaps a test program in the VICE repo for this?
The best bet would be:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/int..
I don't remember if this particular case is tested.
These tests do not test very specific cases so it can be really hard to tell the root cause of what failed.
Should work in x64sc. |
| |
Copyfault
Registered: Dec 2001
Posts: 474 |
Isn't it amazing that this little 8-bit-bastard still keeps us busy finding explanations for its behaviour? I'm loving it!!!
My guess for an explanation of how those branches and the irqs are handled: wouldn't it be easiest (also in terms of transistors needed) to have a dedicated opcode pipe pc? This one is equal to the normal pc but will be set to the irq adress during an irq acknowledge. Now depending on the processed cycle there is an irq acknowledgment or not. During a socalled "opcode fetch cycles" the byte read from memory is fed to the instruction pipe thus it makes sense to prevent any "opcode pipe pc"-updates. Consequently, those opcode fetch cycles DO NOT acknowledge an irq.
If there's no opcode fetch, an irq can be acknowledged and the opcode pipe pc can be set to the irq adress. It might be a bit more complicated as the irq adress consists of two bytes and an update of such an "opcode pipe pc" would probably need at least two cycles, but the basic idea works for me.
I'd like to point to Jackassers findings again about jitter values larger than 8c when combining NMI and IRQ. A test prog for this case is badly needed, I'm sure my old one did not cope mixing of differnt irq types. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
protip: throw some test snippets at visual6502 - its an eye opener lots of the time :) |
| |
lft
Registered: Jul 2007
Posts: 369 |
Do they have support for interrupts now? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I found this:
http://visual6502.org/wiki/index.php?title=6502_Timing_of_Inter.. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
http://forum.6502.org/viewtopic.php?t=1634
interesting, so:
at *only* 3 cycle branches irq only happens after the next instruction. even if it is a branch to itself IRQ will happen during the next instruction.
"A branch may be a case a bit like an indexed write where the final instruction state must be reserved in case a page is crossed. In the case of a branch, the next instruction isn't known to have started until it's known that there's no page crossing. The following instruction after a taken branch doesn't have a normal first cycle. And so a taken branch doesn't have a 'final' state, and so it wouldn't be interruptible. Instead it begins the interrupt handler during T2, which means the NMI needs to enter the chip a bit earlier than the usual case in order to catch the window. We see that the other way around: the interrupt appears to have been deferred. " |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I wrote some code to test:
https://www.dropbox.com/sh/j7v66nnzflvv8l9/AADRjZG4Aa_y5SUMbCh2..
"branch_cross.prg" to test irq with branch crossing page boundary;
"branch_no_cross.prg" to test irq with branch not crossing the boundary;
"branch_test.s" the 64tass source to check for my mistakes.
I noticed that:
- when branch NOT cross the boundary, jitter reach 10 cycles.
- when branch cross boundary, jitter stay in 8 or less cycles.
My code just check if jitter is >= 10c then change border color.
This code works the same way both on rh and vice (x64) so i suppose the emu do it the right way.
I double checked for cycles delay count via code and via breakpoint in vice (at $0900 for no cross or $0a00 for cross boundary version) and i can see that main irq code start between 9 and 17 cycles for -no cross- version, and between 9 and 15 cycles for the "cross" version.
#1 (Trace exec 0900) 250 009
.C:0900 8D 28 09 STA $0928 - A:01 X:02 Y:00 SP:fc ..-..I.C 39465351
#1 (Trace exec 0900) 252 009
.C:0900 8D 28 09 STA $0928 - A:01 X:01 Y:00 SP:fc ..-..I.C 39465477
#1 (Trace exec 0900) 254 009
.C:0900 8D 28 09 STA $0928 - A:01 X:02 Y:00 SP:fc ..-..I.C 39465603
#1 (Trace exec 0900) 000 017
.C:0900 8D 28 09 STA $0928 - A:01 X:02 Y:00 SP:fc ..-..I.C 39469265
#2 (Stop on exec 0918) 000 047
.C:0918 8D 20 D0 STA $D020 - A:0A X:02 Y:00 SP:fc ..-..IZC 39469295
I did it properly or i did something wrong?
-EDIT-
Seems that 10c jitter only occurs on raster line 0.
In other lines max jitter is 9c.
-EDIT 2-
If IRQ is triggered on SECOND cycle of a taken branch opcode, the IRQ is delayed by one opcode.
If IRQ is triggered on FIRST cycle, IRQ is delayed by 3 cycles, in other words, executed just after branch opcode.
This means that:
An IRQ can be dalyed by 9 cycles if the taken loop is "branch opcode looping to a 7 cycles opcode" and IRQ were triggered on second cycle of branch opcode.
For a RASTER IRQ this condition (IRQ delayed by 10c) can happen only on raster line 0, because here IRQ is triggered on cycle 1. Usually, raster IRQ can be delayed by 9c if the first cycle of branch opcode were executed on last cycle of previous line. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
