Video Jail Bars: Is There a Root Cause?

[+mytek]

There has been much speculation about what causes the video interference phenomenon known as 'Jail Bars'.

 

I know there has been a lot of discussion about this over the years, and various topics where it has been brought up. However I thought it might be more advantageous to have a topic that really tries to not only nail this down, but also has a title that will more likely pop up when someone is looking for a solution for it. So in my opinion and based upon observations and extensive tests, I believe I know the root cause (HINT: I don't believe it's necessarily DRAM noise or Ground Bounce).

 

As speculated by others for several years, fundamentally it all seems to boil down to some form of cross coupling of the Chroma signal into the independent Luma video output. This is either inadvertently getting past what should be an isolated internal Composite Summing circuit, or cross coupled by the video cable in use. And it can certainly be both situations combined that create the problem.

 

A little background...

The Composite video output is an intentional combining of the Luma and Chroma video signals coming down a single line. When the Composite signal enters the TV/Monitor it gets separated back into it's individual aspects (Luma, Chroma, Sync) to be used to create the image. However this separation process isn't all that perfect, and the image suffers as a result. Therefor if the TV/Monitor has what's called an S-Video input, that is the preferred video input to use, requiring the raw Luma (w/Sync) and the Chroma as inputs. In older monitors such as the Commodore 1702 these separate Luma/Chroma inputs were done with RCA jacks, however later more modern TV/Monitors had a 4-pin Mini-DIN jack designated as S-Video (or sometimes it was called an S-VHS input, since that's really where it seems to have come from).

 

Note: unfortunately the S-Video jack went away in the last several years, leaving only the Composite RCA video jack (normally a yellow color) still supported. This topic specifically focuses on using TV/Monitors or HDMI converters which still support the S-Video input.

 

So for my tests I chose the 576NUC+ because it not only has no DRAM, but none of the support circuitry and chips that deal with this either. I decided to do this because I really wanted to show that 'Jail Bars' do not depend upon the presence of the DRAM hardware in order to exist.

 

So here we go down the rabbit hole...

 

First Test: Double-Shielded Cable  (each video signal is fed through an independently shielded coax)

 

For this test I was Using B&C ComputerVisions 6 foot long A/V cable which has individual coax cables for each possible signal coming from the Atari which are all terminated to male RCA plugs. To adapt this to a Mini-Din S-Video TV/Monitor input, I used a DIY adapter similar to Hercules Workshop's S-Video to RCA adapter cable.

 

 

The color codes on the B&C A/V cable are not standardized, so for reference I had the B&C A/V cable's White RCA (Luma) and Black RCA (Chroma) going to the respective Luma/Chroma pins of the Mini-DIN plug via my DIY adapter (pin-out below).

 

 

Video Capture Double-Shielded Cable Result:  No Jail Bars

 

------------------------

 

2nd Test: Single-Shielded Cable  (A common shield is placed around the individually un-shielded Luma/Chroma wires)

 

For this test I cut the end off a 6 foot long El Cheapo S-Video cable which only had a common shield surrounding the Luma and Chroma wires. So essentially the Luma and Chroma signals were free to cross couple to each other by their proximity and the lack of a barrier (shield) between them.

 

Video Capture Single-Shielded Cable Result:  Jail Bars Present !!!

 

------------------------

 

Let's Review This

So for the test bed, I was using an 576NUC+ which was based entirely on SRAM, without any remnant of DRAM circuitry present. Yet with a video cable that had no independent shielding, thereby allowing the Luma and Chroma signals to cross couple we got easily seen jail bars. For the control, an A/V cable made by B&C ComputerVisions which utilized independently shielded cables for every signal was subsequently adapted to a Mini-DIN plug and fed into the S-Video input on my test monitor (VIZIO VA19L HDTV10T) for visual reference, and to a USB video capture dongle to get the screen images shown above. Both devices rendered a clean Jail Bar free image with the double-shielded A/V cable, although my Vizio did a better job at displaying the actual video quality coming out of the NUC.

 

The fact that there was no DRAM aspect involved, and yet Jail Bars could still be created by nothing more than an alternative video cable, pretty much rules out that all Jail Bars are the result of the DRAM switching or refresh somehow getting into the video circuits as the cause. Of course it doesn't completely rule out DRAM circuitry of being capable of creating some kind of Jail Bar effect, but it does diminish the possibility of that being the real reason.

 

