Why bypass RGB

[Konsolkongen]

Any time someone asks how to achieve the best picture of older consoles you always see someone suggesting to bypass the RGB encoder.

Several years ago before readily made modkits where available I tried bypassing my 1chip SNES's encoder using a THS7314, hoping that it would improve the ghosting as well as jailbars. It didn't, these issues where _exactly_ the same with the bypass installed. Since then people have found solutions to all these issues on the SNES. Capacitors to fix jailbars, replace the C11 capacitor to fix ghosting and add a few resistors to fix the brightness issue.

Through the OSSC I think the image is now pretty much perfect as is. So why would I ever do an RGB bypass?

The same thing goes for the Mega Drive 1. I've tried a bypass board by a reputable modder, to try and fix the jailbars. This did help a little bit, but made some of the color bars in the 240p Test Suite blend together. I contacted the creator of the board and tried a few of his suggestions but nothing changed, so the board had to go. I've since learned that the jailbars in my MD1 is most likely caused by RAM noise, and not the encoder.

The CXA1145 encoder in the Mega Drive 1 is also used in the Neo Geo CD where it produces a pretty perfect and very sharp image, just like the SNES (after the mods mentioned above). So why the fascination with bypassing these original components when they appear to do the job well enough?

[maxtherabbit]

none of my video encoders are bypassed, I think there's a place for it but it's certainly not universally applicable

[Sirotaca]

I will say that my SNES Jr. with Voultar's THS7374 bypass board definitely appears to have less noise than my non-bypassed 1CHIP-03 through my OSSC. But it's not a massive difference.

[fernan1234]

Has anyone noted color reproduction differences when using non-native video encoders? That'd be my main concern with a bypass approach. I imagine they will never be 100% accurate. Same for audio bypass mods in the case of the Mega Drive's sound.

[Classicgamer]

I don't know how many people are fascinated with bypassing RGB encoders but I suspect it is a tiny percentage. Probably the ones who experienced image problems with specific consoles. It's not the sort of thing that springs to mind if you already have a flawless image.

I have been using RGB consoles since the late 80's and it was never a thing until people started using them on HD flat-screens with upscalers. It's possible that some old console revisions produce visible issues when upscaled that can be improved by bypassing or replacing problematic components.

"noise" is a fairly generic description in some people's vocabulary and often covers all kinds of interference, distortions, static as well as scaling and / or deinterlacing artifacts. I have only ever seen the first 3 when using inferior (usually home-made) cables with poor grounding and shielding on CRT monitors. Scaling noise is obviously specific to upscaled content. My 4k OLED has a bunch of extra settings to fix it. I am not sure that any of that is what people are trying to solve with console mods though.

Logically, you only bypass components if they are causing an issue and only when the signal can be taken more cleanly earlier in the circuit. Some scalers, for example, can be fussy about needing clean sync and video separated from sound etc.

It's probably easier to ask, who has bypassed an RGB encoder, which consoles was it done to and why?

[Konsolkongen]

Logically, you only bypass components if they are causing an issue and only when the signal can be taken more cleanly earlier in the circuit. Some scalers, for example, can be fussy about needing clean sync and video separated from sound etc.

It's probably easier to ask, who has bypassed an RGB encoder, which consoles was it done to and why?

I know the theory behind it. A lot of people swear by bypassing the RGB encoders, I see it mentioned here on Shmups all the time. I've tried it on SNES and Mega Drive and saw no real reason to do so.

Surely someone can tell me why they think it's needed. Preferably with some high quality captures to back it up

[Classicgamer]

Logically, you only bypass components if they are causing an issue and only when the signal can be taken more cleanly earlier in the circuit. Some scalers, for example, can be fussy about needing clean sync and video separated from sound etc.

It's probably easier to ask, who has bypassed an RGB encoder, which consoles was it done to and why?

I know the theory behind it. A lot of people swear by bypassing the RGB encoders, I see it mentioned here on Shmups all the time. I've tried it on SNES and Mega Drive and saw no real reason to do so.

Surely someone can tell me why they think it's needed. Preferably with some high quality captures to back it up

My understanding is that it only helps certain Snes revisions so it's possible you have one of the ones it doesn't help. There is a whole thread on this site about snes revisions and rgb image quality. It's also just possible that you aren't as fussy about image quality or you haven't seen two models side by side to notice a difference.

I owned Super Nintendo's /Famicoms, Megadrives, Neo Geo's and Playstations from all three regions and never had any image quality issues but, I use a CRT. And, I never owned two at the same time to compare. I'd also be curious to see some before and after pics to see if it's something I would notice.

