Sync on green VGA
Andrey Demenev
Posts: 377
Is it possible to generate VGA with sync on green? I know there is one pin VGA, but I think it wont work well with high pixel clock rates. I need a circuit that would generate color VGA different sync signals (H/V sync, composite sync or SOG) selectable in software
Comments
Green Sync VGA.bmp
So the first step is to understand what is required from an external hardware perspective. You will likely want/need to add tie at least one pin into the (via a resistor) green output, depending on the number of levels you require and whether you can use DUTY to create additional levels. Then you need to understand the sync waveforms (timing etc). Finally you need to modify / code a video driver to create those waveforms and the active display.
A while back I tried to create a RGB+composite sync driver for SCART based on TV.spin & VGA.spin but the sync code for those drivers is hairy, and I lost interest.
I think hardware-wise it would be simpler to use 8 pins for RGB, another 2 pins for H/V and composite sync, and yet another pin for SOG. When doing composite or H/V, that last pin is hel high and does not affect green levels. In SOG mode, composite sync is output on that pin, creating sync pulses on green channel. This would require 2 synchronized cogs though, but it also has advantage of more colors (256 instead of 64).
The main question for me here is voltage levels. From what I have read, it appears that levels are 0 for blank, 0.7 V for white, -0.3 V for sync . But some systems (XBOX for example) cannot generate negative voltage, and the entire signal is offset by 0.3V.so sync is 0, and white is 1 V - and that seems to work. I guess I'll have to try and figure out
Video input is typically AC coupled with a level detection / clamp circuit. So the fact that sync is DC = 0V doesn't affect the input which clamps it so blank is 0V. And with AGC the actual levels don't have to be absolutely correct, just the relative magnitudes.
.. except the application nature, and personal preferences In my application, the code is generated on the fly based on video output parameters(pixel clock, resolution etc), maximum is 2048x1536@60Hz so far. I would prefer to keep all calculations based on pixel clock rather than introduce another variable (Propeller clock). But that's only me though
Perhaps you're right. I guess it matters if 4 CLK is a significant number of pixels. But my experience is with TV where the pixel clock is lower and overscan means centering is variable anyway.