PDA

View Full Version : Video timing; New discoveries, improved synchronisation code.



Linus Akesson
11-02-2010, 06:38 PM
Hi!

I've been venturing into the murky depths of video generator timing, and discovered some new glitches and previously undocumented behaviour. The upshot is that I managed to write a 100% reliable PLL synchronisation routine. (The technique used in Chip Gracey's multi-cog video drivers is 99.94% reliable.)

Here's the code, and all the juicy details:

http://www.linusakesson.net/programming/propeller/pllsync.php

Rayman
11-02-2010, 06:49 PM
I'll have to take a look at this...

I have a driver for 3-cog 6-bit color photos on VGA that I could never get the pixels exactly on top of each other with...

Maybe your ideas will help with that...

jazzed
11-02-2010, 06:53 PM
Great work Linus! Thanks for sharing.

Bill Henning
11-02-2010, 07:03 PM
Great work and excellent analysis - this should go into the FAQ.


Hi!

I've been venturing into the murky depths of video generator timing, and discovered some new glitches and previously undocumented behaviour. The upshot is that I managed to write a 100% reliable PLL synchronisation routine. (The technique used in Chip Gracey's multi-cog video drivers is 99.94% reliable.)

Here's the code, and all the juicy details:

http://www.linusakesson.net/programming/propeller/pllsync.php

KaosKidd
11-02-2010, 07:17 PM
WOW!
Awesome writeup! It really explained a number of things!
Great Job!

KK

Oldbitcollector (Jeff)
11-02-2010, 07:36 PM
I predict jitter coming out of some existing video code! Awesome work!

OBC

RossH
11-02-2010, 11:26 PM
Excellent work! This explains a problem I had with my virtual VGA driver failing to sync at higher resolutions.

Ross.

kuroneko
11-03-2010, 12:19 AM
Long time no see Linus! Excellent analysis. FWIW, the multi-bit glitch manifests in other areas as well, e.g. when changing counter modes with a live frqx.

Cluso99
11-03-2010, 12:50 AM
Thanks Linus - excellent work!

jazzed
11-03-2010, 01:02 AM
Don't know if the community noticed or it, but Linus created a Propeller assembler called "plasma" for Turbulence which happens to have an "include" directive :) and it is fully open source. The full capabilities of plasma are not clear just looking at the examples, but at least it allows sharing constant definitions among files.

Linus, what else can plasma do? Share library routines? other?

potatohead
11-03-2010, 05:09 AM
Awesome analysis.

Yes, I've got some code that doesn't work too. Can't wait to bang on this.

Thanks Linus!

Bob Lawrence (VE1RLL)
11-03-2010, 05:18 AM
Great thanks! It's fun to read.


Re: jazzed- Linus created a Propeller assembler called "plasma"

plasma Info Here:
http://www.linusakesson.net/software/plasma/index.php

Loopy Byteloose
11-04-2010, 08:13 AM
This is certainly MUST READ information for anyone that wants to completely master video in the Propeller. It opens up a whole new view point of understanding what is usually just referred to as the "Counter + PLL".

The power of having two PLLs interleave the pixels on different cogs is awesome - better pictures, high resolutions, more colors.

kuroneko
04-06-2011, 07:53 AM
' Synchronise cog PLLs. Here there be dragons.
' http://www.linusakesson.net/programming/propeller/pllsync.php

waitcnt sync_cnt, =$30000 ' 3 ms
mov VCFG, =%0_01_0_00_000_00000000000_010_0_11111111
movi FRQA, #$10000000 >> 23
mov VSCL, #1 ' Reload on every pixel
movi CTRA, #%0_00001_111_00000000_000000_000_000000 >> 23
waitcnt sync_cnt, #0 ' Wait for PLL to settle
mov VSCL, #65 ' Any power of two, plus one

' The next instruction must not be a waitvid, and should
' probably not be an assignment to VSCL either.
Some idle thoughts. To be fair, as far as video related programming is concerned I guess I can let the name PLL sync pass (5 out of 8 isn't bad). OTOH it simply doesn't work for clock dividers 32, 64 and 128 (only the NCO feeding the PLL is in fact sync'd). Not too serious really.

The other thing I don't quite get is the reload on every pixel. That's like self-inflicted damage and then complaining that it doesn't work properly. And changing only a single bit doesn't help. If you step back for a moment and look at it you'll realise that you change a register value the moment it's sampled. Single bit change or not you'll have a ~50% chance that it catches up one cycle later (than the other cog(s)). I checked and this'll happen more often than you think. Which may be OK for a particular use case but can (and should) be avoided.

DAT org 0

entry rdlong delay, #0 ' clkfreq
shr delay, #10 ' ~1ms (%%)

rdlong cref, par ' initial sync target
waitcnt cref, delay ' sync cogs

movi ctra, #%0_00001_111 ' PLL, VCO/1
movi frqa, #%0001_00000 ' 5MHz * 16 / 1 = 80MHz

mov vscl, #vref ' 32 rather than the default 4K

movd vcfg, #2 ' pin group
movs vcfg, #%0_11111111 ' pins
movi vcfg, #%0_01_0_00_000 ' VGA, 32 pixels

waitcnt cref, #vref*3 ' PLL settled (%%)

waitvid zero, #0 ' dummy to play it safe
waitvid zero, #0
sub cref, cnt
mov vscl, cref ' transfer adjustment
waitvid zero, #0 ' latch adjustment
mov vscl, #user ' transfer user value
waitvid zero, #0 ' latch user value

...

kuroneko
04-08-2011, 04:08 AM
waitvid zero, #0 ' dummy to play it safe
waitvid zero, #0

...
Admittedly this comment makes it sound like you could get away without it. Wrong. Reason being that there are 4 cycle waitvids and 4 cycle waitvids. The former is your ordinary/official (and useless) 4 cycle version. The latter - also useless - happens during frame stretches where a minimal waitvid is pushed back by one cycle and makes the frame look longer. However, the next hand-off stays locked to the grid (vscl[11..0]*n) which means it happens one cycle earlier in reference to the waitvid which would throw off all timing. Anyway, I just thought I should share this (after finding out the hard way).

The solution listed suffers from jitter (frqa <> po2) given the right circumstances. A more solid version is listed in my waitvid thread (20110409 update).