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 > Shortest code for stable raster timer setup
2020-01-20 16:20
Krill

Registered: Apr 2002
Posts: 1405
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?
 
... 38 posts hidden. Click here to view all posts....
 
2020-02-01 00:06
Copyfault

Registered: Dec 2001
Posts: 275
Quote: sorry I did not construct it properly with fast I meant it stabilizes fast, with that I mean max ~0.3 seconds a time span that for us humans doesnt matter :) so 9 frames max will do. however looking at the new version and explanation: your skills at this are truly impressive sir.

Ah come on, I'm just too fond of playing aroung with things that seem to keep certain mathematical mysteries inside;) Does not really help to get things *done*
To the opposite: I'd say you are the one to adore here! Will never ever reach that level of coding that you simply own, Oswald! I mean it:)

But thanks for your kind words. Gives me the positive feeling that there are people like you out there that care about explanations'n'stuff!
2020-02-01 11:54
Rastah Bar

Registered: Oct 2012
Posts: 194
I find this problem surprisingly hard to understand. I think I get most of what you are saying, but aren't you neglecting the presence of badlines? The number of cycles available to the CPU is less on badlines and can even vary because of RMW instructions in the init code. So it seems there may be cases where neither of the approaches (INC, LAX) locks. Or am I mistaken?
2020-02-01 12:02
Copyfault

Registered: Dec 2001
Posts: 275
Quote: I find this problem surprisingly hard to understand. I think I get most of what you are saying, but aren't you neglecting the presence of badlines? The number of cycles available to the CPU is less on badlines and can even vary because of RMW instructions in the init code. So it seems there may be cases where neither of the approaches (INC, LAX) locks. Or am I mistaken?

I compared the approaches with having a clean setup before doing the stabilization routine, i.e. no badlines, no irqs.

If you allow badline f.e., my reasoning of the large posting above does not hold true anymore. I did some measurements yesterday that show both approaches take more than 9(resp. 7)frames with badlines enabled. I have to admit that I had no motivation to do the calculations respecting the badlines inbetween, but it *could* be done...
2020-02-01 12:13
Rastah Bar

Registered: Oct 2012
Posts: 194
I guess it can be easily fixed by blanking the screen in the init code. This is often required anyway when setting up the graphics, so this is not really a constraint.

I have tried to analyze my timer-based approach.

One loop takes 18 cycles. Between the same cycle of two consecutive badlines there are 461 available cycles. If the STA ZP starts on a certain cycle of a badline (and there is no lock), it will start 7 cycles later on the next badline, because 461 = 26*18 - 7. Since a non-locking badline has 20 cycles which is not coprime with 7, the algorithm will always lock.

What are your thoughts about this?
2020-02-01 16:54
Rastah Bar

Registered: Oct 2012
Posts: 194
I can shave off one byte:
sync: lax $dc04
      sbx #51
      sta ZP      ;RMW instruction
      cpx $dc04
      bne sync:

The loop is 16 cycles and since 461 = 29*16 - 3, this also should always lock. It needs at most 20 consecutive badlines, so the very worst case is that the lower border is reached after 19 badlines and you have to start again at the first badline. So locking is guaranteed in less than 1.4 frames.
2020-02-01 21:36
JackAsser

Registered: Jun 2002
Posts: 1599
Quote: I can shave off one byte:
sync: lax $dc04
      sbx #51
      sta ZP      ;RMW instruction
      cpx $dc04
      bne sync:

The loop is 16 cycles and since 461 = 29*16 - 3, this also should always lock. It needs at most 20 consecutive badlines, so the very worst case is that the lower border is reached after 19 badlines and you have to start again at the first badline. So locking is guaranteed in less than 1.4 frames.


Exploiting kernel setup values in dc04 and dc05 (different on PAL and NTSC)?! But we're only in PAL domain in this thread anyways.
2020-02-01 22:24
Rastah Bar

Registered: Oct 2012
Posts: 194
See post #38 for what I have in mind. Do you think this could work? I'm always a little bit afraid that I missed something.

It should lock also on NTSC since 477 = 30*16 - 3, but the routine exits on a different cycle number.
2020-02-02 12:09
Copyfault

Registered: Dec 2001
Posts: 275
Quoting Rastah Bar
I guess it can be easily fixed by blanking the screen in the init code. This is often required anyway when setting up the graphics, so this is not really a constraint.[...]
Forgot to stress this detail, but I had this in mind: you even do not have to set it before the start of the stabilization loop (the first check of $d012 might be a "bad case" anyway), so it suffices to blank screen/kill irqs/etc in the init code blob.

