Disable vertical sync signal when composite sync is enabled

[semi-simple]

Summary of the problem: When composite_sync=1 is set, the HSYNC line carries HSYNC+VSYNC as expected. However, the VSYNC line still carries the VSYNC signal. This creates a number of issues with devices that use a XOR/XNOR gate to combine VSYNC and HSYNC.

Suggested fix: Instead the VSYNC signal should not be sent when composite_sync=1 is set.

Many devices with HD-15 inputs XNOR the HSYNC and VSYNC line to get composite sync. This approach works great with many sources, including sources with separate HSYNC and VSYNC signals and sources with composite sync on the HSYNC line. However with MiSTer it doesn't work since mister doesn't disabled VSYNC on the VSYNC line.

This creates two potential issues:

1. A destination that uses a XOR gate between HSYNC+VSYNC will not work properly if composite_sync=1. In my test many behave erratically in a way that can be hard to debug. Of course a reasonable fix is simply to use composite_sync=0 for those
2. If using a matrix to drive multiple output at the same time, it is not possible with MiSTer to drive outputs that require CSYNC and outputs that use a XOR gate between HSYNC and VSYNC to create their own CSYNC at the same time. Currently there is no good workaround for this.

[semi-simple]

If I understand correctly, this line is what should be fixed: https://github.com/MiSTer-devel/Template_MiSTer/blob/master/sys/sys_top.v#L1476

I don't understand the logic here. Is "| csync_en" at the end really correct and intended?

[birdybro]

If I understand correctly, this line is what should be fixed: https://github.com/MiSTer-devel/Template_MiSTer/blob/master/sys/sys_top.v#L1476

I don't understand the logic here. Is "| csync_en" at the end really correct and intended?

The result of the nested ternary is being OR'd with csync_en. If csync_en is high then VGA_VS is driven high. (I think)

[semi-simple]

Do you have any thoughts why it would make sense to drive it high? Perhaps it's a bug and the intention was to drive it low to precisely avoid the issue I'm describing with devices that do their own HSYNC+VSYNC composition? (i.e. should be & ~csync_en).

[birdybro]

Maybe it's for RGsB output where Sync on Green and Composite Sync are both enabled? Not sure, sorg or someone else would have to answer this to be 100% sure. I was just translating what that code is doing for ya.

To me it looks like treating csync as a clock enable signal for vsync. So synchronizing vsync to csync I guess.

[paulb-nl]

Vsync is driven high because it is used as a voltage source for SCART to switch the TV into RGB mode.

Also Hsync/Vsync are usually active low so driving it high disables Vsync.

[semi-simple]

Thanks for the quick reply, that makes sense. And now that I think about it for a XNOR gate, driving the VSYNC input high should be correct so that the XNOR gate becomes a no-op, duh. I need to look deeper into this.

What is happening though is that with composite_sync=1, going into some sync combinators with VSYNC and HSYNC both connected messes up sync. Perhaps the only "fix" would be to leave HSYNC floating (is that something we can do?). I'll look deeper.

[sorgelig]

Originally VSYNC=1 when composite sync is active.
I need to find out why it was changed.

upd: it's really VSYNC=1 when csync_en=1, so i don't know why it doesn't work for you.
If you are talking about direct_video mode through HDMI->VGA converter then it's impossible to set VSYNC=1 there as converter won't work is such condition.