superg wrote:DirkSwizzler wrote:Questions about the gscartsw 3.4 VGA output.
Does the VGA output handle non-csync inputs? I'm assuming that this is one of the reasons the sync stripper is embedded and probably has to turn on for non-csync sources.
Does separating RGBS into RGBHV introduce a line delay similar to LM1881 sync stripping?
Yes, EL1883 (similar to LM1881) introduces a delay in v3.4 VGA output sync. Simply you'll always have that delay on VGA output.
Some comments on your setup: I'd use gscartsw_lite as a final processing unit in your chain, it has least latency and sync regeneration is much faster than EL1883. That is:
gscartsw_v3.4 [utilize SCART output, keep CSYNC off] -> gscartsw_lite (with sync regeneration on) -> XRGB-Mini. Make RGBS your default choice (not RGBHV). Garo can be connected directly to lite using RGBS, it'll be gcompsw -> Garo -> gscartsw_lite. What is left is Dreamcast / Hanzo which can be connected either using ArcadeForge VGA2SCART (this combination is tested by me) or I think you can just get that other thing from beharius, forgot the name, you'll directly get RGBS from Dreamcast not depending on mode. Then you can totally exclude Aten from your chain.
Thanks for the info. Am I wrong or does sync regeneration introduce a (small, but nonzero) line delay even for native csync sources? This, as well as the VGA output and LPF switch I installed on the 3.4 make it seem like a clear winner for end of the SCART chain at least.
I already had the Toro for going from Dreamcast straight to SCART. But I was previously less aware of how to actually use the thing and I think I was getting suboptimal results because I had the switches in the wrong place. Namely the VGA/RGB switch which I had previously assumed selected the output on the box to use. It actually selects 15KHz vs 31KHz signal availability.
Sorry for newb'ish questons guys. Some of this stuff seems like tribal knowledge to me and I just ramped up my interest 6 months ago. I'll go back to assuming that SCART is the gold standard as long as I have an upscaler that accepts 480p and up from it.
It seems I can ignore the Dreamcast VGA problem for now with the Toro outputting RGBS directly. Now just to solve component.
Guspaz wrote:superg wrote:Garo can be connected directly to lite using RGBS, it'll be gcompsw -> Garo -> gscartsw_lite.
This won't work with all consoles: Garo's issues with gscartsw_lite sync regeneration notwithstanding, the Garo's RGBS output is largely incompatible with the OSSC (for 240p at least) due to the incorrect way it combines HV sync. Workarounds include using the Garo's RGBHV output on the OSSC, or using an external sync processor to combine the Garo's RGBHV into RGBS. I just tested that tonight, with the following chain:
SNES (YPbPr) -> gcompsw (YPbPr) -> Garo (RGBHV) -> Extron SC210 (RGBS) -> gscartsw_lite (RGBS) -> OSSC (RGBS)
This chain appears to work correctly from a sync standpoint. However, the following chain does not appear to work with 240p sources (tested with Wii, GameCube via HDR cable, SNES via HDR cable):
SNES (YPbPr) -> gcompsw (YPbPr) -> Garo (RGBS) -> gscartsw_lite (RGBS) -> OSSC (RGBS)
While the Extron SC210 doesn't solve the Garo's issues with the RGB lines themselves, it at least bypasses the Garo's sync issues.
Just a data point for Garo RGBS vs RGBHV. I just tried XBox 1080i -> gcompsw -> Garo (RGBHV VGA output) -> Kenzei (RGBS SCART output) -> a couple gscartsw configs.
Hooking the Kenzei output to gscartsw 3.4 port 7 (specifically avoiding port 8 where it worked before) works just fine!
Hooking the Kenzei output to gscartsw_lite to gscartsw 3.4 port 7 (still avoiding 8 where it worked before) works fine with sync regeneration on and off.
So it looks like maybe I can avoid buying an Extron and massage the Garo's output with a Kenzei. Plus, keeping the Kenzei in the chain means I leave myself an open door for using the Aten to hook up other VGA sources. All funneling to RGBS SCART on the 3.4 for maximum auto-switching goodness.