Wierd screen issue

[wally86]

I have gbs control up and running fine. I'm using a S-Video to Component transcoder (Koryuu). It just converts the signal, no scaling or lag. I'm getting wierd screen issue. The picture flashes in and out and has a tearing like effect. I've tried a few option with no improvements. Any help would be appreciated. Thanks

Video of problem. If it will help.

[wally86]

https://i.imgur.com/rXebxPR.jpg

[ramapcsx2]

Hey,
you need to give a little more detail. What is the format that goes into the GBS, and what kind of cabling do you use?

[wally86]

N64 via S-Video which is being transcoded to Component video. I'm using component cables connected to the component IN on the gbs 8200.

[wally86]

I was talking to amoore2600. He told me that it's probably the Sync on Green capacitors that are causing the video to go crazy. Can you confirm this? If so will these here work?

https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.com%2Fulk%2Fitm%2F163399061673

[ramapcsx2]

Yes, they'll make sync separation easier, but this shouldn't be required.
Any other Component source works just fine, so yeah..

[tvirusx]

Hi, there... while we are talking sync. does the GBS8200 have any issues with CSYNC signal???? I have a snes mini and I installed that Voultar board to restore RGB and when I pull sync through LUMA e work beautifully but from CSYNC there are some instabilities on the signal some flickering.. so am just using LUMA, but on the Genesis that I have, I have to get the signal from sync on composite, so the signal has a lot of interference. any thoughts??? I replaced the R34 resister like the wiki and c33 and c35.

The funny part is that I recently bought the Retrotink Scart 2x and it does not accept CSYNC, only LUMA or sync on composite according to Mike, but the image on the GBS at 1080p is way WAY crisper and better on my opinion. Great job to you guys on this project.

[wally86]

Yes, they'll make sync separation easier, but this shouldn't be required.
Any other Component source works just fine, so yeah..

https://videogameperfection.com/products/koryuu-transcoder/

This is the transcoder I have. Im new to the whole sync/csync stuff. I don't have the means to having my n64 RGB modded, so S-Video is my only option.

[tvirusx]

Did

Yes, they'll make sync separation easier, but this shouldn't be required.
Any other Component source works just fine, so yeah..

https://videogameperfection.com/products/koryuu-transcoder/

This is the transcoder I have. Im new to the whole sync/csync stuff. I don't have the means to having my n64 RGB modded, so S-Video is my only option.

Did u try composite from N64 to Koryuu and then to the GBS???? did u go to the WEB interface and try diferente resolution????

[wally86]