Quoting Rastah Bar
I can shave off one byte:
sync: lax $dc04
      sbx #51
      sta ZP      ;RMW instruction
      cpx $dc04
      bne sync:

The loop is 16 cycles and since 461 = 29*16 - 3, this also should always lock. It needs at most 20 consecutive badlines, so the very worst case is that the lower border is reached after 19 badlines and you have to start again at the first badline. So locking is guaranteed in less than 1.4 frames.
This one looks quite clever, though I did not deep-check "all the math" behind it. One thing (besides the badline-timing) that might also cause a cycle-mismatch at the cpx $dc04-instruction is the behaviour of the timers: afair, it never reaches the $00-value, but gets initialized with the max-value (so $dc04 outputs the same value in two consequetive cycles, but never $00).
And as a sidenote: a STA ZP is just a write-instruction, no Read-Modify-Write (the RMW-comment in your code examples confused me a little;)). But the idea you posted with one write-cycle is correct and should work...
2020-02-02 18:21
Rastah Bar

Registered: Oct 2012
Posts: 194
Quoting Copyfault
Quoting Rastah Bar
I guess it can be easily fixed by blanking the screen in the init code. This is often required anyway when setting up the graphics, so this is not really a constraint.[...]
Forgot to stress this detail, but I had this in mind: you even do not have to set it before the start of the stabilization loop (the first check of $d012 might be a "bad case" anyway), so it suffices to blank screen/kill irqs/etc in the init code blob.
Yes, you are right.
Quoting Copyfault
This one looks quite clever, though I did not deep-check "all the math" behind it. One thing (besides the badline-timing) that might also cause a cycle-mismatch at the cpx $dc04-instruction is the behaviour of the timers: afair, it never reaches the $00-value, but gets initialized with the max-value (so $dc04 outputs the same value in two consequetive cycles, but never $00).
And as a sidenote: a STA ZP is just a write-instruction, no Read-Modify-Write (the RMW-comment in your code examples confused me a little;)). But the idea you posted with one write-cycle is correct and should work...

Thanks for your feedback. $dc04 can reach 0 because it is linked with $dc05. So as long as $dc05>0, $dc04 goes from 0 to $ff, and there is no problem. But when ($dc05,$dc04)=$0001 it goes directly to $4025 after that (on PAL), but that cannot cause an accidental lock. It only may delay the locking a bit. So there is no problem there, I think.

You are right, STA ZP is an RRW instruction, but the W-cycle at the end is important.
2020-02-03 11:43
Rastah Bar

Registered: Oct 2012
Posts: 194
How would one setup a timer in NTSC? Since 65 = 5*13 a timer period of 13 seems the most obvious choice.
Previous - 1 | 2 | 3 | 4 | 5 - 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
Advanced
Users Online
Karmic/HVSC/ONS
Brittle/Necta!^Demozoo
Black Beard/Abyss, A..
E$G/HoKuTo FOrCE
Knobby/Role
Jazzcat/Onslaught
Dymo/G★P
LKP/CFN-3001
Motion/ΛRTΣTΛTE·..
Guests online: 45
Top Demos
1 Uncensored  (9.7)
2 Coma Light 13  (9.7)
3 Edge of Disgrace  (9.7)
4 Comaland 100%  (9.6)
5 Unboxed  (9.6)
6 The Shores of Reflec..  (9.6)
7 Remains  (9.5)
8 Lunatico  (9.5)
9 We Come in Peace  (9.5)
10 C=Bit 18  (9.5)
Top onefile Demos
1 Dawnfall V1.1  (9.6)
2 Crystal Gazer  (9.6)
3 Space Demo  (9.5)
4 Field Sort  (9.5)
5 Instinct  (9.5)
6 The Tuneful Eight [u..  (9.5)
7 Smile to the Sky  (9.5)
8 Rewind  (9.5)
9 Onef1ler  (9.5)
10 Bad Boy  (9.5)
Top Groups
1 Performers  (9.6)
2 Oxyron  (9.4)
3 PriorArt  (9.4)
4 Booze Design  (9.4)
5 Censor Design  (9.4)
Top Sysops
1 Optic Freeze  (10)
2 pcollins  (9.9)
3 Pudwerx  (9.7)
4 Aycee  (9.6)
5 Taper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.043 sec.