Removing RGB jail bars idea?

[TmEE]

not sync but video. RGB cables are supposed to use Cvideo for sync, as it will work with all TVs. But people tend to get better results with Csync, but that will cause black screen on shittier TVs. This is why Dreamcast manual says that some TVs may not show image with RGB cable, DC uses Csync not Cvideo for RGB (because Cvideo does not work in RGB mode)

[TrekkiesUnite118]

Does the 32X use the Genesis CVideo or CSync signals? If it does that could explain why you get Jailbars with RGB on the 32X but not when you use S-Video.

[lumclaw]

You are bypassing it for Composite and S-Video. And if your Genesis has a CXA1645 (Like many late Model 2s) you will see no improvement at all from using the 32X as that's the same encoder the 32X uses.

That doesn't seem right. Your suggestion implies 32X is able to communicate with the Genesis, telling it not to amp RGB using its encoder.

[TrekkiesUnite118]

What I was getting at is if the Genesis uses CVideo for sync and that is the actual source of the jail bars, wouldn't having the RGB encoded on the 32X possibly eliminate the jailbars as it's a different encoder creating the CVideo signal now?

I'm not saying the 32X is telling the Genesis not to amp it's RGB, I'm saying that it could be a case where for Genesis games the 32X is simply passing through the Genesis RGB and Sync signal for RGB output but re-encoding the signal for Composite and S-Video using it's own encoder. Which if the Composite signal is truly the source of jailbars that could explain why you still have them for RGB on the 32X but you don't have them for Composite and S-Video.

[lumclaw]

I think it's more plausible composite and s-video smooth over the jailbars in a similar fashion CRTs do.

If jailbars are generated in the Genesis VDP, fixing that bug in 32X's VDP would've make 32X games look too bizarre over RGB. That is... Having jailbars only in the Genesis-created portions of the video output. Which we know didn't happen.

[TrekkiesUnite118]

According to what TmEE posted the jailbars come from the Composite Video Signal used for sync, not the VDP.

And do 32X games have Jailbars in RGB? Or just Genesis games?

[TmEE]

32X uses Csync on the RGB input, it cannot extract sync from Cvideo. Half the sync comes form cartridge slot H and Vsycn signals, those are used on image generation, the Csycn from MD Av out is used for image over/underlay.

[TrekkiesUnite118]

Does the 32X work in the same way when it's playing a Genesis game?

[Lastcallhall]

You guys might want to check out this thread:

http://www.assemblergames.com/forums...-1-CXA1645-mod

It's semi relevant, and it's a good read on the subject nonetheless.

Interestingly, it seems that the jailbars are coming from pin 6 of the CXA1145 which is the x'tal in. Since this issue is more prevalent on VA2/VA3/VA4(possibly - I've never tested one) system boards, it seems like the encoder is too close to the oscillator that's causing the issue. If you look at a VA5 and VA6 CXA1145, the chip is flipped 180 degrees from it's position on the older boards, and - surprise - has far less distortion than it's older siblings...

Something to think about.

[TmEE]

This what I have been telling that jailbars come from Colorburst.

@Trekkies: Always same way

[Drakon]

Yeah I tried a cap from luma to ground ages ago but it didn't work, it's really odd. It works in the rgb nes.

I'm going to attach an encoder circuit to my genesis and run it off of a crystal oscillator and see if the jailbars disappear...

[TmEE]

Except that I have yet to see those lines on any RGB line, on scope or my TVs.
I could perhaps suspect VRAM interference on MD1 but that would mean the lines aren't uniform.

[Lastcallhall]

The jailbars come from the vdp I can bypass the built in encoder and still get jailbars. Remember even the genesis 3 has the jailbars it's a completely different pcb layout, same with the genesis 2. Just because some rgb tvs don't show the jailbars doesn't mean that they're not there.

Damn, Well there goes my theory of tapping straight off the VDP.

I read that ENTIRE assemblergames thread a long time ago. Basically it ends up being some guy laughing and pointing out that the jailbars are a flaw with the vdps sega was using and that the problem comes right from the vdp chip.

I'm going to attach an encoder circuit to my genesis and run it off of a crystal oscillator and see if the jailbars disappear...

I just did that routing the RGB out into a 1645 circuit (same as the dozens I've done before) last weekend, actually. There's no jail bar issue, but the colors.. shimmer, I guess is the best way to put it. Additionally, the color values are way screwy. I wish I had taken pictures. I'll look and see if I still have the encoder hooked up when I get home and post pics if I can.

[TrekkiesUnite118]

Didn't they try tapping directly from the raw RGB lines in the first page of that assemblergames thread? From what I saw in that there weren't any jailbars, the picture just wasn't amped correctly.

[lumclaw]

flaw with the vdps sega was using and that the problem comes right from the vdp chip.

In that case we've got a LONG way to go. To find out how far into the greater vdp family they went, and when the issue first appeared. We could be looking at things like even Pico having jailbars.

There's been various upgrades/extensions over time. More primitive relatives found in systems like SG-1000 didn't have real rgb. So who knows about those. Mark III was where sega added rgb.