mickcris wrote:
I looked back a couple pages to your install pic and it looks like you have sync connected to the composite sync pin on the HuC6260. remove that and just use the composite video signal going to the din jack. that composite signal directly from the IC will not work with the gscartsw_lite and is probably why the sync stripper needed to be added. using the stock composite video at the din jack will work fine.
I can definitely confirm that composite sync is a way to go. Composite sync is the default and I test everything in that mode.
Honestly I don't get the current trend when we complicate our setups by using csync / sync-on-luma cables, TTL etc. True, it solves some specific problems mostly due to the issues presented by other devices For instance some RGB monitors accepting only csync which can be solved in a more elegant way just by adding one sync stripping IC before monitor input (which is not needed if gscartsw sync regeneration is used). But in general it introduces more problems than it solves. I spent years making those switches and 95% of all the problems involve cable integrated sync stripping (LM1881) / csync cable / sync-on-luma / improperly modded console sync circuit. Almost all the old RGB-SCART cables used composite sync by default. And from consumer standpoint it's very hard to manage all specific sync information like having the correct resistor on a TTL sync line, most of owners have no idea how to check that, they've just purchased the RGB-SCART CSYNC cable because they heard that CSYNC is the best cable because somebody said that.
Inb4 somebody mentions analog signal interference: composite video affects RGB lines as much as every other RGB line affect each other, and all interference is minimal if fully shielded cable is used. And it's all theoretical as visually I can't tell the difference.