| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Raster line cycle 0 != cycle where raster irq is triggered?
I'm writing a raster irq routine where using this loop
lda #rasterline
cmp $d012
bne *-3
and the polling raster method to set up cia timer for raster stabilization.
During my debug section, on pal machine, i noticed that after my polling routine, if i put code to reach rasterline-after-polling+1 on 4th cycle of a lda $d012, i need 64 cycles in total.
This is perfect: 63 cycles of current line + 1 cycle in new line.
But if i try, on the line where raster irq is triggered, to reach next line, i have to use only about 56 cycles, but from raster trigger line+2 to +3 i must use 63 cycles in total again.
No code outside irq, of course.
Also taking care about 3 cycles jitter of an endless loop, this mean that first cycle of first opcode in irq routine isn't executed near first cycle of rasterline, but about 5-6 cycles after.
Or isn't it? |
|
... 1 post hidden. Click here to view all posts....
|
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
so it's correct if i say that on rasterline where irq is triggered, there are only 56 cycles available,
and from these cycles we need to subtract also the jitter before first opcode of irq routine it's executed? |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Yes, I suppose you could put it that way if you like. Jitter is separate from the cycles consumed by the IRQ stack pushing etc that Graham mention. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
ok. I understand.
I know that those 2 delays are caused by 2 different things.
I just wanted to know if this 7 cycles delay i found using my routine exist, or i caused it by wrong coding...
But seems that exist...
=) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
The IRQ is triggered on cycle 0 (naturally depending on which cycle you define as 0
:), it then takes 2-9 cycles for the current instruction to finish executing, then it takes 7 cycles for the CPU to save status and PC registers and jump to the IRQ vector. This leaves you 47 cycles left on the rasterline where the IRQ was triggered. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: The IRQ is triggered on cycle 0 (naturally depending on which cycle you define as 0
:), it then takes 2-9 cycles for the current instruction to finish executing, then it takes 7 cycles for the CPU to save status and PC registers and jump to the IRQ vector. This leaves you 47 cycles left on the rasterline where the IRQ was triggered.
My definition of "cycle 0" in a PAL system is "that cycle after wich there are other 62 cycles before reaching new raster line".
Said this, in your post you consider a jitter of 9 cycles, that include also illegal opcodes, right?
So: 9+7 (worst case) = 16 = 63-16 = 47.
9 cycles "before" those "47" are jitter, so they may be or not be, but the "7 cycles for the CPU to save status and PC registers and jump to the IRQ vector" are -fixed-.
So 47+9 = 56 and assuming a minimum of 2 cycles of jitter, at maximun (best case) 54 cycles are available on line where IRQ is triggered.
Concluding:
best case 54 cycles
worst case 47 cycles available on raster trigger line.
what i thought is correct? |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
No, 2-9 cycles of delay means 7 cycles of jitter, and does not consider illegal opcodes. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: No, 2-9 cycles of delay means 7 cycles of jitter, and does not consider illegal opcodes.
...mumble...mumble...
How do you reach the '47 cycles' available?
Irq triggered on cycle 0
7 cycles jitter in worst case
7 cycles for saving etc...
63 - 14 = 49 availables.
What are others 2 cycles used for? |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
You need to consider delays: the jitter is 7 but the delay, as Magervalp's written, is 2-9. Add to this the delay of 7 due to IRQ call and you get a total of 9-16 cycles which, in turn, means you get 47 (worst case, delay of 16) to 54 (best case delay of 9) free cycles per line (no badline, no sprites). |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
these 2 cycles then come from the fact that cpu goes to irq if it is triggered almost before last 2 cycles of currently executed opcode, otherwise also next opcode is executed...
right? |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
Yes, you can consider a fixed delay of 2 cycles due to the way 6510 schedules interrupts in the execution flow.
Once an irq is called 2 cycles are *always* skipped then it depends on where the cpu finds itself and you get the overmentioned 0-7 delay. As MaverValp's stated you may consider 0-8 with illegal opcodes (DCP x indexed IIRC). |
| Previous - 1 | 2 - Next |
