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 > Cycles to get into IRQ routine
2015-05-20 04:17
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....
 
2015-05-27 10:31
MagerValp

Registered: Dec 2001
Posts: 1078
Quoting lft
But 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?
2015-05-27 11:50
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.
2015-05-27 15:28
MagerValp

Registered: Dec 2001
Posts: 1078
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 :)
2015-05-27 16:17
tlr

Registered: Sep 2003
Posts: 1790
Quote: Quoting lft
But 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.
2015-05-27 19:54
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.
2015-05-27 19:56
chatGPZ

Registered: Dec 2001
Posts: 11386
protip: throw some test snippets at visual6502 - its an eye opener lots of the time :)
2015-05-27 21:01
lft

Registered: Jul 2007
Posts: 369
Do they have support for interrupts now?
2015-05-27 21:15
Flavioweb

Registered: Nov 2011
Posts: 463
I found this:
http://visual6502.org/wiki/index.php?title=6502_Timing_of_Inter..
2015-05-28 07:35
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. "
2015-05-28 10:30
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
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
Guests online: 108
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Swappers
1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.7)
4 Acidchild  (9.7)
5 Cash  (9.6)

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