[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: 2980

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-12-17 12:03

Krill

Registered: Apr 2002
Posts: 2980

Quoting Groepaz

relying on anything being already initialized isnt really a good idea though. perhaps acceptable for something like a 4k - but for anything bigger i'd rather not do this. you can never know what some cartridge or kernal replacement does.

Cartridge and KERNAL stuff do not play much of a role in demos, so it's not unusual to have timers for IRQ jitter compensation run during the entire multi-side demo without re-initialisation.

It's different for games, of course, but there you rarely need stable interrupts.

But then both multiload demos and games do not have much of a space issue, so just re-initialise timers at strategic/natural points and be done with it.

2020-12-17 12:16

Copyfault

Registered: Dec 2001
Posts: 478

Quoting Rastah Bar

It may still work, because the border can get it out of such an endless loop, but this should be checked.

Hmm, at least my counter example from post#132 seems to get fixed: if we have loop-cycle#4 at cycle#11 of the last rasterline in one frame, we will get to loop-cycle

change                  |   loop-cycle
starting situation      |   4
W-cycle following "S"   |   +1 = 5
cycles to bl in next fr |   +3 = 8
W-cycles of BRK         |   +2 = 10
cycle to next bl        |   +6 = 16 = 3

so the next loop-cycle (which is the S-cycle) hits raster-cycle #12 and the loop ends.

Similarly, when starting with loop-cycle#11:

change                  |   loop-cycle
starting situation      |   11
cycles to bl in next fr |   +3 = 14 = 1
cycle to next bl        |   +6 = 7
W-cycles of BRK         |   +3 = 10
cycle to next bl        |   +6 = 16 = 3

Now we have to check all starting situations, since the routine might start at a last badline of a frame. But I'm warily optimistic ;)

2020-12-17 12:49

Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336

I checked all starting situations and if I did not make a mistake, the loop always ends!

The next exercise is to check this for C64 models other than PAL.

2020-12-17 12:59

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote:

Cartridge and KERNAL stuff do not play much of a role in demos, so it's not unusual to have timers for IRQ jitter compensation run during the entire multi-side demo without re-initialisation.

thats not the point. the point is that you cant rely on the kernal having initialized the timer to a certain value when your code starts up.

2020-12-17 13:01

Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336

Quote: Quoting Groepaz
relying on anything being already initialized isnt really a good idea though. perhaps acceptable for something like a 4k - but for anything bigger i'd rather not do this. you can never know what some cartridge or kernal replacement does.
Cartridge and KERNAL stuff do not play much of a role in demos, so it's not unusual to have timers for IRQ jitter compensation run during the entire multi-side demo without re-initialisation.

It's different for games, of course, but there you rarely need stable interrupts.

But then both multiload demos and games do not have much of a space issue, so just re-initialise timers at strategic/natural points and be done with it.

I did assume that $dc04 goes through all 256 values. If it runs at a period of 9 cycles, the SBX #51 will fail. If it runs at a period of 63 cycles, I don't know if it will work. That has to be analyzed. If it does, I expect that it often will take much longer to lock. Then again, as you point out, if it runs at these periods usually means that a raster syncing procedure has already been performed.

2020-12-17 13:16

Krill

Registered: Apr 2002
Posts: 2980

Quoting Rastah Bar

I did assume that $dc04 goes through all 256 values.

Note that by default, you cannot expect a timer period that is divisible by 256. That is, on timer underflow, the timer lo-byte will wrap to some other value than $ff.

2020-12-17 13:30

Copyfault

Registered: Dec 2001
Posts: 478

The approach with the timer has some pitfalls but the idea behind it is really beautiful: to check if the timer has changed largely though the read-accesses to the timer-register are just a few cycles apart!

In some of my former posts I already wondered wether the timer underflow never misaligns the read values s.t. a badline might be detected while not being in one. And somehow it feels strange to use timers in a routine which aims to fix a raster cycle position s.t. a timer can be initialised in a stable way. Nontheless a valuable addition to the pool of (mostly insane) approaches :)

2020-12-17 14:10

Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336

Quote: Quoting Rastah Bar
I did assume that $dc04 goes through all 256 values.
Note that by default, you cannot expect a timer period that is divisible by 256. That is, on timer underflow, the timer lo-byte will wrap to some other value than $ff.

Yes, but for the default ~60 Hz setting, that will only postpone locking somewhat.

2020-12-17 14:15

Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336

Quoting Copyfault

The approach with the timer has some pitfalls but the idea behind it is really beautiful: to check if the timer has changed largely though the read-accesses to the timer-register are just a few cycles apart!

Thanks!
Quoting Copyfault

In some of my former posts I already wondered wether the timer underflow never misaligns the read values s.t. a badline might be detected while not being in one. And somehow it feels strange to use timers in a routine which aims to fix a raster cycle position s.t. a timer can be initialised in a stable way. Nontheless a valuable addition to the pool of (mostly insane) approaches :)

The default Kernal settings are such that a false positive cannot occur. But, as Groepaz pointed out, you can never know what some cartridge or kernal replacement does to the settings.

2020-12-17 18:31

Krill

Registered: Apr 2002
Posts: 2980

Quoting Rastah Bar

The default Kernal settings are such that a false positive cannot occur. But, as Groepaz pointed out, you can never know what some cartridge or kernal replacement does to the settings.

This is the same hazard as relying on any kind of pre-initialised variable. Usually to be avoided, but okay for very tight size-restricted productions, such as 4K or smaller demos. =)