Shop OBEX P1 Docs P2 Docs Learn Events
Sync on green VGA — Parallax Forums

Sync on green VGA

Andrey DemenevAndrey Demenev Posts: 377
edited 2011-03-31 05:44 in Propeller 1
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

  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-27 07:49
    Try something like this (have not tested). This should work at least for HSync. I think that for VSync they use a negative pulse on the sync on green (do not remember for sure).

    Green Sync VGA.bmp
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2011-03-27 08:36
    I know that on my LG monitors there are very hard black level clamps in the sync areas. This would hate the syncs being put there.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-27 09:14
    There were some monitors that required Sync on green, produced in the 1990s. I would assume that Andrey is using such a monitor.
  • potatoheadpotatohead Posts: 10,261
    edited 2011-03-27 15:21
    SGI used sync on green regularly.
  • ericballericball Posts: 774
    edited 2011-03-29 11:27
    There's no reason the video generator can't generate VGA with sync on green. The standard VGA driver uses WAITVID to control the HSync & VSync pins. From the video generator's perspective it's just outputting 8 bits to 8 pins. The software & external hardware define what they are.

    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.
  • Andrey DemenevAndrey Demenev Posts: 377
    edited 2011-03-29 15:51
    The question was actually about the hardware. I have no problem generating composite sync.

    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
  • ericballericball Posts: 774
    edited 2011-03-30 05:53
    There's no reason the sync can't be generated by the same COG as the active video. Just put the correct OUTA after the WAITVID.

    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.
  • Andrey DemenevAndrey Demenev Posts: 377
    edited 2011-03-30 15:33
    ericball wrote: »
    There's no reason the sync can't be generated by the same COG as the active video ...

    .. 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
  • ericballericball Posts: 774
    edited 2011-03-31 05:44
    I would prefer to keep all calculations based on pixel clock rather than introduce another variable (Propeller clock).

    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.
Sign In or Register to comment.