My demonstration showed a definite relationship between a double-shielded vs. single shielded A/V cable to the possibility of generating Jail Bars when a poor cable choice is made. And I would say it's pretty conclusive that your best bet would be to always go for the double-shielded cable to insure that the A/V cable itself doesn't end up being the culprit. However as some people have seen, a better cable doesn't always work and Jail Bars can still be present. If that's the case, then what is more likely at fault is Atari's internal composite combiner circuit and/or its PCB layout, which is allowing for direct coupling of the Chroma into the independent Luma output. That can often be solved by installing a switch to disconnect the Chroma injection capacitor of the Composite Summing circuit when clean S-Video is desired.

 

As another control, I tested the single-shielded cable both with and without the double-shielded cable in series - it made no difference, the presence of Jail Bars was the same in either case. Since I was able to still create Jail Bars with a single-shielded A/V cable, even when put in series with the double-shielded A/V cable, I feel that also rules out any capacitive effect of coaxial cables acting as a means to dampen and/or eliminate the Jail Bars.

 

Lastly there have been reports of getting no Jail Bars even when using single-shielded A/V cables. I personally think that boils down to those cases utilizing a TV/Monitor/HDMI-Converter that has additional filtering built-in that just happens to cancel out jail bars. We can't all be that lucky

 

If anyone has something constructive to add to this subject, please do

[Mathy]

Hello Michael

 

