| |
Krill
Registered: Apr 2002
Posts: 2845 |
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....
|
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
The six byte example as shown does not work since it could get interrupted. An SEI should be executed first before jumping into the loop. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Rastah BarThe six byte example as shown does not work since it could get interrupted. An SEI should be executed first before jumping into the loop.
Hmm, this is more or less the same for all examples we had before, or do I miss smth?? Ok, here a basic sys-line is part of the trick, but it could also jump to an init routine that does SEI or LDA #$7F:STA $DC0D:etc. first.
Another instability of the approach with having the operand bytes of the SHX actually doing something usefull (i.e. filling a register) is that y != 0 in all the examples we had until now. This can lead to the ORA ($f9),Y taking one cycle more, depending on the content of $f9/$fa.
So I vote for $14 instead of $11 as value for X. It'll change the BPL into a NOP zp,X which always takes 4 cycles. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
It can be fixed by putting an SEI in a 7 byte loop. Adding your improvement as well:
20 SYS 14777 : REM $39B9
*=$39B6 (14774 decimal)
39B6 loop: SEI
39B7 TAY
39B8 SHX $39A7,Y
39BB BPL loop
But since the basic SYS 14777 instruction occupies one more byte in memory than a SYS to $08xx, I suppose we have to count this as an eight bytes method. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting QuissNeat! Right, no reason to make those two address bytes go to waste. :)
Another amusing thing to contemplate is how this code could be placed at, say, $08xx. Preferably without messing up the basic upstart.
[...] Not necessarily the shortest piece of code, but it satisfies your requirement to have the sync routine at $08xx:
0843 A2 9E LDX #$9E
0845 A0 08 LDY #$08
0847 E0 00 CPX #$00
0849 D0 F9 BNE $0844
Branching to $0844 leads to SHX $08A0,Y, so the operand byte of the CPX is altered continuously. As long as the "&(hi+1)" plays in, the compare operand will be =$08. When "&(hi+1)" disappears, the full $9E is written to the operand byte and the loop will end. This happens iff the critical SHX-cycle happens on a badline. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Excellent! |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Stupid question from a layman - where this stabilizing piece of code is supposed to go exactly to do its job and not crash the whole thing? :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
$08A3 |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Quoting Rastah Bar$08A3
LOL! :D
So it's supposed to be in fixed place in order to work properly? I asked rather broad, relatively to usual structure of inits etc. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
I guess you did not follow the thread very carefully. The (currently) shortest code that can be placed anywhere was proposed in post #44. Quiss came up with a very bright idea in post #50 that uses the instabilities of the SHX instruction. It uses less RAM, but it has some restrictions on code location. Shorter variants were found, but they have much stronger location restrictions. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting JammerStupid question from a layman - where this stabilizing piece of code is supposed to go exactly to do its job and not crash the whole thing? :) No worries, we're all laymen in some field(s);)
Short answer: it's a short routine that ends on a fixed cycle position of a PAL-rasterline.
If you want a bit more: quite often a raster stabilizing routine is needed for some funky raster code. One approach is to initialize a timer in such a way that you can read it at the beginning of your RASTER irq and use it as a counter for the cycle jitter. This requires some routine that actually initializes the timer somewhere in your init code.
Since every raster line has the exact same no. of cycles, it boils down to init the timer relative to that total no. of cycles of a line. Quiss came up with the initial idea to "wait for a badline" utilising the SHX abs,Y. So effectively his (and also my) routine loops until you hit a badline at an exact cycle position, thus ending up on a unique cycle after the badline. Here you'd usually insert your timer start trigger.
If you *really* want even more detail, feel free to pm me and I'll act as your personal explainer ;) |
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 20 - Next |
