Understanding the video generator
Mervin
Posts: 8
Today I built this RRGGBBII DAC Circuit for my DIY Propeller board.
I've been reading through the Datasheet and looking at some examples but the operation of the video generator is still not very clear to me.
the RRGGBBII format ofcourse means that I want to use 8 bits of color information per pixel, to give a max of 256 different colors on screen
(The HSYNC and VSYNC will be driven by some other mechanism)
My immediate goal is to draw something on my VGA monitor with support for 256 colors, so I've started making a 'driver' cog
My Propeller runs on a 5Mhz Crystal with PLL16X = 80Mhz.
I'm having trouble with a several things:
- How do I calculate the value required PLLDIV for Counter A for a given resolution Width*Height*8bpp and refresh rate R (50hz or 60hz)
- How do I calculate the values required for the Pixel Clock and Frame clock
- What is this i'm reading about four color mode and two color mode and "2 bit pixels", and giving a pixel array for WAITVID in the datasheet?. does this mean I can't set pixels with a depth of 256 values? and I have to set 16 or 32 pixels at once???
Please give me some info about the required math or small code examples (only C, SPIN, or ASM please)
I've been reading through the Datasheet and looking at some examples but the operation of the video generator is still not very clear to me.
the RRGGBBII format ofcourse means that I want to use 8 bits of color information per pixel, to give a max of 256 different colors on screen
(The HSYNC and VSYNC will be driven by some other mechanism)
My immediate goal is to draw something on my VGA monitor with support for 256 colors, so I've started making a 'driver' cog
My Propeller runs on a 5Mhz Crystal with PLL16X = 80Mhz.
I'm having trouble with a several things:
- How do I calculate the value required PLLDIV for Counter A for a given resolution Width*Height*8bpp and refresh rate R (50hz or 60hz)
- How do I calculate the values required for the Pixel Clock and Frame clock
- What is this i'm reading about four color mode and two color mode and "2 bit pixels", and giving a pixel array for WAITVID in the datasheet?. does this mean I can't set pixels with a depth of 256 values? and I have to set 16 or 32 pixels at once???
Please give me some info about the required math or small code examples (only C, SPIN, or ASM please)
Comments
See App Note 1 http://www.parallaxsemiconductor.com/an001 for calculating the PLLDIV. You basically need to know the pixel frequency (aka dot clock) and then calculate FRQA and PLLDIV based on CLKFREQ.
Pixel Clock & Frame Clock depends on what you are doing. For VGA you usually have Pixel Clock = 1 and Frame Clock = number of pixels per WAITVID (4, 16, or 32 usually during the active part of the screen, as required during sync).
WAITVID accepts two parameters - a four entry palette of 8 bit "colors" (output values for VGA) and a pixel bitstring. Every Pixel Clock PLLA one or two bits are shifted out of the pixel register and used as a lookup to the palette register. If you want 8 bit pixels then you load the palette register with your colors and use %%0123 for the pixel register. However, this method has a maximum dot clock of 1/9th CLKFREQ. 8bpp is also HUB RAM hungry - and you only have 32K total.
I still don't have a clue about how to calculate the required vga clock for a given resolution (aka.. at which interval to let the video generator push out a pixel)
It takes time to load up a waitvid, fetch new values and loop back to load up the next waitvid. Because there are only 4 pixels in an 8bpp frame, low PLLA values might not yield enough time for the Propeller to load the pixels properly, corrupting the display.
I had a hard time locating just the driver post. http://obex.parallax.com/objects/695/ That object contains the driver. The sprite driver in my signature also does full color VGA, and you can see the very tight timing required to get it done at just 256 pixels / scan line, and that's with the lowest sweep frequency that will display on most modern monitors. (640x400 or so interlaced)
Examine that video loop, and use the values in that driver to verify your timing calculations. Once you can calculate those values yourself, then you will be much more able to format pixels on scan lines.
I'm not sure anybody has actually achieved stable sync output with 8 color bits and bit-banged Hsync and Vsync though...
BTW: If you want to get knee deep in the stock VGA.spin driver, I've added a lot of comments to it here:
http://forums.parallax.com/showthread.php?133914-VGA.spin-Explained
http://forums.parallax.com/showthread.php?134552-Barebone-VGA-driver
I got to to be in sync with HUB reads, but getting it to be in sync with VGA PLL I have not tried.
And I think general view on this is to still use VGA PLL for sync, but switch banks when you want it active.