| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
unexpected lost cycles (with sprites)
I'm trying to get a stable raster with the double irq method (I made it several times already) but it seems like the sprites or something else is stealing my cycles, even though they are way below my raster code. Here's the scenario:
first irq line 22, next irq 23, wobble check, line 24 we're stable. Here I do a bunch of stuff and setup the sprite Y position to the line number + 6 + value from $20 like:
lda $d012
clc
adc #6
adc $20
sta $d001
sta $d003
sta $d007
; i even started disabling sprites and enabling them just here to make sure.... still timing problems
lda #7
sta $d015
the value in $20 is always betwen 0 and 20, so the sprites are on lines (the code above starts at line 25) 31 - 51. Seems like there's no way for them to disrupt my timings in the lines 22/23/24. If I make them appear way below (replace adc #6 with let's say adc #50) it seems stable.
I'm looking in the vice monitor and see that the last instruction before nops in the first irq (cli) is on cycle 56 and then i get a nop on cycle 2 of the next line (and second irq after it). Seems like 7 cycles missing ? Any ideas ? |
|
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
7 cycles are just the time needed by cpu to "setup" an IRQ.
Push return address, processor status, read irq vector...
May be these your "lost cycles"? |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
adc $20
Perhaps ADC #$20?
Other than that, sprite 0 sucks when it comes to timing,
Edit: never mind, but sprite 0 can still really fuck up the timing. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Flavio is leading |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
While I didint think about what the cpu has to do to jump to the irq handler, I think it should happen latter. I mean, I can't even get one nop executed in the first irq where before I had plenty of them.
irq:
sta $10
stx $11
sty $12
lda #<irq2
ldx #>irq2
sta $fffe
stx $ffff
inc $d012
lda #1
sta $d019
tsx
cli
; bunch of nops so the next irq hits on a nop, but it seems like the irq hits before them
nop
nop
nop
nop
irq2:
txs
.... |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Yes...
CLI on cycle 56 clear Irq flag, then seems like irq is triggered immediatly, so cpu starts the next irq.
Cpu (better say bus) is halted by vic sprites fetch but internally cpu still setup things.
Just after bus release, execution continues with next irq, exactly just after CLI (maybe 1/2 cycles could be used by cpu after sprites fetch to read irq vector).
Should be something like this... |
| |
WVL
Registered: Mar 2002
Posts: 885 |
Are you on a badline perhaps? |
| |
Firehawk
Registered: Aug 2011
Posts: 31 |
Do remember that some sprites (0-4) steal cycles on the line before they are displayed. But my guess also is that you are on a badline.
Do note that if you use VICE, and stable the cycle this way on the first line of sprite display (or was it the line before, can't remember), then the number of cycles to wait before lda $d012, cmp $d012 differs (by one cycle) between x64 and x64sc (x64sc is the same as the real C64's I've tested on). |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
I'm on line 22 as I said which is in the top border. No badlines in the top and. bottom border right ? and the sprite is way below the raster code as I mentioned. I know it steals cycles one line before display, but this is at least 6 lines apart |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
If second irq is triggered immediatly after Cli, or there is an Irq condition true, or you have a pending irq somewhere...
Then the 7 cycles "delay" between cli and first irq opcode, is just the cpu setup time... even if is strange, because at least a 2 cycle opcode should be executed meanwhile (at least one nop). |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
I understand that, i just don't see how it's possible for me to have an interrupt pending. I have all interrupts disabled but the raster one. Look at the code, the previous I typed from memory, maybe I missed something.... ($d01a is always 1)
!macro next_irq .handler, .line{
lda #.line
sta $d012
lda #<.handler
sta $fffe
lda #>.handler
sta $ffff
lda #1
sta $d019
}
sprite_scroll = $20
stable_raster_1 = 22
!align 255,0
irq_stable_raster_base:
sta $10
stx $11
sty $12
+next_irq stable_raster_base_2, stable_raster_1+1
inc $d012
lda #1
sta $d019
tsx
cli
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
stable_raster_base_2:
txs
inc $d020
dec $d020
; the above color change should flicker only by 8 pixels (1 cycle wobble in this interrupt), however, i get way more than that....
EDIT... 5 seconds after posting I realised that I'm setting the $d012 and then incrementing it, making it hit 2 lines after, not one !!! HOW DUMB AM I ??
It works now, but the monitor totally mislead me... |
| |
enthusi
Registered: May 2004
Posts: 674 |
I am (ab)using this to again declare MACROs the devil's work! ;-) |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
There's still something wrong.. While my code had a bug and after fixing it I managed to get a stable raster... but only after I disabled the sprites. While the sprites are enabled (and I tried other sprites too, without sprite 0) the raster is flickering... the sprites are 6 lines below the stable raster code. Stable raster codes sets their Y position and enables them with d015, d015 is set to 0 at line 10 (12 lines above the double_irq routine)
EDIT. Problem went away when I disabled 2x height of the sprites. Any clue why would it be the issue ? |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
Are you sure that the sprites are not in the process of being drawn at a previous location when you set the y-position or erase the enable flag? |
| |
lft
Registered: Jul 2007
Posts: 369 |
Your sprites are at Y-position 31-51 (in hex $1f-$33). When the sprite Y-register is e.g. $33, it will match the raster position twice per frame, and sprite DMA will be enabled starting at lines 51 ($33) and 307 ($133). The copy at line 307 is hidden by the border, and normally ends at line 15, before the next irq. But with Y-expansion, it continues all the way to line 36, and interferes with the irq on the next frame. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Oh yeah that's it. All I have to do now is to disable the y expand (or sprites all together) before the line $11f. Thanks. |
