Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums

Forums > C64 Coding > unexpected lost cycles (with sprites)
2018-03-27 17:14

Registered: Jan 2018
Posts: 98
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
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 ?
... 5 posts hidden. Click here to view all posts....
2018-03-28 06:59

Registered: Mar 2002
Posts: 841
Are you on a badline perhaps?
2018-03-28 09:59

Registered: Aug 2011
Posts: 29
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).
2018-03-28 11:03

Registered: Jan 2018
Posts: 98
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
2018-03-28 14:08

Registered: Nov 2011
Posts: 364
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).
2018-03-28 16:29

Registered: Jan 2018
Posts: 98
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	
	sta $10
	stx $11
	sty $12
	+next_irq stable_raster_base_2, stable_raster_1+1
	inc $d012
	lda #1
	sta $d019
	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...
2018-03-28 16:42

Registered: May 2004
Posts: 653
I am (ab)using this to again declare MACROs the devil's work! ;-)
2018-03-28 17:17

Registered: Jan 2018
Posts: 98
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 ?
2018-03-28 17:54

Registered: Oct 2012
Posts: 27
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?
2018-03-28 19:46

Registered: Jul 2007
Posts: 356
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.
2018-03-28 20:17

Registered: Jan 2018
Posts: 98
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.
Previous - 1 | 2 - 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
Users Online
Guests online: 29
Top Demos
1 Uncensored  (9.7)
2 Comaland 100%  (9.7)
3 Unboxed  (9.7)
4 Edge of Disgrace  (9.7)
5 Coma Light 13  (9.6)
6 The Shores of Reflec..  (9.6)
7 Lunatico  (9.6)
8 Wonderland XII  (9.6)
9 X Marks the Spot  (9.6)
10 C=Bit 18  (9.6)
Top onefile Demos
1 Arok 20 Invitation  (9.6)
2 FMX Music Demo  (9.6)
3 Daah, Those Acid Pil..  (9.6)
4 Pandemoniac Part 2 o..  (9.5)
5 Rewind  (9.5)
6 Party Horse  (9.4)
7 Dawnfall V1.1  (9.4)
8 Crystal Gazer  (9.4)
9 Merry Xmas 2017  (9.4)
10 Dawnfall  (9.4)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Finnish Gold  (9.3)
5 The Transfer Team  (9.3)
Top Hardware-Gurus
1 Soci  (9.9)
2 Wiesel  (9.9)
3 Grue  (9.8)
4 Zer0-X  (9.8)
5 JMP$FCE2  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.052 sec.