| |
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 setupThe 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....
|
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
Quoting Rastah BarI checked all starting situations and if I did not make a mistake, the loop always ends! Can confirm :) Depending on the loop-cycle at raster-cycle#11 of, say, badline at $30, the loop-cycle-no. either rather quickly gets to 3 (and thus the S-cycle lands where it should), or the loop-cycle-no. gets into an "4/5<->11 endless cycle". No other endless cycles are possible.
So it suffices to check what happens when the loop-cycle at raster-cycle#11 of the last badline of the frame is 4/5 or 11. For this, see post#150. "QED", I'd say 8)=)
Quoting Rastah BarThe next exercise is to check this for C64 models other than PAL. Puhhh, not now, I'm just too happy it works for PAL :)
Quoting ChristopherJamQuoting Copyfault[...]Thanks for doing the analysis! Had to be done;) And I kinda like rastercycle-joggling... really sad it did not "pay off". And now it DID pay off :) I'm really happy now, 'cause we have just "proven" that
sta $d093,y
brk
with the brk replaced by any wanted value on the sync-loop's exit works!!! A 0-byte-sync-routine (ofcourse PLUS all the preparations, but those may serve other purposes, too). |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
Victory! \:D/ \:D/ |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
I checked NTSC1, NTSC2, and DREAN, but it doesn't work for these models. NTSC2 and DREAN have 65 cycles per line, and since this is a mutiple of the looplength of 13 cycles, the border changes nothing and won't get us out of an endless loop.
I found examples of endless loops for all models, and for NTSC1 the border does not save it either. So PAL only. |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
There's still some more to squeeze out of the "0-byte-approach", though one may argue that it becomes a 1-byte-routine this way...
Instead of changing the byte following the SHA (vec),y, we could change the low-byte of the BRK-vector. By doing so, the mem constraint of the routine (best fit was the $ffxx-page) can be lowered a bit:
*= page*$100 - 1
sta $d093,y
brk
Now init the BRK-vector with $00/#page, put #($fe-y)/$ff at $d0/$d1 and choose values for accu and x s.t. x&a=1 and the routine will still work (also widens the choice for a and x somewhat). |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
Oh nice. There's always a use for a value pre-initialised to zero too, so I'm sure that would not be wasted. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
The choice of A&X can be much wider than s.t. A&X=1.
A&X=3 would also work to continue with the code after the BRK instruction. Or, if you store some useful data such as a small table after the BRK, it can be skipped with a larger value of A&X. Ideally the BRK instruction would serve as the first element of a table :-) |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
Yes, you're both right, the BRK can be used as some data and the step from the beginning of the page to the adress where to continue can be chosen almost arbitrarily... but it imposes more (and weirder!!) restrictions on the choices for a and x;)
The example with A&X=1 was on intention, 'cause this way the $d0 turns into a BNE to the next opcode, and since A&X!=0, it's quite save to assume that the zero-flag is not set when the loop starts;)) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Quoting CopyfaultYes, you're both right, the BRK can be used as some data and the step from the beginning of the page to the adress where to continue can be chosen almost arbitrarily... but it imposes more (and weirder!!) restrictions on the choices for a and x;)
Not more restrictions, you just have more choice. |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
Quoting Rastah BarQuoting CopyfaultYes, you're both right, the BRK can be used as some data and the step from the beginning of the page to the adress where to continue can be chosen almost arbitrarily... but it imposes more (and weirder!!) restrictions on the choices for a and x;)
Not more restrictions, you just have more choice. Hmm, don't know, but the more bits are fixed by the AND-conditiion, the fewer variants for the pair (a,x) are permitted, no? |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Yes, but the coder can choose to use A&X=1, or A&X=3, or something else. So in that sense there are less restrictions.
A priori he has more possibilities to choose from.
Some may not work, but he can always fall back to A&X = 1 or A&X = 3 if he can't make a data table work with the corresponding restrictions on A and X, and to A&X = 1 if A&X = 3 can't be met. Besides, A&X = 2^K, K = 2,...,7 also only fixes 1 bit. |
| Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 - Next |