I did try composite. Same issue. I have tried every resolution in the control panel. Still the same. :(

[ramapcsx2]

CSync is the pure form of the same signal that it embedded in Luma (Luma is black and white video + CSync) and also Composite Video (black and white + color + CSync).
So the logic is the same, but the voltage level and stability differs.

If CSync from a modded SNES Mini doesn't work, then I'd start checking the cable.
The cable should have the components (maybe a resistor, maybe none) on the Sync line that the mod requires.
Voultar usually specifies what the cable should have.

[ramapcsx2]

Extra note: This applies only to SCART / VGA type connections, not the Component input.
The Component input should just work, no modifications required (unless the source does something funny, or the GBS board has a defect, or the cable is bad).

[wally86]

Not sure if this helps at all. But I have ran my transcoder into the component on the gbs without the esp8266 and it outputs the picture fine. (Well as fine as the stock board can do)

[ramapcsx2]

This suggests a timing problem that I haven't encountered yet.
I developed gbscontrol using home consoles. All consoles that have a Component option have been tested and work, from 240p to 1080p.

If you have access to logs, please paste a few lines here. Maybe I can see something (but probably not).

[wally86]

Since I'm having trouble with the component in. Could I use this Scart to VGA adapter, then add the S-Video to Scart adapter to that so I can use my n64 via S-Video?

[wally86]

What does it mean when the esp8266 keeps blinking blue and the picture is scrambled and flickering in and out?

[wally86]

*h: 428 v: 475 PLL:0 A:7b7b7b S:07.10.00 H- I:40 D:058c m:0 ht:3566 vt: 273 hpw: 264 u: 21 s: 0 S:14 W:31
h: 428 v: 475 PLL:0 A:7b7b7b S:07.10.00 H- I:40 D:058c m:0 ht:3567 vt: 273 hpw: 264 u: 22 s: 0 S:14 W:31
h: 428 v: 475 PLL:1 A:7b7b7b S:07.10.00 H- I:40 D:058c m:0 ht:3565 vt: 266 hpw: 263 u: 28 s: 0 S:14 W:31
h: 428 v: 475 PLL:1 A:7b7b7b S:07.10.00 H- I:40 D:058c m:0 ht:3566 vt: 266 hpw: 264 u: 29 s: 0 S:14 W:31
h: 428 v: 475 PLL:0 A:7b7b7b S:07.10.00 H- I:40 D:058c m:0 ht:3565 vt: 266 hpw: 130 u: 2a s: 0 S:14 W:31
h: 428 v: 475 PLL:0 A:7b7b7b S:07.10.00 H- I:40 D:058c m:0 ht:3565 vt: 266 hpw: 264 u: 2b s: 0 S:14 W:31
h: 428 v: 475 PLL:0 A:7b7b7b S:07.10.00 H- I:40 D:058c m:0 ht:3565 vt: 266 hpw: 264 u: 2c s: 0 S:14 W:31
h: 428 v: 475 PLL:0 A:7b7b7b S:07.10.00 H- I:40 D:0508 m:0 ht:3566 vt: 266 hpw: 263 u: 2d s: 0 S:14 W:31
h: 428 v: 475 PLL:0 A:7b7b7b S:07.10.00 H- I:40 D:058c m:0 ht:3565 vt: 266 hpw: 130 u: 2e s: 0 S:14 W:31
h: 511 v: 475 PLL:0 A:7b7b7b S:07.10.00 H- I:40 D:058c m:0 ht:3565 vt: 278 hpw: 263 u: 2f s: 0 S:14

[wally86]

That is with my Koryuu running N64 via S-Video to Component on gbs

[wally86]

(WiFi): AP mode (SSID: gbscontrol, pass 'qqqqqqqq'): Access 'gbscontrol.local' in your browser

Chip ID: 1A 1

Activity detected, input: Component

2345678
Format change: 1
ADC offset: R:46 G:44 B:45

preset applied: 720x480 for NTSC 60Hz

.* (debug) ign. length: 0x4E

.* (debug) ign. length: 0x4C

.* (debug) ign. length: 0x4C
.* (debug) ign. length: 0x4E
..* (debug) ign. length: 0x53
(debug) ign. length: 0x63

.* (debug) ign. length: 0x4C

.* (debug) ign. length: 0x4E

.* (debug) ign. length: 0x4E

.* (debug) ign. length: 0x50

..* (debug) ign. length: 0x4E

[ramapcsx2]

It is a software problem with the sync signal that the Koryuu produces. This is what I can tell from the log.
I would need access to your setup to fix it, or at least a Koryuu unit here.

I wonder what's so different with the signal, over all the other sources that I've tested so far..

Anyway, you may have some success swapping the SOG capacitor for the Component input.
The software is marginal / almost accepting the sync, so the capacitor change might push it over the threshold.
https://github.com/ramapcsx2/gbs-control/wiki/Sync-on-Green-Capacitor-Replacements

[ramapcsx2]

Ah, one more suggestions:
Since this is the Component input, I may not be very aggressive adjusting an important sync separation parameter on it.
You can try accessing the web interface, go to the developer tab, and hit the "SOG Level--" button a few times.
This may or may not work better with "Disable Syncwatcher", which is on the same tab.
You can also enable info prints there, and watch them while tweaking these settings.
You know it gets better when the readouts become more even looking (and the picture gets better :p).

[wally86]

syncwatcher off
Phase: 12 SOG: 11
Phase: 12 SOG: 10
Phase: 12 SOG: 9
Phase: 12 SOG: 8
Phase: 12 SOG: 7
Phase: 12 SOG: 6
Phase: 12 SOG: 5
syncwatcher on
(debug) ign. length: 0x4D

..* (debug) ign. length: 0x4D

. (debug) ign. length: 0x62
.*Phase: 12 SOG: 4
(debug) ign. length: 0x4D

.*Phase: 11 SOG: 3
(debug) ign. length: 0x4D

.*Phase: 12 SOG: 2
(debug) ign. length: 0x4B

.* (debug) ign. length: 0x4D

. (debug) ign. length: 0x62
.* (debug) ign. length: 0x4B
(debug) ign. length: 0x62

.* (debug) ign. length: 0x4B

.Phase: 16 SOG: 1

• (debug) ign. length: 0x4B

.* (debug) ign. length: 0x4B

.Phase: 16 SOG: 1

• (debug) ign. length: 0x4D

.* (debug) ign. length: 0x4B

.* (debug) ign. length: 0x4B

.* (debug) ign. length: 0x4B
(debug) ign. length: 0x62

.Phase: 16 SOG: 1

• (debug) ign. length: 0x4B

.Phase: 16 SOG: 1

• (debug) ign. length: 0x4D

.* (debug) ign. length: 0x4D

.* (debug) ign. length: 0x4D

.* (debug) ign. length: 0x4B

.*syncwatcher off
Phase: 16 SOG: 1
Phase: 16 SOG: 0

[wally86]

I pushed the sog level button until it won't go any lower, no difference. When I push syncwatch button picture wasn't flickering in and out anymore, but shaking and scrambled.

[ramapcsx2]

Okay, then it's not the sync level / amplitude, but the sync pulse width or the way VSync is embedded.
It's a problem where I really need to have access to the problem device.

[wally86]

Ok. I got ya. Here is a picture for the 1 second the picture locks in. Looks soooo good. Hope someone can help figure it out.

[wally86]

I know it must be something with the Koryuu, because when I turn on the koryuu the test color lines do the same thing without a input plugged in

[wally86]

Would something like this work better than the koryuu? All the input and output info is in the link.

https://www.ebay.com/itm/Composite-S-Video-to-Component-YUV-RGB-RGsB-Sync-On-Green-Converter-/251001590643

[ramapcsx2]

Probably not, no. Generic converters usually don't work well with games. Expect forced deinterlacing and the likes.

I have asked people in the forums whether they have Koryuu units. Maybe one of them can help.

[wally86]

hopefully someone does. is there any other way to get s-video into the gbs with correct scaling, etc? I'm looking into replacing the capacitors, never done a capacitor before and they are mighty small.

[wally86]

is there any older version of the firmware i could test? maybe get something useful out of.

[tomudo]

is there any older version of the firmware i could test? maybe get something useful out of.

on https://github.com/ramapcsx2/gbs-control, click "### commits" -> click whatever old version -> click "browse file" -> click download

[wally86]

@tomudo thanks.

I got something working, kind of...

I downloaded commit 106c463 from Jan 14, 2020 picture was flickering only slightly. I was able to push syncwatch at just the right moment and lock in the picture and works with no problem.

[wally86]

[ramapcsx2]

Yes sure, try and find an even older version still.
I added the variable sync window code to support a much wider range of sources, but it isn't perfect.
The more "dumb" (static) version I used before will either work all the time, or not at all.
Sometimes stuff goes like that.
I need a Koryuu to fix the "smarter" version for it. It's obviously a kind of corner case that I don't consider right now, but I don't know which.

[wally86]

Well I wouldn't call the issue resolved. I don't know why I didn't think of doing it earlier. I wanted to use the gbs8200 for N64 and PS1, for games that have resolution changing during mid gameplay. Because my OSSC loses signal for 5-10 seconds every time the resolution changes. What I did was connect the Koryuu via component to the gbs8200 (stock) to component IN. Then connected the VGA out on the gbs8200 to the VGA in on the OSSC. Then set the OSSC to passthru. Looks amazing. No signal lose. And scanlines and all the options of the OSSC.

[tvirusx]

CSync is the pure form of the same signal that it embedded in Luma (Luma is black and white video + CSync) and also Composite Video (black and white + color + CSync).
So the logic is the same, but the voltage level and stability differs.

If CSync from a modded SNES Mini doesn't work, then I'd start checking the cable.
The cable should have the components (maybe a resistor, maybe none) on the Sync line that the mod requires.
Voultar usually specifies what the cable should have.

Found my issue with CSync... I just mod my NES with the RGB board and it works fine via CSync. So that made me go back to basic and recheck everything and the CSync wire was in the wrong hole. Solder it to the proper hole and WOW it works...

[wally86]

Do scanlines still work with 480i? Also does the VGA input on gbs have a low pass filter?

[wally86]

Decided to get a Retrotink 2x to run into gbs control board. No issues.