| |
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....
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
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: 478 |
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: 11386 |
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: 5094 |
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. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Remember in the movie Magnolia, when the kid is watching as frogs fall from the sky? "This happens. This is something that happens."
Today I had this weird crash that would go away whenever I changed something. I finally tracked it down. My decruncher was reading a bitfield by shifting a byte in memory, in a loop. Something like:
loop
asl memory
rol
dey
bne loop
A raster interrupt occurred during the branch instruction, just like we discussed here, so it was delayed until after the shift instruction. This is the maximum delay if we only use legal opcodes.
Meanwhile, my raster interrupt was moving along with a border sprite, so it happened to be on rasterline 0 at this exact moment. Therefore, the interrupt was first delayed by one cycle (because rasterline 0), and then an additional eight cycles for the bne+asl combo.
The jitter compensation code was reading a timer that is counting down 8,8,7,...,1 that would normally be in the range 1..7, corresponding to the expected range of interrupt latencies. The value is EORed with 7 and stored into a branch instruction followed by a clockslide. The extra latency made the timer return 8; the branch offset became 15 and the program crashed.
As soon as I changed anything, anywhere, the crunched data would come out a little differently, and the interrupt on rasterline 0 wouldn't strike exactly on that Achilles' heel. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Upped my old test prog here: Cycle Jitter TestProg. I have to admit that I was not motivated to include nmi irqs so this still needs a suitable test suite.
Quoting Flavioweb
...
-EDIT-
Seems that 10c jitter only occurs on raster line 0.
In other lines max jitter is 9c.
...
Hmm, in my routine the values read from $dc04 lie between $10 and $17, giving eight different values. In line 0 it's clear that there's another cycle offset, but for the other lines I'm not sure if you really have _nine_ different jitter values??? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I registered the _nine_ cycles when, using this loop
LOOP
INC $FFFF,X
DEX
BNE LOOP
the first BNE cycle was executed on last cycle of previous raster line where irq is triggered. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
