[resolved][puzzle] Drifter, The
kuroneko
Posts: 3,623
The attached program upsets the video h/w to generate a 32MHz pixel clock based on an 80MHz system clock, i.e. one pixel lasts 2.5 system clocks. After we synchronised to the waitvid hand-off point (WHOP) we delay for a frame and subsequently use a cmp insn in a 40 cycle loop (16 pixels per frame, 16 * 2.5 = 40 system clocks). Which works well up to a point, then the WHOP has drifted into the neighbouring insns and the video h/w outputs a guard pattern instead of the intended match pattern (demoboard LED bar). This is no surprise given that the frqx setup is not a power of two value.
Objective: Stabilise the WHOP so it stays within the designated compare insn.
Objective: Stabilise the WHOP so it stays within the designated compare insn.
waitvid zero, #0 mov dira, mask ' drive outputs '----------------------------------------------- [COLOR="orange"]waitvid zero, #0[/COLOR] ' sync point [COLOR="blue"]mov cnt, cnt[/COLOR] ' [COLOR="blue"]add cnt, #9{14} + 19[/COLOR] ' [COLOR="blue"]waitcnt cnt, #0[/COLOR] ' adjust for one frame '----------------------------------------------- :loop [COLOR="red"]cmp match, #0[/COLOR] ' WHOP cmp guard, #0 cmp guard, #0 cmp guard, #0 cmp guard, #0 ' +20 cmp guard, #0 cmp guard, #0 cmp guard, #0 cmp guard, #0 jmpret guard, #:loop nr ' +40
Comments
So far, it hasn't slipped.
-Phil
Addendum: 'Checked back after an hour; still no slippage evident.
@all: The fact that puzzle and Phil both start with the letter P doesn't mean that only he can participate!
-Phil
The original solution simply sampled an appropriate phsa which is then inserted in the loop later (at the same offset). While picking a hard-wired value works, care must be taken to pick one far enough away from the critical points. Also, given that we are sync'd already the new/forced value shouldn't upset the PLL from that point onward. FWIW, using $19999999 gives you $04444444 stable NCO cycles which amounts to ~9sec @80MHz. Plenty of room.