Removing RGB jail bars idea?

[isleofthedamned]

I don't know if its been discussed yet and I know I'm late to the party but the blue jail bars went away once I got a Framemeister. I know it's an expensive solution but I totally worked for my model 1, 2 and 32x.

[nissling]

The Framemeister isn't as sensitive to jailbars as an RGB monitor. In picture mode they will only appear at fractions of the image and once scanlines are added you will most likely not see them at all. In standard mode, the signal will go through a low-pass filter which to my experience eliminates the jailbars. It may slightly reduce textures but I haven't seen any loss so far. Great thing.

[phoenixdownita]

I have a Mini, that's how I saw how bad the jailbars were in RGB/Scart.
So I need a more drastic solution.

[phoenixdownita]

Cut encoder "Pin6" from under the 5660 chip and rewired with a long twisted pair that never crossed the 3 RGB, no dice.
[I went the other way on the new wiring to make sure I stayed as far as possible from the 3 RGB lines]
The change didn't even look it helped. I really hoped that I could "average" the jailbars via isolating the chroma subcarrier .... oh well, it was worth a try.
[this is on a NTSC MD2 VA1.8]

[Helder]

Try one of the pcbs that ArcadeTV made for clean RGB:
http://www.sega-16.com/forum/showthr...S1-SMS2-NG-AES

When I was messing with getting rid of jailbars the Blue line is what carried them and this was on a MD2 VA1.8 also. The other colors had nothing but the blue did have the lines and I have no idea as to why since it runs parallel with the red and green lines up till it gets to the encoder.

[phoenixdownita]

Thanks for the pointers but those boards pretty much kill off any other video but RGB and for me it's a no-no.

I do have an XRGB Mini that I CAN use with RGB, but truth be told direct SVideo to TV is not half as bad for me and faster to hookup (needless to say SVideo carries the exact same jailbars).

So I am looking for a solution that keeps Composite/SVideo (I mod my systems personally) and fix the jailbars on RGB.
I tried going thru a 32X and then out via RGB but it's the exact same.

I am not entirely sure the blue line is the only one with issues in my case, although it seems to carry the brunt of it. I basically see it everywhere, obviously games like Xenon2 being mostly black mask the effect quite a lot.
Notice that I swapped out the stock sKA2195 for a CXA2075 ... I wonder if that amplifies the jailbars further ... not that I had a choice as I wanted SVideo anyway.

[Helder]

While I was messing with a way to get rid of composite jailbars (unsuccessful) I had tried numerous things including cutting the clock feeding the NTSC/PAL signal and feeding it my own clock and the bars are still there. I also separated the RGB lines and passed them through a THS7314 after I cut the traces going to the Encoder and and fed the amplifies RGB lines into the encoder and still had bars but not as bad but this was on composite as I was trying to keep that working as well. So in the end no idea where the damn jailbars are coming from and fyi the clock signal from my own oscillator and the one produced on the Genesis motherboard are strong and pickup interference easy.

[Firebrandx]

The Framemeister isn't as sensitive to jailbars as an RGB monitor.

Depends on the scaler settings (and also if using RGB cables). Turning Auto_Scaler to "Off" and setting H_Scaler to "4" and V_Scaler to "6" will give a much sharper picture without any artifacts. The jailbar interference on the blue signal of my Genesis was painfully obvious, but thankfully the trace interruption to pin 6 on the CXA removed the jailbars completely.

Also, only "Picture" mode is meant for 240p gaming. All the other modes (Natural, Game_1, Game_2, etc.) are deinterlacing modes meant for 480i gaming. Never use them for 240p as it introduces extra processing that simply isn't needed.

Here are some notes I put together about general Framemeister usage:

http://www.firebrandx.com/generalframemeisternotes.html

[t0nito]

I still say the easiest way isto lift and ground pin 6

[phoenixdownita]

... lifting pin 6 alone does not work, don't you also need to make sure sync does not come from composite, which normal cables do?

[t0nito]

... lifting pin 6 alone does not work...

That's why you also need to ground it.

[phoenixdownita]

The plot thickens.

As already stated I am using a XRGB Mini. I purchased a Scart to JP-21 adapter so that I can connect all my Scart consoles.

My Genesis 2s and my SMSs (both US and JP) have very heavy jailbars as already stated. So today I decided to install an LM1331 sync stripper in the adapter, I have it with a switch so I can use either straight composite or "sync stripped"-composite.
What do you know!?!?!!, the sync stripped signal has remove jailbars from my Genny 2s [2 of them all with a CXA2075] and made them extremely faint on SMSs (both US and JP) to the point I can barely tell. I did not modify the relative Scart cables in any way, they do not take sync from special pins on the console at all, everything is without mods as far as Scart cabling is concerned.

The nice part about the switch is that I can change it live to see the effect, the LM1331 circuit itself is always ON, simply the switch relays to the Mini either the pure composite as coming from the console (which at the same time is fed to the LM1331) or the sync-stripped version as coming out for the LM1331, as simple as that.

Now for the question, why on hell would cleaning the composite signal have any effect at all on jailbars over RGB?
The way I understand it is that over RGB intensity is carried over via the R, G and B, there's nothing in the sync signal related to either luma or chroma so cleaning the "sync" signal should have very little to do with jailbars (as we assumed they were present on the RGB themselves) ... and yet, at least thru the Mini big difference.

Anyone care to explain?

[Helder]

The same way the NESRGB has image artifacts like dot crawl(?) when you use composite video for sync but the image is fine with CSYNC. Composite video has too much shit in it that causes interference and unstable images when using it as a Sync source (try Luma instead of Composite for Sync). It's been confirmed that the clock signal adds some jail bars and I'm sure it makes it's way into the composite video signal.

[phoenixdownita]

Bear with me and thanks for the post but I am not totally satisfied by the explanation, there's gotta be more to it than "noise".

If composite is used as source of sync only it CANNOT introduce jailbars as those are the result of either luminosity changes or color changes, but both of those in RGB are carried over the other lines.
AFAIK only sync info is used from the composite (or sync stripped version of it), that is HSync and VSync combined, neither of which carries any per pixel info, those are the realms of the RGB lines.

Only thing that comes to mind is that when the rest of info is present then some intermixing happens in spite of declaring that only sync is used out of the composite signal. I'm no expert but if the "clock" pulses are present in the original RGB lines I don't see how using a sync-stripper on the composite signal can fix that.

[rama2]

Genesis jailbars are high speed signals creeping into the RGB signal and analog 5V lines.
This can be fixed by adding lots of capacity to the 5V line, also placing small capacitors close to the VDP pins.
Also required is heavy shielding of the RGB lines from the VDP memory bus. Earthed copper foil placed carefully does that.
The final "polluter" is indeed the 3.57Mhz subcarrier clock, so disconnecting it at the VDP gets rid of the last remaining jailbars.
I've done all this on an early VA3 USA Genesis and it works.

All in all it's still easier to do Arcade TV's RGB bypass mod, taking care to avoid the VDP memory bus getting close to the RGB signal lines.