Video Signal & VSCL Query

Gary Preston

Hi all,

I've got a stable VGA signal working using 1024x768 @ 60Hz by using the following values:

Horizontal Component (RGB/HSync)
FP) Front Porch - 12 pixels
HS) Horizontal Sync - 68 pixels
BP) Back Porch - 80 pixels
AS) Active Scan-line - 512 pixels

Vertical Component (Scanlines/VSync)
FP) Front Porch - 3 lines
VS) Vertical Sync - 6 lines
BP) Back Porch - 29 lines
AL) Active Lines - 768 lines

Where the Horizontal component values are 1/2 that of a normal 1024x768 signal. Also I've reduced the pixel frequency from 65MHz to 32.5MHz since we're outputting half the horizontal pixels this is needed to ensure we still end up with a 60Hz refresh rate.

With this setup, I get a stable VGA image however I don't fully understand why.

Can anyone confirm the following theory.

My Understanding - Probably incorrect [noparse];)[/noparse]

Since we've reduced the horizontal frequency to 32.5MHz and only output 512 active and 160 setup pixels, we're still getting a 60Hz refresh rate. By outputting 768 vertical lines the monitor is locking onto a 1024x768 signal and running its dot clock at 65MHz. However we're output each line with a 32.5MHz dot clock, thus each pixel we output is been sampled twice by the monitor, thus effectivly doubling the pixels (which would explain why all the Horizontal components were halved and not just the active pixels)

If that is accurate, then what is it that the monitor is locking onto in order to determine this is a 1024x768 signal? What is stopping it assuming this is a 512x768 resolution rather than a higher res with doubled horizontal pixels?

Example2:

Also, and this is where I really start to lose myself. Assuming we're doing no work at all to prepare the pixel and colour data for the waitvid, just outputting the exact same 16 pixels and colour every clock frame. Why would running at 65MHz with horizontal components of 24, 136, 160 and 1024 active pixels not work?

If it's down to lack of time to be on the next waitvid call before the video hardware samples the source/dest, why wouldn't the following work:-

Example3:

Outputting 768 lines as above, but half the horizontal component pixels (like in the first example), then using a VSCL or "(2 << 12) | 32" such that we output 32 pixels in total, but only 16 unique ones, with each unique pixel effectivly output twice.

Wouldn't this allow the FREQA to be set to generate a dot clock of 65MHz as a 1024x768 signal should, but provide more working time between waitvid calls as we're allowing the video hardware to double pixels for us, rather than expecting the monitor to do it as with the first example?

In effect allowing us to output a full 1024 horizontal resolution with the pixel doubling occuring on the prop rather than leaving it up to the monitor. (Assuming my understanding of the monitor in the first example was correct?)

HELP!

Have I mis-understood the VSCL hardware?

I feel I'm missing something somewhere along the lines that will result in a eureka moment where everything becomes clear. As is, I feel like I understand how everything works, yet quite clearly do not as the 2nd and 3rd examples do not work. Yet to me, they seem to be nothing but a varient of the first example.

If anyone can help point out what it is I'm missing, I'd really appreciate it.

Hopefully this post isn't as confusing as I currently am [noparse]:)[/noparse]

Mike Green

As I understand it, the VGA monitor doesn't really know the pixel clock rate. It has the vertical sync pulse which sets the frame (refresh) rate. It also has the horizontal sync pulse which sets the number of scan lines and the time for the scan line. Within the active scan line, it just sees a stream of analog data. If it's all a single color, there is no information to derive a clock rate. I think there are standard combinations of horizontal / vertical pulse rates that go with certain resolutions and that implies a clock rate. If you use a clock rate that's an exact submultiple of what's expected, the monitor (as you've seen) simply paints several adjacent pixels with the same data.

Gary Preston

Ok, I think I'm beggining to get somewhere with this.

512x768 - Monitor Doubling
Using 512x768 settings I'm getting a 1024x768 signal with a refresh rate of 60Hz.

With a FREQA set to 363506346 and PLL set to %101 (4x) it's (hopefully) running the video clock at 32.5MHz. Using the settings from the top of the first post. The VSCL is set to "(1 << 12) | 16" for pixel rate to output all 16 pixels at a rate of 1 pixel per clock. Whilst the FP, HS and BP are using "(0 << 12) | X" (where X is 12, 68 or 80 accordingly)

Horizontal Component (RGB/HSync)
FP) Front Porch - 12 pixels
HS) Horizontal Sync - 68 pixels
BP) Back Porch - 80 pixels
AS) Active Scan-line - 512 pixels

The prop outputs 512 active pixels + 160 sync pixels which combined with the 768 vertical lines is picked up by the monitor as a 1024x768 signal with the horizontal pixels been drawn twice.

Prop Doubling

Now as mention in the first post, I expected to be able to do doubling myself, for example, if I drop the output pixels to be only 256 per horizontal line, but up the clocks per pixel to "(2 << 12) | 32" the prop now (still using 32.5MHz clock) outputs 256 pixels twice giving 512 pixels (which the monitor is then also doubling up to 1024)

Now this is a contrived example just to demonstrate that the new VSCL setting does indeed work as I'd hoped. But, it all breaks down in the next example.

1024 Pixels

Note in both the above two examples, the FREQA has remained the same, giving a 32.5MHz clock rate and that the HF,HS,BP have remained the same as we're still outputting 160 setup pixels and a full 512 horizontal pixels (as it's 2 clocks per pixel now and thus 32 pixels output per frame) so we still get 672 pixels for the complete horizontal scanline, which doubled by the monitor gives the correct 1344.

So, I would assume as we can take a 512 pixel output @ 1clk/pixel and halve it to 256pixels with 2clk/pixel we should be able go the other way. If we double the pixels we're outputting to 1024 we need to 1/2 the clock rate to be 0.5clk/pixel which obviously isn't possible. (Not double as I made the mistake of assuming in my first post)

What we can do however, is up the video clock FREQA from 4x to 8x, which gives us a 65MHz video clock rate. Which means we can now output with a clk/pixel of 1 when using 1024 pixels, 2 when using 512 and 4 when using 256 pixels. As we've doubled the clock rate and doubled the number of active pixels from 512 -> 1024 and because we're outputting 1 pixel per clock, the HSync pixels are no longer correct and need doubling up too to give 24, 136, 160.

At least, that's how I _thought_ it would work. But as it turns out, it doesn't work unless I use a PLL of x2 rather than x8 which doesn't mesh with my idea that if FREQA is producing 32.5MHz @ 4xPLL it should produce 65MHz @ 8xPLL? Or does PLL work in reverse? Such that a 2xPLL gives a 65MHz signal rather than 8x?

I feel I'm very close to finally understanding this all as I've now managed to get a good signal output at 256x768, 512x768 and 1024x768 where the first is pixel doubled by prop and then monitor, the second pixel doubled by monitor and the last not doubled by anything. (only case I've not tried is 512 pixel doubled by prop, but that should work based on the above reasoning too)

Any ideas on the PLL discrepency?

Apologies for the long post, but I wasn't sure how much detail you'd like.

Post Edited (Gary Preston) : 7/15/2007 5:51:33 PM GMT