phase relationship between PLLA and Pixels

MIchael_Michalski

Was just thinking, suppose I setup the video generator and execute a waitvid to feed it a pixel and color data that makes it alternate every pixel. (1010101010...1010) Now suppose I have setup the PLL to output on a pin. If I put both on an oscilloscope how much phase difference will I see between them due to the differing propagation times of the various parts.

VonSzarvas

Interesting. Have you tried the experiment yet?

garlen

Curious with the result of the experiment as well.

MIchael_Michalski

I haven't tried it yet. Its disappointing that there are not comprehensive timing diagrams available.

MIchael_Michalski

It also begs the question, what is the relation to the main clock. If I for example create a pixle one clock wide and set a counter to count when the PLL is high AND the pixel is high by connecting those pins to the counter B inputs, depending on the phase relationship between all of these it either wont work,will work unreliably or will work perfectly. I expect that the phase of the PLL should lead the phase of the pixles by a significant amount because of the extra stuff it has to go through. My real hope however is that EVERYTHING lags the system clock by enough that it gets counted.

Publison

Have you found the Application Notes? :

https://www.parallax.com/search?search_api_views_fulltext=AN00

and the DAT Sheet?:

https://www.parallax.com/downloads/p8x32a-propeller-datasheet

MIchael_Michalski

Yes,but they dont provide comprehensive timing diagrams. Ideally we would have diagrams that show you how the instructions,IO, video generator,etc relate to each other. I guess I could look at the Verilog. In fact, thats what I think Ill do as I should be able to understand the nitty gritty details. Im not sure I 100% agree, but one could certainly make the argument that the nitty gritty technical details are not as important in the datasheet if you can go back and look at how things are actually put together. Its a similar argument to open source software. Does the manual for a data analysis package really NEED to have a in depth detailed appendix describing exactly how they implemented the Savitsky Golay filter when anyone who can understand it probably can just look at the provided source code.,

tonyp12

P1 is starting getting to old for anyone to really care with that stuff, magical hardware timings is fun to discover on new devices.
Is Kuroneko even around anymore?, as he would be the guy to ask.

potatohead

This error can be seen in some composite TV drivers. Several of mine were written with the colorburst constant per line to emulate old 8 bit computer signals. The error shows easily.

The color burst is generated by PLLA, and the pixel clock is expressed as X number of pixels clocked out per PLLA.

Possible phase error is 1/(number of PLLA cycles per pixel). Something like that, anyway. Never measured it.

Edit: That is just the possible granularity of it, not a direct error percentage.

It remains constant when P1 is running, and will vary on a reset, and or driver restart.

On most drivers, this error is small. On something like VGA, it manifests as a very small shift in pixel position, which digital monitors correct for. A CRT will display it, but you have to have a good one to see it. Or you have to have a small number of pixels per PLLA. Ideally both.

For TV, Eric Ball generated a color burst manually, just using pixels to approximate the waveform, to insure a constant phase between pixels and the color burst reference, basically taking PLLA out of the equation. The P1 color phase generator isn't used at all.

That was necessary to generate true artifact color, as in say an odd pixel being red, an even one being blue kind of thing, like say an old Apple 2, or Atari computer would do.

The phase error can be seen in the parallax driver, by changing the number of scan lines to even, so the color burst is static, then put a swatch of red on the screen, and a blue one overlapping it.

A better TV will show a fringe color at the boundary. Reset the prop to see it change. That fringe color will be one of a number of shades possible, depending on the number PLLA cycles per pixel there are.

Later TV drivers minimized this by running a higher PLLA, say some multiple of the color burst.

This error, and jitter in general, also makes a PAL driver difficult to get good color purity on without a crystal.