[CSDb] - User Forums - Shortest code for stable raster timer setup

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Shortest code for stable raster timer setup

2020-01-20 16:20

Krill

Registered: Apr 2002
Posts: 2854

Shortest code for stable raster timer setup

While working on my ICC 2019 4K entry (now postponed to ICC 2020, but i hope it'll be worth the wait), i came up with this (14 bytes):

initstabilise   lda $d012
                ldx #10          ; 2
-               dex              ;   (10 * 5) + 4
                bpl -            ; 54
                nop              ; 2
                eor $d012 - $ff,x; 5 = 63
                bne initstabilise; 7 = 70

                [...]; timer setup

The idea is to loop until the same current raster line is read at the very beginning (first cycle) and at the very end (last cycle) of a raster line, implying 0 cycles jitter.

With 63 cycles per line on PAL, the delay between the reads must be 63 cycles (and not 62), reading $d012 at cycle 0 and cycle 63 of a video frame's last line (311), which is one cycle longer due to the vertical retrace.

The downside is that effectively only one line per video frame is attempted, so the loop may take a few frames to terminate, and the worst case is somewhere just beyond 1 second.

The upside is that it always comes out at the same X raster position AND raster line (0), plus it leaves with accu = 0 and X = $ff, which can be economically re-used for further init code.

Now, is there an even shorter approach, or at least a same-size solution without the possibly-long wait drawback?

... 177 posts hidden. Click here to view all posts....

2020-01-29 05:52

ChristopherJam

Registered: Aug 2004
Posts: 1381

Cheers, Copyfault.

I was wondering about the pagebreak myself, but didn't want to constrain the code (of course, as writ it needs to avoid a page break, but that's slightly easier).

I agree that the ldy#val you've proposed belongs to the init code, and hence is a valid way to avoid the RMW without increasing the code size.

All that said, my submission and your modifications to it are all vulnerable to failing if they enter in the middle of line zero - only a 0.3% chance, but still not ideal. The following take avoids that, albeit at the cost of re-introducing the write to $d012. Possibly a bonus if you want to set up a raster interrupt for line $000 or $100 mind :)

sync:
    inc $d012   ; result will be zero on cycles 0-7 or 8 of raster line $ff
    bne sync    ; (or very rarely, cycle 9..62)

    .res 27,$ea ; wait 62-8=54 cycles. Replace with 54 cycles of init code

    inc $d012   ; if result is nonzero then we are too late.
    bne sync    ; carry on if we read on cycle 62, 62 cycles after cycle 0

edit: this one probably also compresses better than the earlier versions - the two code snippets both start with EE 12 D0 D0

2020-01-29 16:53

Krill

Registered: Apr 2002
Posts: 2854

Quoting ChristopherJam

sync: inc $d012 ; result will be zero on cycles 0-7 or 8 of raster line $ff bne sync ; (or very rarely, cycle 9..62) .res 27,$ea ; wait 62-8=54 cycles. Replace with 54 cycles of init code inc $d012 ; if result is nonzero then we are too late. bne sync ; carry on if we read on cycle 62, 62 cycles after cycle 0

edit: this one probably also compresses better than the earlier versions - the two code snippets both start with EE 12 D0 D0

Excellent! =D

Seems to work just fine here in my real-world code. Fast, reliable, short, packs well AND is pretty elegant. A keeper. :)

2020-01-29 18:14

JackAsser

Registered: Jun 2002
Posts: 1990

Quote: Quoting ChristopherJam
sync: inc $d012 ; result will be zero on cycles 0-7 or 8 of raster line $ff bne sync ; (or very rarely, cycle 9..62) .res 27,$ea ; wait 62-8=54 cycles. Replace with 54 cycles of init code inc $d012 ; if result is nonzero then we are too late. bne sync ; carry on if we read on cycle 62, 62 cycles after cycle 0

edit: this one probably also compresses better than the earlier versions - the two code snippets both start with EE 12 D0 D0
Excellent! =D

Seems to work just fine here in my real-world code. Fast, reliable, short, packs well AND is pretty elegant. A keeper. :)

I haven't really tried to understand it actually. Will this lock on any raster line or just 0 or 256? Or what are the limitations?

2020-01-29 18:27

Krill

Registered: Apr 2002
Posts: 2854

$100 only, i think.

2020-01-29 18:47

Frantic

Registered: Mar 2003
Posts: 1629

How nice! :)

2020-01-29 20:59

ChristopherJam

Registered: Aug 2004
Posts: 1381

Cheers all.

Yup, locks to line $100.

Assumes sprites disabled and no interrupts occur.

2020-01-29 21:39

Oswald

Registered: Apr 2002
Posts: 5026

I dont get it, Z flag is set according to result of inc, thus line should be $ff ?

2020-01-29 21:52

ChristopherJam

Registered: Aug 2004
Posts: 1381

Sure - depends how you measure it.
The last time the 54 cycles worth of code between the snippets are executed, they will be on line $0ff.

The code always exits a few cycles into line $100.

2020-01-30 00:22

Copyfault

Registered: Dec 2001
Posts: 467

Quote: Cheers, Copyfault.

I was wondering about the pagebreak myself, but didn't want to constrain the code (of course, as writ it needs to avoid a page break, but that's slightly easier).

I agree that the ldy#val you've proposed belongs to the init code, and hence is a valid way to avoid the RMW without increasing the code size.

All that said, my submission and your modifications to it are all vulnerable to failing if they enter in the middle of line zero - only a 0.3% chance, but still not ideal. The following take avoids that, albeit at the cost of re-introducing the write to $d012. Possibly a bonus if you want to set up a raster interrupt for line $000 or $100 mind :)

sync: inc $d012 ; result will be zero on cycles 0-7 or 8 of raster line $ff bne sync ; (or very rarely, cycle 9..62) .res 27,$ea ; wait 62-8=54 cycles. Replace with 54 cycles of init code inc $d012 ; if result is nonzero then we are too late. bne sync ; carry on if we read on cycle 62, 62 cycles after cycle 0

edit: this one probably also compresses better than the earlier versions - the two code snippets both start with EE 12 D0 D0

Ooh yes, I see... the uber-motivation was to huge yesterday;)

But... this should be fixable without INC-opcodes. The chance of failing comes from the fact that we used a BEQ-check after the stuffed-in init-code with the strategy of a unique overflow situation in mind.

Now if we reverse this strategy, we could check for a unique non-overflow-situation, by just prolonging the init code part by a suitable no. of cycles.

sync:
    ldy #val
line0x100_wait:
    lax $d012
    bne line0x100_wait
    /*
    // 56 cycles of init code go here
    */
    lax $d012   // the R-cycle occurs exactly after 62 cycles of the upper R-cycle of the lax $d012
    bne sync    // this gives 0 if and only if the upper $d012-read was exactly @cycle=0 of the rasterline
                // as rasterline 0 is only 62 cycles long, this will only be
                // the case if the upper $d012-read was @cyc=0 of line=$100

The [ldy #val] is still needed for ensuring coprimeness (i.e. no. of cycles between two upper $d012-checks must not have a common divisor with 63=7*9).

Should work and should need 63 frames in the worst case. Ahh, and the lower [lax $d012] was just for having two identical codeblocks, thus should also do them compressing algorithms a favor;)

2020-01-30 07:38

Oswald

Registered: Apr 2002
Posts: 5026

in max how many frames would this awesome inc solution would sync up ?

I'd be interested in a solution thats simple AND fast. Not necessarily shortest. Would be a nice addendum to codebase.

What I have currently by Ninja does have a lot of code checking on how it misses the end of a rasterline, a version that fits into a dozen lines would be neater.