In his articles on the SuperVideo update, Ben Poehland uses a switch to keep one of the signals from bleeding into the other.  (I never liked the idea of using a switch BTW)  It seemed to work (never tried it myself, as I said, I don't like the idea of using a switch)  That would suggest that the jail bars are created inside the Atari.

 

Sincerely

 

Mathy

 

[+mytek]

1 minute ago, Mathy said:

In his articles on the SuperVideo update, Ben Poehland uses a switch to keep one of the signals from bleeding into the other.  (I never liked the idea of using a switch BTW)  It seemed to work (never tried it myself, as I said, I don't like the idea of using a switch)  That would suggest that the jail bars are created inside the Atari.

Hi Mathy

 

Sometimes it is internal, as I alluded to in my first post. And in those cases, a different video cable doesn't seem to make a difference. However the single-shielded cable is still contributing, and will often be seen as such even when the switch solution has been put into play. So that's why I suggest going for the better video cable no matter what, and then if that doesn't fix the problem, do the less desirable internal fix.

[Mathy]

Hello Michael

 

I was hoping you'd come up with a better solution than Ben Poehlands switch.

 

Sincerely

 

Mathy

 

[+mytek]

13 minutes ago, Mathy said:

I was hoping you'd come up with a better solution than Ben Poehlands switch.

To fix it on the Atari side would not be easily done by the average user. Basically it was poorly designed by Atari, although not intentionally, since at the time only CRTs were in use which don't seem to reveal this problem.

 

Now days the fix would be to install a UAV or my UGV board. Of course better still might be one of the Sophia2 boards if you don't mind going digital, and assuming you can find one to buy.

[+bob1200xl]

I seem to be confused by what is a jailbar. The ones I have seen look different than yours. Do you get them on an 800XL if you add the CHROMA wire on the M/B?

 

Bob

 

 

 

[+mytek]

9 hours ago, bob1200xl said:

I seem to be confused by what is a jailbar. The ones I have seen look different than yours.

Hi Bob

 

Jail Bars as the name infers look like vertical evenly spaced bars of a different shade than the background. Not to say that there aren't other versions, perhaps with a different amount of space between them. Do you have an example you can share of what you were thinking they were?

 

Here's some other examples from non-Atari systems which look pretty much the same as what I see with a single-shielded A/V cable on the Atari...

 

Genesis Model 1's S-Video (click image to expand)

 

Neo Geo AES

 

 

9 hours ago, bob1200xl said:

Do you get them on an 800XL if you add the CHROMA wire on the M/B?

I would imagine so since Jail Bars can manifest on any Atari, especially if the source of the problem is the video cable. Ironically the best cable to use prior to the custom ones with a Mini-DIN plug, were the old original ones with the RCA plugs that B&C or Best Electronics carried, since they utilized individual coaxial cables for each signal, usually bonded together to form a semi flat cable (also available from Amazon and eBay). If your monitor needs the Mini-Din plug for S-Video there are adapters for that as well (Hosa VSF-454 - available from eBay).

 

EDIT: Be wary of the custom Atari to S-Video cables being sold now days. many of them use a single common shield. The only ones I know for sure that use individual shields for each signal are made by Hercules Workshop.

 

Here's a post I made about the 8-Bit Classics Atari to S-Video cable not being as good as everyone thought, including me at the time...

 

When it's not a cable issue, then it's time to look internally to see if disconnecting the Chroma injection capacitor on the Composite Summing circuit will fix the problem.

 

[Mazzspeed]

I made my own separately shielded chroma/luma cables for both my A8 and Commodore machines and I get no jailbars whatsoever. In fact the resulting PQ from my 600XL was fantastic after modding the video output for separate chroma/luma based on FJC's instructions. I now run a Sophia 2, but if I couldn't have got a Sophia 2 for any reason (as is the case now I believe) I would have remained perfectly happy with my separately shielded svideo output.

[TGB1718]

3 hours ago, Mazzspeed said:

I made my own separately shielded chroma/luma cables for both my A8 and Commodore machines and I get no jailbars whatsoever.

Same here, I made sure the cable I re-purposed had individual shields, no jailbars on 800/800XL/130XE

[+x=usr(1536)]

Not to discount other possibilities, but the following video has an interesting analysis of the circuit-level issues affecting XE machines' video output.  It seems reasonable to assume that the same may apply elsewhere.

 

 

FWIW, I do agree with his general assessment that CRTs mask issues that appear on LCDs: my 1200XL with a UAV looks great over composite on the CRT TV, but as soon as I move it over to composite on an LCD TV the jail bars are apparent.  They're faint, but they are there.  My suspicion is that striking a decent balance between picture quality and increasingly diminishing returns on hardware modifications needs to be approached from both the cable and system modification sides.

[reifsnyderb]

26 minutes ago, x=usr(1536) said:

Not to discount other possibilities, but the following video has an interesting analysis of the circuit-level issues affecting XE machines' video output.  It seems reasonable to assume that the same may apply elsewhere.

 

 

This is quite interesting.  I've seen interference on an S-Video modded 800XL that is similar to what fix did with the ground wire.  However, there is no close link between the 4050 ground and the VLSI chips.  But it does give us more information to consider.

[+mytek]

And when the cable alone doesn't do the trick on your 800XL, here's the internal switch connection that @Mathy mentioned written by Ben Poehland in his SuperVideo update.

 

"The 8-bit Alchemist", Atari Classics Vol. 2 No. 6 December 1993 article

 

See how the added switch disconnects what was intended to only be a Luminance feed for the Composite Summing circuit, but unfortunately it also back-fed Chrominance into the Luminance output, which creates the Jail Bar effect.

 

As I mentioned earlier, doing the 'CV Disable Switch' mod will have no effect if your video cable is also contributing to the Jail Bar effect due to poor shielding.

 

1 hour ago, x=usr(1536) said:

Not to discount other possibilities, but the following video has an interesting analysis of the circuit-level issues affecting XE machines' video output.  It seems reasonable to assume that the same may apply elsewhere.

Nice video, thanks for posting it. Notice that the Jail Bars that were being seen on that 130XE appeared to be much wider spaced then what I was getting with a single-shielded A/V cable. So I would say a good rule of thumb to use for determining the source of Jail Bars would be as follows...

 

Closely Spaced Bars = Chroma bleeding into the Luminance output signal (2 possible causes: either minimal shielding on the A/V cable -or- back feeding of the Chroma via the Composite Summing circuit)

 

Widely Spaced Bars = Ground Bounce due to poor decoupling of CD4050 ground from digital switching chips (solution would be to try to create a better ground path from the CD4050 towards the ground plane by the DIN output jack - I suggest watching that video posted by @x=usr(1536) to see what I mean)

 

 

[BillC]

2 hours ago, x=usr(1536) said:

FWIW, I do agree with his general assessment that CRTs mask issues that appear on LCDs: my 1200XL with a UAV looks great over composite on the CRT TV, but as soon as I move it over to composite on an LCD TV the jail bars are apparent.  They're faint, but they are there.

The UAV uses an NCS2563 3 channel video amplifier, which requires an external connection between chroma/luma to create composite. The older FMS6400 chip has inputs for chroma/luma and outputs for chroma/luma/composite, the composite signal is generated internally while keeping the chroma/luma signals isolated from each other.

[+mytek]

5 minutes ago, BillC said:

The older FMS6400 chip has inputs for chroma/luma and outputs for chroma/luma/composite, the composite signal is generated internally while keeping the chroma/luma signals isolated from each other.

Yeah that's what I love about it. With that full isolation there's really no chance of the Composite Summing causing problems with the S-Video. It's a nice chip, although obsolete and no longer made (just like our A8s). However there is a newer version, but unfortunately it's locked into a 6 db gain which is undesirable for our application.

[+-^CrossBow^-]

In the case of my 130xe is has to be something in the XE causing mine. I've tried two sets of cables to help rid my jail bars as they are the more thinner vertical bars. I have a set of the Herc cables on it and they are still present. I have a UAV installed and removed the original outputs from the atari circuit and wired the UAV outputs to the AV din port instead to further try and remove them. No dice, but an 800xl that I did the same way, looked great! So at least in the case of the 800xl vs a 130xe that I've seen in person and worked on, the issue was something in the 130xe. What, exactly I couldn't say and I've just learned to live with it at this point. I should note that I only see them really when using s-video through my av setup in the game room. Composite I don't see them.

 

[+mytek]

On 8/19/2022 at 1:29 PM, -^CrossBow^- said:

In the case of my 130xe is has to be something in the XE causing mine. I've tried two sets of cables to help rid my jail bars as they are the more thinner vertical bars. I have a set of the Herc cables on it and they are still present. I have a UAV installed and removed the original outputs from the atari circuit and wired the UAV outputs to the AV din port instead to further try and remove them. No dice, but an 800xl that I did the same way, looked great! So at least in the case of the 800xl vs a 130xe that I've seen in person and worked on, the issue was something in the 130xe. What, exactly I couldn't say and I've just learned to live with it at this point. I should note that I only see them really when using s-video through my av setup in the game room. Composite I don't see them.

Composite is rarely ever a problem since Luma and Chroma need to be combined to create the Composite video output. The Composite input on the TV/Monitor is designed with that in mind.

 

I was looking at Sobola's 130XE schematics and see that the RF Modulator is where the Composite output is created in that machine. This is also the same modulator that a 65XE uses as well.

 

 

Even though they have buffer transistor circuits (emitter follower configuration) on both the Luma and the Chroma before doing the summing for Composite creation, there is always the possibility that the Chroma might still back feed into the Luma and cause the Jail Bars.

 

However that should only affect the stock video signals. A UAV should bypass all that.

 

I guess just for grins, you could disconnect pin 2 of the Modulator from the Motherboard to see if that changes anything (disconnecting pin 3 should work as well).

[Ricky Spanish]

Atari 8-bit at 59.94 Hz matches very well with more modern CRT's 60-80 Hz refresh rates. Even hooked up my N64 to the CRT and it's a much better picture than the LED/LCD. I think PLASMA would also work out well. I need to the give the 1200XL a try on my 50" plasma. 

[+x=usr(1536)]

15 hours ago, mytek said:

Composite is rarely ever a problem since Luma and Chroma need to be combined to create the Composite video output.

Understood.  So, thinking out loud: would it be feasible to feed LUMx, sync, and chroma directly from the GTIA to a UAV since those pins on the GTIA are all outputs?  This would be done by disconnecting pins 21-25 and 31 on the GTIA from the system and jumpering them directly to the UAV - sort of along the lines of what happens to a PIA in a machine with a RAM expansion.

 

If the video signals can be removed from traversing the PCB entirely, the effects of other potential points of signal degradation, interference, or processing may be reduced.  +5V and GND would still have to be taken from somewhere on the system's PCB, but, If I'm reading the UAV manual correctly, this should be possible...  I think.

 

Granted, that would completely remove the possibility of running the RF modulator alongside the UAV, but that seems to be what most people do anyway.  It would allow for the 4050 to act solely as a power supply for the UAV, however.

[reifsnyderb]

9 hours ago, x=usr(1536) said:

Not to discount other possibilities, but the following video has an interesting analysis of the circuit-level issues affecting XE machines' video output.  It seems reasonable to assume that the same may apply elsewhere.

 

 

FWIW, I do agree with his general assessment that CRTs mask issues that appear on LCDs: my 1200XL with a UAV looks great over composite on the CRT TV, but as soon as I move it over to composite on an LCD TV the jail bars are apparent.  They're faint, but they are there.  My suspicion is that striking a decent balance between picture quality and increasingly diminishing returns on hardware modifications needs to be approached from both the cable and system modification sides.

 

I was thinking more about this video and looking at the 800XL GTIA chip.  While 4050 ground isn't close to the VLSI chips, there is a +5vdc line that comes up from the GTIA chip and feeds the pull-up resistors going to the 4050.  (R45 - R45)  I am thinking that this could be a source of interference.  Looking at the board layout, prior to reaching the pull-up resistors for the 4050, +5vdc first goes past the decoupling capacitor for the GTIA chip then supplies power to the GTIA chip.  It stands to reason that any ripple on the supply line going to the 4050 pull-up resistors would show up on the screen. 

 

 

 

Edited August 19, 2022 by reifsnyderb

[Jason Young]

Lots has already been said in the comments above, so apologies if this has already been touched on.  But what I found interesting is the difference between the XL series and the XE.  Here is the setup:

2 XL machines - 800XL with UAV installed and 1200XL with UAV installed,

2 XE machines - 130XE with UAV installed and 65XE with UAV installed

Video cable:  Hercules Workshop double-shielded output to S-Video, then plugs into RetroTink 2X Pro, then goes into HDMI on either LCD TV or Dell Monitor

 

So, same video cable, same monitor, UAV in all four machines.

When I use the XE machines on either TV or monitor, no jail bars, picture is 100% perfect.

When I use the XL machines on either TV or monitor, faint jail bars.  They certainly aren't as bad as I've seen in non-UAV machines, but they are still present.

 

What is it about the XL machines that would cause jail bars with all other things being equal?

 

[Mrshoujo]

I'm still perplexed why this is perceived as a problem. I like the "jailbait" look and don't mind it. It gives the video output a distinctive computeristic look. As long as it's not too prominent, I'm okay with however it looks.

[+x=usr(1536)]

1 hour ago, Mrshoujo said:

I'm still perplexed why this is perceived as a problem. I like the "jailbait" look and don't mind it. It gives the video output a distinctive computeristic look. As long as it's not too prominent, I'm okay with however it looks.

Thinking of it as symptomatic of poor design choices on Atari's behalf rather than as an actual problem may be a bit closer to how it's perceived.

 

Granted, jailbars don't really interfere with the system's operation - but figuring out how to improve upon what's already there carries on the tradition of looking at something and saying, "hmm, I could make that work better."

[+x=usr(1536)]

20 hours ago, mytek said:

Yeah that's what I love about it. With that full isolation there's really no chance of the Composite Summing causing problems with the S-Video. It's a nice chip, although obsolete and no longer made (just like our A8s). However there is a newer version, but unfortunately it's locked into a 6 db gain which is undesirable for our application.

Just noticed something while looking at the NCS2563 datasheet: it apparently also has a 6dB fixed internal gain, so it appears to already be a characteristic of how the UAV processes signals.  Meanwhile, the FMS6400 claims to have selectable 0dB or 6dB gain on pin 2.

 

Not really going anywhere specific with this; just tossing it out there.

[+mytek]

1 hour ago, x=usr(1536) said:

Just noticed something while looking at the NCS2563 datasheet: it apparently also has a 6dB fixed internal gain, so it appears to already be a characteristic of how the UAV processes signals.  Meanwhile, the FMS6400 claims to have selectable 0dB or 6dB gain on pin 2.

 

Not really going anywhere specific with this; just tossing it out there.

There's a lot of digital noise flying around the GTIA which is also where the 576NUC+ and the new UGV board's video processing circuits reside (smack dab underneath to be specific). Whereas the UAV is a bit removed from this, being off to the side. Anyway because of that proximity to GTIA it required A) using as little gain as necessary to get the job done, and B) the use of a very low impedance resistor DAC circuit. So that's what made the FMS6400's ability to down shift to 0 db gain a plus for what I was doing. There was also a side benefit of the low impedance DAC that allowed for direct injection of the analog signal into the FMS6400's inputs, thereby eliminating the usual emitter follower transistor buffer circuits like what the Atari uses (and I suspect the UAV as well), thus simplifying the overall design.

 

