| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Trig raster irq with sprites enabled.
This is the scenario:
- stable irq by raster polling + inverted cia timer
- sprites 3 to 7 enabled moving on y axis
- first value read from dc04 is $30
- irp triggered on no badline
i can stabilize irq correctly, without sprites, using a table of values 0-7 starting from offset $30 going backwards in table and reading these values accordingly with dc04 to set bpl branch offset.
I thougth that to compensate also sprites delay, i need to rebuild table considering also cycles fetched at line start by sprites data.
I calculated 3 cycles of BA setup + 2x4 cycles for sprite data = 11 cycles.
Rebuilt table with values $12 - 00, of course starting at offset $30 and added relative cmp #$c9 to adjust bpl targets with new values.
Still have perfect stable raster, but first opcode cycles after stabilization is executed forward or backward even spriter are on trigger line or not.
How can i do to correctly compensate cycles stoled by sprites?
What i'm missing? |
|
... 2 posts hidden. Click here to view all posts....
|
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
sorry, i mean 4 sprites 4-7 %11110000 in d015.
However code is 'shifted' proportionally with number of sprites on trigger line. |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Quoting Freshness79
The maximum delay should be 10 cycles (2x5): if sprites 3 or 4 are on BA goes low 3 or respectively 1 cycles before IRQ is triggered.
If i use a too big value for delay compensation isn't possible that this cause only a fixed delay in execution but not a delay related to sprites position/number? |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
Still 10 cycles: in worst case you have (4x2) + 3-1
- (4) # of sprites
- (3) BA low
- (-1) first BA-low cycle is executed on preceeding line
If you use a delay >=10 you're safe. |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Quoting Freshness79
If you use a delay >=10 you're safe.
Actually i'm using 7 cycles for jitter compensation + 12 for sprites, but putting just 1 sprite over trigger line cause that code after stabilization is executed some cycles after the position without sprite.
And i can't understand what i'm missing... |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
Hmm... well, I wasnt right about not taking into account the first BA cycle (the one in preceeding line).
Actually you need to consider it as it may be involved in retarding last instruction.
So:
+ 2x4 (sprite)
+ 3 (BA low)
+ 7 (IRQ instruction)
+ 8 (max illegal opcode lenght - DCP)
=> 26
|
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Quoting Freshness79Hmm... well, I wasnt right about not taking into account the first BA cycle (the one in preceeding line).
Actually you need to consider it as it may be involved in retarding last instruction.
So:
+ 2x4 (sprite)
+ 3 (BA low)
+ 7 (IRQ instruction)
+ 8 (max illegal opcode lenght - DCP)
=> 26
Routine init setup dc04 at line start using value $3e.
Irq code start with sta/x/y zp taking 7 cycles for irq instruction + 3x3 to store regs = 9 = 15.
In fact dc04 is $30 exactly $0f from start.
Lda $dc04 read real value after 4 cycles from where is executed, but this is compesated by the store instruction in init routine that start timer with same delay.
Starting from this value we start to add cycles to compensate jitter and sprites.
I do not use illegal opcodes so we can subtract 1 from your total.
25 - 7 = 18 cycles = 1 cycle less mine.
But i still missing something... |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Quoting Freshness79Hmm... well, I wasnt right about not taking into account the first BA cycle (the one in preceeding line).
Actually you need to consider it as it may be involved in retarding last instruction.
So:
+ 2x4 (sprite)
+ 3 (BA low)
+ 7 (IRQ instruction)
+ 8 (max illegal opcode lenght - DCP)
=> 26
|
| |
Pixman
Account closed
Registered: Dec 2001
Posts: 42 |
Btw, the sprites doesn't always use the same cycle-length when different sprites (0, 5, 7 for example) activated on a raster line.
I read a good article on this, goes heavily into timing and sprites: |
| |
lft
Registered: Jul 2007
Posts: 369 |
Don't know if you considered this already, but if the IRQ happens while the CPU is stalled (due to sprite fetch right at the rasterline switchover, can't remember if it's sprite 2 or 3 causing it), then the total latency is one cycle less than what you'd otherwise expect. It seems the 6510 performs the first step of IRQ processing (probably synchronising the signal) even though it is stalled. |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Lft... interesting.
I suppose that the use of the word "halted", while the processor waits for the vic leave the bus free, don't mean really "stopped", but more likely, "waiting".
If "some strange" happens while CPU "wait", maybe -internally- something can be done.
Accordingly with
http://wiki.nesdev.com/w/index.php/CPU_interrupts
(IRQ and NMI tick-by-tick execution)
"1 PC R fetch opcode (and discard it - $00 (BRK) is forced into the opcode register instead)"
could be that "no real memory access" is done but, instead, some kind of "virtual bus access" that in fact it does not happen and "force" $00 into the opcode register.
At the same time the vic accessing the bus.
If my theory is correct, however, this should happen for every IRQ that happens during a badline/sprite fetch... |
| Previous - 1 | 2 - Next |