I'd be particularly interested to see pics of the difference when used with a CRT monitor (at native res).

[buttersoft]

Since then people have found solutions to all these issues on the SNES.

Have they? On the original 2-chip SNES? I wish someone had mentioned that before i went and laid out Torapu's bypass mod board and ordered the parts... Can you link to some examples of fixes, or provide more info?

[Konsolkongen]

I’m talking about the 1chip models

[kel]

The only reason to bypass the encoder/amp on the 1CHIP SNES is to be able to turn the LPF off. This way you can use a better LPF down the line like the one on the OSSC if going digital. With analog CRT the LPF isn't needed anyway and I'm not really sure why they used one in the original encoder/amp as all that were available back then were CRTs.

[Guspaz]

It's the opposite. The 1chip has no LPF. The older SNES consoles do. That's why the 1chip is so much sharper.

[kel]

The S-RGB chip in the 1CHIP SNES definitely has a LPF. The output looks the same as the THS amps with LPF turned on. The THS amps with LPF turned off look sharper than the S-RGB chip.

The 1CHIP is not sharper than the older SNES because of an LPF, it is because of the problem of longer rise and fall times from the output of the PPU on the older 3CHIP SNES which doesn't affect the output of the "S-CPU N" on the 1CHIP SNES.

[RGB0b]

I've covered this in great detail over the years and even did a livestream on it. It's a combination of moving the signals away from the motherboard, using more modern RGB amps and 1% tolerance components. Here's the long, boring version: https://youtu.be/YTRFCu9hrzs

People often make fun of me for going through so much effort for a 1% difference, but if you have A BVM you'll notice....and if you're using an OSSC on a 65" TV, you'll really notice. It's probably not worth it on a SNES for most people, but bypassing a Genesis is a GIANT difference.

[maxtherabbit]

I've covered this in great detail over the years and even did a livestream on it. It's a combination of moving the signals away from the motherboard, using more modern RGB amps and 1% tolerance components. Here's the long, boring version: https://youtu.be/YTRFCu9hrzs

People often make fun of me for going through so much effort for a 1% difference, but if you have A BVM you'll notice....and if you're using an OSSC on a 65" TV, you'll really notice. It's probably not worth it on a SNES for most people, but bypassing a Genesis is a GIANT difference.

a genesis 1 is a huge difference, a good quality gen2 not so much

on that note - for anyone having subtle vertical banding on an ASIC genesis 2: I recently discovered this can be eliminated on a stock console by stacking a 10uf MLCC on top of C46 (at least its C46 on the VA3)

this is the stock decoupling capacitor for AVCC

[viletim]

A lot of consoles have poor motherboard layouts which run the analog video traces near data lines with fast edge transitions. Crap from the data line couples into the video signal before it gets to the video encoder chip. Specific versions of Sega Master System, Mega Drive, and Neo Geo consoles suffer from this the most. Bypassing the video traces is one way to solve the problem. Sometimes it's easy to mod the motherboard, such as by isolating the part of the data line which is close to the video signal and jumping with some jumper wire. The trouble is that there's lots of different motherboard versions out there. I think lots of people find it easier to install a bypass mod than try to figure out what's wrong with a given motherboard layout. Nintendo covers their motherboards with opaque solder mask which doesn't help.

[Konsolkongen]

I've covered this in great detail over the years and even did a livestream on it. It's a combination of moving the signals away from the motherboard, using more modern RGB amps and 1% tolerance components. Here's the long, boring version: https://youtu.be/YTRFCu9hrzs

People often make fun of me for going through so much effort for a 1% difference, but if you have A BVM you'll notice....and if you're using an OSSC on a 65" TV, you'll really notice. It's probably not worth it on a SNES for most people, but bypassing a Genesis is a GIANT difference.

That's quite the long video, I'm not sure I'll have time to sit through it any time soon. But thank you for posting it

With my now fixed SNES 1Chip and OSSC with optimal 256x224 in 5x mode, I find it hard to believe that there is any benefit to bypassing. The signal is already about as perfect as one could imagine. There is zero bleed, and everything is razor sharp too. Really glad I heard about that C11 replacement to fix that damn ghosting because that really bothered the hell out of me

Viletim's explanation makes sense for the Mega Drive. This explains why the first bypass method I tried did improve jailbars slightly. But since it made the colors blend together it was overall not preferable to the jailbars.
I've also tried a method similar to Voultars current bypass, but that made no difference at all for me. The jailbars were exactly as visible with this method. I followed the installation method as shown in one of your videoes Bob. It might have been improved had I used shielded wires from the bypass circuit to the AV out. But then wouldn't it work just as well by copying and shielding the original circuit between VDP and the CXA1145? Has anyone tried this or is the CXA1145 placed so close that it's contaminated by the RAM noise?