Even though the FMS6400 is obsolete, it's still readily available as NOS from eBay and AliExpress, and at a very reasonable cost. Unlike the FPGAs, CPLDs, and Micros, it hasn't suffered at all from the chip shortages.

[+mytek]

15 hours ago, Jason Young said:

Lots has already been said in the comments above, so apologies if this has already been touched on.  But what I found interesting is the difference between the XL series and the XE.  Here is the setup:

2 XL machines - 800XL with UAV installed and 1200XL with UAV installed,

2 XE machines - 130XE with UAV installed and 65XE with UAV installed

Video cable:  Hercules Workshop double-shielded output to S-Video, then plugs into RetroTink 2X Pro, then goes into HDMI on either LCD TV or Dell Monitor

 

So, same video cable, same monitor, UAV in all four machines.

When I use the XE machines on either TV or monitor, no jail bars, picture is 100% perfect.

When I use the XL machines on either TV or monitor, faint jail bars.  They certainly aren't as bad as I've seen in non-UAV machines, but they are still present.

 

What is it about the XL machines that would cause jail bars with all other things being equal?

 

Good question. Personally I haven't seen a problem with jail bars on my 600XL that also has a UAV installed, and I'm running its video out the stock A/V DIN jack. Since the 600XL is very similar to the 800XL, aside from the type of DRAM in play I'm not sure what to tell you is causing your jail bar problem. In fact this machine has the cleanest bar-free video out of all the systems I have.

 

For more info on all the stuff I got packed into this machine, check out: https://ataribits.weebly.com/blog/category/monster-600xl