Soooo looking forward to this. I'll definitely be swapping out my "handle everything that isn't already csync" lite with the RGsB support.superg wrote:Yes, it will properly separate sync signal and remove it from green channel. You'll get legit RGBS on the output.the Goat wrote:Can you elaborate on the planed sync on green support? Will it automatically convert RGsB input to RGBS or RGBHV output?superg wrote:I'm working on a newer version of gscartsw, it will finally have input protection (WindyGaming SUPERGUN damage and similar) and second there will be Sync on Green support.
gscartsw / gscartsw_lite / gcompsw switches support thread
-
DirkSwizzler
- Posts: 548
- Joined: Fri Apr 28, 2017 8:23 pm
- Location: Bellevue, Washington, USA
- Contact:
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
I personally have several switches (SCART, BNC and VGA) and also have couple consoles that can output RGBHV which makes it incompatible with SCART. I also have two professional monitors that can take RGBS or RGBHV
Last edited by haightc on Tue May 15, 2018 4:18 pm, edited 1 time in total.
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
How having RGBHV makes it compatible with SCART? You have to have composite sync, that's why RGBS.haightc wrote:I personally have several switches (SCART, BNC and VGA) and also have couple consoles that can output RGBHV which makes it compatible with SCART. I also have two professional monitors that can take RGBS or RGBHV
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
8:2 please.superg wrote:It's either 4:2 or 8:2.mj23kb08 wrote:SuperG,
I realize you're still in the re-design process with both of these products, but are you leaning a particular way in regards to changing the number of gcompsw inputs at the moment?
Framemeister 240p scanline settings: http://shmups.system11.org/viewtopic.ph ... start=9600
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
For SOG compatibile switching just keep some form of sync on scart pin 20. Its not that hard.thebigcheese wrote:Sync on luma cables work fine with the switcher. I've been using it with my PS1 for a while now. Sync on green does not (currently) because the sync travels on the same line as green. The switch needs a separate sync line to detect the input. In general, though, I'd stick with c-sync wherever possible. Just makes things easier.
-
DirkSwizzler
- Posts: 548
- Joined: Fri Apr 28, 2017 8:23 pm
- Location: Bellevue, Washington, USA
- Contact:
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
I'm not an expert. But isn't it slightly harder than patching green into a second pin? Doesn't doing that introduce too much load on the console output and either cause damage or reduce your green levels?Syntax wrote:For SOG compatibile switching just keep some form of sync on scart pin 20. Its not that hard.
And if I'm not mistaken, PS2 RGB doesn't output anything on the composite or luma lines in higher resolutions. So you can't use any other source other than green at higher resolutions.
Combining the two problems means you have to put some active distribution circuitry in the cable somewhere.
I could totally be wrong though.
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Yep your absolutely correct for PS2, and I think the same applies for dreamcast.
They both shut down comp video as a safety feature when jumping to 31k modes.
So using comp video as your sync switch works until you change to 31k then its gone.
Using csync on that pin works.
I tend to forget as my ps2 has SOG turned off and 3 output ports, (the standard AV and 2 VGA ports, one runs HV sync the other Csync)
They both shut down comp video as a safety feature when jumping to 31k modes.
So using comp video as your sync switch works until you change to 31k then its gone.
Using csync on that pin works.
I tend to forget as my ps2 has SOG turned off and 3 output ports, (the standard AV and 2 VGA ports, one runs HV sync the other Csync)
Last edited by Syntax on Tue May 15, 2018 2:40 am, edited 1 time in total.
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
You're correct, in order to properly split Green to two you have to amplify the signal.DirkSwizzler wrote:I'm not an expert. But isn't it slightly harder than patching green into a second pin? Doesn't doing that introduce too much load on the console output and either cause damage or reduce your green levels?Syntax wrote:For SOG compatibile switching just keep some form of sync on scart pin 20. Its not that hard.
And if I'm not mistaken, PS2 RGB doesn't output anything on the composite or luma lines in higher resolutions. So you can't use any other source other than green at higher resolutions.
Combining the two problems means you have to put some active distribution circuitry in the cable somewhere.
I could totally be wrong though.
-
- Posts: 1974
- Joined: Wed Jul 19, 2017 1:52 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Without hard mods, it is. When the PS2 switches to 480p/RGsB, it cuts off both composite video and luma. You'd either need to amplify and split green to pin 20, or buy one of superg's RGsB->RGBS shims, assuming they're still going to be developed/released.Syntax wrote:For SOG compatibile switching just keep some form of sync on scart pin 20. Its not that hard.thebigcheese wrote:Sync on luma cables work fine with the switcher. I've been using it with my PS1 for a while now. Sync on green does not (currently) because the sync travels on the same line as green. The switch needs a separate sync line to detect the input. In general, though, I'd stick with c-sync wherever possible. Just makes things easier.
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
I'm expecting the new gscartsw SoG prototypes to arrive early next week, it will take another week to debug firmware before I start testing.
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Hey SuperG,
I have the original Gscart and the Lite. Am i missing anything else besides the Supergun protection and the SOG compatibility on the new design? Also when is SOG useful? I only use the typical SNES, NES, PS1, PS2, DC, GC, etc and all work fine with RGB Csync or Luma.
Just trying to figure out if i need a 3rd Gscart :p Or if the new features i won't need.
Thanks
I have the original Gscart and the Lite. Am i missing anything else besides the Supergun protection and the SOG compatibility on the new design? Also when is SOG useful? I only use the typical SNES, NES, PS1, PS2, DC, GC, etc and all work fine with RGB Csync or Luma.
Just trying to figure out if i need a 3rd Gscart :p Or if the new features i won't need.
Thanks
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
SoG will be useful only for PS2. There is some professional equipment which outputs SoG (mainly Sony) and also there is a speculation that some early home PC's were outputting SoG, personally I haven't seen other cases except PS2. The switches you own are OK, I don't expect any quality differences. Now when we talk about Supergun, the switch won't fix the root issue (you won't get any sound or garbled sound), it will just be protected from being fried.magus90 wrote:Hey SuperG,
I have the original Gscart and the Lite. Am i missing anything else besides the Supergun protection and the SOG compatibility? Also when is SOG useful? I only use the typical SNES, NES, PS1, PS2, DC, GC, etc and all work fine with RGB Csync or Luma.
Just trying to figure out if i need a 3rd Gscart :p Or if the new features i won't need.
Thanks
-
DirkSwizzler
- Posts: 548
- Joined: Fri Apr 28, 2017 8:23 pm
- Location: Bellevue, Washington, USA
- Contact:
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
A few of my non-sony transcoders like SoG (and thankfully usually include a YPbPr option to work around this). But the point holds that SoG is pretty rare.superg wrote:SoG will be useful only for PS2. There is some professional equipment which outputs SoG (mainly Sony)
-
arithmaldor
- Posts: 124
- Joined: Wed Jun 07, 2017 8:39 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Don't forget the OG Xbox with a patched, flashed bios. Nt mini can do it too which is irrelevant as it can do RGBS.DirkSwizzler wrote:A few of my non-sony transcoders like SoG (and thankfully usually include a YPbPr option to work around this). But the point holds that SoG is pretty rare.superg wrote:SoG will be useful only for PS2. There is some professional equipment which outputs SoG (mainly Sony)
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Does one have less "noise" than the other? (RGBs vs RGsB)
-
- Posts: 1974
- Joined: Wed Jul 19, 2017 1:52 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
No. RGB is RGB. Noise usually comes from crappy cables, and sometimes from the console hardware itself.Octo-King wrote:Does one have less "noise" than the other? (RGBs vs RGsB)
-
- Posts: 4
- Joined: Fri Mar 17, 2017 7:03 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Hey guys - Need some help on a CMVS problem (yes I know that can be a bad word around here) When feeding the CMVS through the GSCART I am getting a distorted picture. I think this may be because the resistors have not been done correctly on the CMVS RGB conversion board which I have attached some pics for your viewing pleasure. Please point me in the right direction if there is a better forum to reach out to for assistance. I am more then able to solder and adjust the board with resistors as needed. Additionally, it does work without GSCART in the mix but the picture is extremely bright and over saturated.
BTW I love the GSCART! Never had any issues before and would love to play my CMVS in RGB properly.
BTW I love the GSCART! Never had any issues before and would love to play my CMVS in RGB properly.
Spoiler
-
DirkSwizzler
- Posts: 548
- Joined: Fri Apr 28, 2017 8:23 pm
- Location: Bellevue, Washington, USA
- Contact:
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
I'm not an expert. And nmalinoski is absolutely correct that noise usually comes from crappy cables. I believe that there's a case to be made that any circuitry mixing a sync signal into the green channel is going to produce marginally more noise than keeping it completely separate.nmalinoski wrote:No. RGB is RGB. Noise usually comes from crappy cables, and sometimes from the console hardware itself.Octo-King wrote:Does one have less "noise" than the other? (RGBs vs RGsB)
If there's any truth to that. Then RGBs beats out RGsB by a hair. But worry more about good cables.
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Maybe somebody can chime in, I don't have any experience with CMVS. Also please be careful and don't kill your switch!crazedbinary wrote:Hey guys - Need some help on a CMVS problem (yes I know that can be a bad word around here) When feeding the CMVS through the GSCART I am getting a distorted picture. I think this may be because the resistors have not been done correctly on the CMVS RGB conversion board which I have attached some pics for your viewing pleasure. Please point me in the right direction if there is a better forum to reach out to for assistance. I am more then able to solder and adjust the board with resistors as needed. Additionally, it does work without GSCART in the mix but the picture is extremely bright and over saturated.
BTW I love the GSCART! Never had any issues before and would love to play my CMVS in RGB properly.
-
arithmaldor
- Posts: 124
- Joined: Wed Jun 07, 2017 8:39 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Will the new revision allow for RGsB passthrough without converting to RGBs? Like a switch to turn it on and off? So basically just detection on the green line. If so I'm assuming it would work with YPbPr passthrough as well. If not, how would the switch deal with YPbPr? My old PVM (1953MD which I think is fairly common) could accept RGBs, RGsB (though only 15khz so limited use there), and YPbPr, and so can the OSSC, so I think a passthrough option would be useful.
-
- Posts: 1974
- Joined: Wed Jul 19, 2017 1:52 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
I'm not aware of any devices that are capable of distinguishing between RGsB and YPbPr--they both have the same number of cables, same color-coding, put sync on the same line (green/Y), and both operate within the same electrical specification*. That said, the new gscartsw is expected to completely remove sync from green to get proper RGBS, and such a procedure will leave you with Y/luma without a sync signal, which I would expect to be unusable, unless somehow your PVM/BVM (which would be the only type of display that might be able to do this) is able to display YPbPr using external sync.arithmaldor wrote:If so I'm assuming it would work with YPbPr passthrough as well. If not, how would the switch deal with YPbPr?
(I've suggested that it's possible to determine RGsB or YPbPr, by testing whether B/Pb and R/Pr have a nonzero resting voltage, but the hardware would need to be capable of measuring voltage of these lines between frame data.)
-
arithmaldor
- Posts: 124
- Joined: Wed Jun 07, 2017 8:39 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Yeah I'm really just hoping there is a way to turn this off and detect sync on the green line (Y in YPbPr or Gs in RGsB) for forwarding.nmalinoski wrote:I'm not aware of any devices that are capable of distinguishing between RGsB and YPbPr
-
- Posts: 1974
- Joined: Wed Jul 19, 2017 1:52 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
I agree; it would be nice if superg had a three-way switch for this--off, detect and forward, and detect and convert to RGBS--but it's really up to him.arithmaldor wrote:Yeah I'm really just hoping there is a way to turn this off and detect sync on the green line (Y in YPbPr or Gs in RGsB) for forwarding.nmalinoski wrote:I'm not aware of any devices that are capable of distinguishing between RGsB and YPbPr
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Looking to get a neo-geo console but want to make sure it's compatible with the gscart lite...
Does anyone have any recommendations? A stock AES would be the obvious choice, but it sounds like the later board revisions don't use Csync but rather composite video as sync, would that be an issue with the switch?
Does anyone has any experience with the Omega CMVS?
Does anyone have any recommendations? A stock AES would be the obvious choice, but it sounds like the later board revisions don't use Csync but rather composite video as sync, would that be an issue with the switch?
Does anyone has any experience with the Omega CMVS?
-
axlblazeadam
- Posts: 107
- Joined: Tue Sep 08, 2015 3:16 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
I'm using a Analogue CMVS slim and a gscartsw 3.2. No issues whatsoever.seldinger wrote:Looking to get a neo-geo console but want to make sure it's compatible with the gscart lite...
Does anyone have any recommendations? A stock AES would be the obvious choice, but it sounds like the later board revisions don't use Csync but rather composite video as sync, would that be an issue with the switch?
Does anyone has any experience with the Omega CMVS?
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
I'm not sure if this would be possible but also why would you want such functionality? SoG is pain in the ass exactly because there is no separate sync. You will get legit RGBS on the outputs which is supported by everything. Regarding YPbPr passtrough, Y can go through sync line, this way it won't be separated.arithmaldor wrote:Yeah I'm really just hoping there is a way to turn this off and detect sync on the green line (Y in YPbPr or Gs in RGsB) for forwarding.nmalinoski wrote:I'm not aware of any devices that are capable of distinguishing between RGsB and YPbPr
Forgot to mention, the new gscartsw has microUSB power supply.
(I should get the prototypes today)
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
You went with microUSB when you could have used USB-C? You just lost a sale!superg wrote:Forgot to mention, the new gscartsw has microUSB power supply.
-the Goat
Heliopause Heavy Industries :: video game console repairs and modifications
Heliopause Heavy Industries :: video game console repairs and modifications
-
- Posts: 1974
- Joined: Wed Jul 19, 2017 1:52 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Personally, I prefer Mini USB, because it's more durable, but it's not like these switches are going to be moved around a lot.the Goat wrote:You went with microUSB when you could have used USB-C? You just lost a sale!superg wrote:Forgot to mention, the new gscartsw has microUSB power supply.
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
Newer doesn't mean better. USB-C has too many pins and very fine pitch, I'd say it's overkill just to power up the switch.the Goat wrote:You went with microUSB when you could have used USB-C? You just lost a sale!superg wrote:Forgot to mention, the new gscartsw has microUSB power supply.
True, but microUSB is much more widely available.nmalinoski wrote: Personally, I prefer Mini USB, because it's more durable, but it's not like these switches are going to be moved around a lot.
-
arithmaldor
- Posts: 124
- Joined: Wed Jun 07, 2017 8:39 pm
Re: gscartsw / gscartsw_lite / gcompsw switches support thre
SoG passthrough would pretty much only be useful for OSSC which supports it.superg wrote: I'm not sure if this would be possible but also why would you want such functionality? SoG is pain in the ass exactly because there is no separate sync. You will get legit RGBS on the outputs which is supported by everything. Regarding YPbPr passtrough, Y can go through sync line, this way it won't be separated.
PVMs that support RGB/component on the same input, as well as the OSSC, both expect Y to be on the green pin. That's why detect and forward only, or a default forwarding port (like port 8 on the gscartsw 1.1) would be nice. But I also understand this is very niche. I think 99% of people would be happy without it. And built in SoG conversion is much nicer than having to use an extron box with sync strippers etc.