[copy]

I've covered this in great detail over the years and even did a livestream on it. It's a combination of moving the signals away from the motherboard, using more modern RGB amps and 1% tolerance components. Here's the long, boring version: https://youtu.be/YTRFCu9hrzs

That's quite the long video, I'm not sure I'll have time to sit through it any time soon. But thank you for posting it

It's a fun one, though. Voultar even plays guitar. I had it on in the background while soldering on a recent Saturday.

[Classicgamer]

I've covered this in great detail over the years and even did a livestream on it. It's a combination of moving the signals away from the motherboard, using more modern RGB amps and 1% tolerance components. Here's the long, boring version: https://youtu.be/YTRFCu9hrzs

People often make fun of me for going through so much effort for a 1% difference, but if you have A BVM you'll notice....and if you're using an OSSC on a 65" TV, you'll really notice. It's probably not worth it on a SNES for most people, but bypassing a Genesis is a GIANT difference.

I'm curious what started you off on the project? Did you see two different models side by side and wonder why yours looked worse? Or did you just read about it and couldn't live with not having the best possible set-up?

I think it's something about the way our eyes work but I often don't notice minor differences in clarity unless I am used to the clearer one, or I see them next to each other. After that, a slight loss in clarity becomes a hard to ignore irritant. It's why I am OK with games designed to be 480i but I can't even look at 240p games presented in 480i.

Also, did you test it out to see if the issues were visible on a crt (in native res)?

[SamIAm]

I've got a few broadcast monitors and several consoles hooked up with RGB. When I use the 240p test suite across multiple systems at once, I notice that my 1CHIP SFC's green signal is slightly stronger than it should be. My current assumption is that it's the 10% (20%?) tolerance parts, in particular the resistors, in the original video circuit that's causing this. Right now, I'm debating whether to try replacing the resistors or to simply get a bypass board. So there's one example, I guess.

[Konsolkongen]

The tolerance in resistors is not enough to cause the much brighter image of the 1Chip. This is just the design of this system and it’s there on every console. You need to pull the RGB signals to ground with 750 ohm resistors which fixes this.

[SamIAm]

The tolerance in resistors is not enough to cause the much brighter image of the 1Chip. This is just the design of this system and it’s there on every console. You need to pull the RGB signals to ground with 750 ohm resistors which fixes this.

That would only be the case if all three signals were too bright, but as I wrote in my post, it's only green.

Let me explain. I can adjust a monitor based on the 240p suite's Color Bar test using a Mega Drive, RGB-modded PC Engine, Dreamcast, and even a PC, and arrive at a single calibration that will show the colors in balance for all of those systems. Then I can send in video from my 1CHIP SFC and the green is obviously brighter than it should be, by a very small margin. It's really only visible at the darker end of the spectrum.

FYI, I've already done the 750 ohm resistor fix, with 1% tolerance parts.

[Konsolkongen]

Sorry about that. I was apparently much too tired this morning when I read your post. That does sound like off spec components in your SNES. I haven't measurement the white balance of mine, but I do have a colormeter if that’s something you would like me to try.

[kel]

The tolerance in resistors is not enough to cause the much brighter image of the 1Chip. This is just the design of this system and it’s there on every console. You need to pull the RGB signals to ground with 750 ohm resistors which fixes this.

That would only be the case if all three signals were too bright, but as I wrote in my post, it's only green.

Let me explain. I can adjust a monitor based on the 240p suite's Color Bar test using a Mega Drive, RGB-modded PC Engine, Dreamcast, and even a PC, and arrive at a single calibration that will show the colors in balance for all of those systems. Then I can send in video from my 1CHIP SFC and the green is obviously brighter than it should be, by a very small margin. It's really only visible at the darker end of the spectrum.

FYI, I've already done the 750 ohm resistor fix, with 1% tolerance parts.

From the SNES consoles that I've modded the RGB signals were unbalanced on all of them, each console in a different way. Even if I had of bypassed the amp and then replaced the 150/160ohm resistors on the RGB lines between the DAC and GND to compensate for any difference in tolerance or drift the RGB signals would still be unbalanced. It seems to me that the problem is in the DAC itself and the only sure way that I could balance them would be to replace the 150/160ohm resistors on the RGB lines between the DAC and GND with slightly different values from each other based on measurements and calculations.