shmups.system11.org

For some time now behind the scenes I've been researching the jailbar issue that seems to affect Core Grafx and Core Grafx 2 consoles when RGB modded. I don't like to offer mods in my store unless I'm really happy with them and while the RGB mod is fantastic on the Supergrafx and (I'm assuming) other PC Engines, we can't seem to shake these jailbars entirely on the CoreGrafx machines.

So here's exhibit one, PC engine with 4 caps replaced - C121,C131,C132,C135

bas-pc-engine by videogameperfection, on Flickr

Honestly it's not bad.. but you can definitely still see the jailbar effect. Next up we tried completely re-capping a machine

matt-pc-engine by videogameperfection, on Flickr

Recapping did seem to have an effect but again can't seem to get rid of the jailbars entirely.

We also tried electrolytic rather than ceramic capacitors for the jailbar fix, theoretically electrolytics do a better job at AC decoupling (I'm just repeating what I've been told here) but in practise it didn't seem to make much difference. We're also always testing using a linear power supply.

Anyway, since it's always worth throwing this out to the community, that's where we're at. At the moment we can't get rid of the jailbars on these Core Grafx machines entirely and we've tried multiple consoles.

I assume this is with proper 9MHz video LPF like on the OSSC, right?

I'm not familiar with the layout of the Core Grafx consoles, but one thing I'd check for is to see how the subcarrier for the composite video is routed. Sometimes removing that source does the trick. Other times is it's because the RGB lines run too close to a crystal clock or some other coupling issue, and lastly, it can be encoder itself (though I assume you are bypassing the encoder in an RGB mod).

Edit: Also I assumed you tried upgrading C121 and C135 with 4.7uf?

The bypass board needs its own power supply to be rid of jailbars it seems.
Depending on where you grab 5v from the jailbars can get really bad.

Yep that's through my OSSC.



Yeah he says he's checked for most of that. I'm actually tempted to cut composite video altogether see if that makes a difference.



Yes that's been tried.



Interesting, I'll pass that along.

Changing the input output caps from 47uf to 220uf seemed to make a difference too. "Seemed..."

Still chasing my tail.

I spoke about this a long time ago on TheRetroRoundtable.

CVBS on the PC-E is generated kinda outside of the silicon, but it looks really nice.

The color-carrier and chrominance data are interleaved between pins 26 and 35.




I don't have a CoreGrafx, so I can't do a proper analysis. But get out your scope and look for AC noise and capacitance coupling between these signal outputs, and composite video on the routing. By nature of the expansion connector, composite video is routed adjacent to the analog RGB output.

Otherwise, just lift both of those pins that I marked on the HU6260 and monitor. Is there a change? If so, there you go.

Hello,

Tim Worthington suggested that changing caps C133 and C135 should fix the issue in Core II systems. I haven’t had a chance to do this yet, but I thought I’d share. A markup supplied by Tim is included below.

D

Curious to hear if this fixes the issue.

I decided to install Voultar’s RGB into my Core Grafx 2. The board is great, but there are definitely issues with jailbars. I tried the following:

1. Replacing C131 and C135 per Tim’s direction

2. Replacing C121 and C135 per the info from Console5’s Wiki

3. Lifting the pins Voultar specified in his post

Unfortunately none of the above significantly reduced the jailbars.

If anyone has any additional idea, please let us know.

Thanks

Just throwing in my two cents here now that I have a CoreGrafx. I opted for the board sold by Console5 since it is cheaper and I wanted to keep composite video intact just in case I want to use it one day. I am using a packapunch sync on composite cable from Retro Gaming Cables, so that ought to keep the composite signal isolated from the other lines to keep out interference. However, I'm still getting jailbars. The signal is otherwise very sharp and free of static or other interference, so it's a step up from the AV Driver install I had in my TG16. Still, would be nice to be rid of the jailbars. I have replaced C121 and C135 per the Console5 recommendations. I've tried to route my wiring such that it is away from any potential sources of interference, though my efforts to make the 5v wire look neat might be thwarting that. I'm pulling RGB directly off the 6260, analog 5v power from pin 21 of 6280, and analog ground (as far as I can tell) off the empty pad/via directly above the RGB board in the picture. Haven't tried a recap, but they seem to be in good condition, so I'm not sure how helpful that would be. Any ideas?


Edit: I've found this thread from the way back that also mentions better grounding for the 8-pin DIN port, but naturally the image for that fix is the only one with a broken link. Anyone know more about that? I think leonk is still around here somewhere, it was their post so maybe they can chime in.

BuckoA51,

Check R, G, and B separately. For example connect each one to a the monitor's green input in turn.

If it's coming from capacitive coupling to the RGB traces it will be worse on one colour than another. If it's the same on all it's most likely power related.

If it is from capacitive coupling, would the solution be to lift those pins? I might give that a go tonight just to see what happens, but I'd rather not be lifting and resoldering pins multiple times if it's not likely to fix much. Can't think of any reason I'd need RGB to go to the extension jack if I'm doing an RGB mod (and since I am specifically not modding my IFU for RGB, instead taking it from the CoreGrafx), so that would be a pretty easy fix.

No offense, but you're running analog video right next to a high-speed oscillator that everything references for clock on that board. That's bad.

This video is from several years ago, but the point/lesson remains:

https://www.youtube.com/watch?v=ayNvNvnA6Rk

Ah, that makes sense. I did wonder about that. I will route the wires in between the chips and see if that helps. I also tested grabbing the 5v supply direct from the regulator and also not running it under the pins, but neither made any difference.

It is now running between the chips and then over. It's a definite improvement, enough that I can live with it, though still not "perfect." Ah well, thanks for the advice. One day perhaps there will be more to try.

Edit: not sure if this was here or elsewhere, but someone had asked if there is any harm in replacing all of the decoupling capacitors with the better, higher capacitance ones instead of just two? Are there better places to be tapping power and ground from?

Sorry to keep posting... but I did some more investigating and found an even better solution. It seems like a lot of the noise comes from the general area of the 6270, so I've changed my setup so that none of the wires pass anywhere near there. It's not 100% perfect, but it's close enough that it looks noise free from anywhere but right up on the TV at a weird angle that exaggerates the contrast. Basically, I am now grabbing signal from the extension port pins instead. Here's a view from the top: https://photos.app.goo.gl/cCvrC5zoMC7EoTLx9. And here is a view from underneath: https://photos.app.goo.gl/aRGqVtHpBuutRjsa6. This puts a shield between the video wires and circuit board, so I figure that should help keep the noise down. 5v is taken from the little via behind the board, which you will need to scrape a bit to get at the copper, and ground is taken from the top of the extension port as you can see. It's possible that engaging the LPF on the bypass board may get rid of the last bit of noise (at the expense of decreased sharpness since I'm also using the LPF on the OSSC), but it would be a pain to enable on this board, so I don't think I will bother. Hopefully this helps.

Your analog video wires need to avoid the bus traces as well. Memory line traffic has a lot of power to couple into weak analog video.
That's why you saw a big influence from the 6270 area.

If you hold an oscilloscope probe just near those traces, you'll see the noise as it easily couples to it.
Shielding can help but it's not always trivial to do (example: Mega Drives).

Thanks for the pics, TBC! I'm going to give this approach a try, for internal mod.

I had a similar experience with excessive jailbars on my Core Grafx 2. This was due in part to the wires I ran across the board in front of the 6260 and 6270. If I pressed the wires onto the board in front of the 6260 the jailbars would intensify significantly.

I was able to move the RGB board under the ribbon cable, which solved my issue. The board fit well surprisingly. I pulled R, G, B, and sync from the vias under the wires on the left side of the image. Please see below and excuse the messy soldering/modwork – I'm usually better than this, but I was working fast.



I tested for the jailbars using my BVM-D32 which is very unforgiving. I do plan to test this with an OSSC and HDTV to see if the problem still persists.

Does this also happen on the original white PC Engine?

It happens with all of the PCE family to some extent. On the TG16, no matter where I put the mod board (an AV Driver in that case) or where I tapped signal from, the noise was worse than it is now on my CoreGrafx. But I've seen others say that the white PCE has been less noisy than the CoreGrafx and that the CoreGrafx is one of the worst offenders. IMO, for systems with RF output (TG16 and white PCE), I'd just go with an external solution like the dB Grafx Booster. This moves the RGB circuit outside the console, so it's less likely to pick up interference. If you end up getting an SSDS3 or an IFU later, you can mod those for RGB (or fixed RGB in the case of SSDS3) instead. But this is based solely on my experience with my own TG16, so take that with a grain of salt.

I don't have a PC Engine but am now very interested to get one since the Super SD System 3 was launched. That fits externally so hopefully circumvents these issues as you say, and has RGB out (plus all the other cool stuff it does). I'm waiting to see if it has few revisions, and goes down in price a bit!

Hello,

I had a chance to test the Core Grafx 2 with the OSSC and unfortunately the jail bars were still visible, please see the image below:



This issue wasn't noticeable on the BVM that I have, but I can't leave well enough alone. I decided to redo the mod and change things up a bit. I did the following:

• Re-positioned the RGB Board to be closer to the video chip.

• Used thicker cable for the RGBS, 5v, and ground - I had used kynar previously.

• Tried to keep the cable runs as short as possible.

• Used shielded cable for the (longer) RGBS output run.

• I put a layer of copper tape under the RGB Board - it’s been insulated with multiple layers of electrical tape to avoid shorts! I’m not sure if this was crazy or not but I wanted to try everything.

• I made a point to avoid touching the PCB with any of the wires.

Here is a picture of that install:



All of this made the difference and now the Grafx 2 is free from jail bars even when played through an OSSC on an HDTV:

How are you grounding those shielded wires? I'm not seeing where the shields are connected. Did you also connect the copper tape to ground? If I recall, Voultar's board has a nice ground plane, so I'm not sure how much that tape is actually doing. Still, glad it's working for you.

They aren't. They are like a normal wire, wrapped with a layer of wire mesh. If you take a close look at the picture you'll see the main wire is white and the insulated part is gray.


No.



I'm sure you're right. I just wanted to do anything and everything with this install to ensure it worked. I have limited time for this stuff and it was do or die this time! It could very well just be the thicker wires instead of kynar and positioning of the RGB board.



Me too! This has taken way longer than I originally expected! It'd be nice if the SSD3's RGB output was as good.

So I think now that the jailbars are at a level that most people would consider acceptable (yes yes I know I'm supposed to be where people go for "perfection" but we've already sunk hours into this)

Placement of the board really does affect the Jailbars, there's so little room in these cute little consoles. Here's where we put the board on the most recent install:-

pce-new-position by videogameperfection, on Flickr

I say we, it's all down to my subcontractor, who wants to stay anonymous as he hates internet drama lol. Anyway this resulted in a grey ramp as shown here:-

jailbars-better by videogameperfection, on Flickr

(click through to see it in bigger, obviously)

Much better, there's definitely still a trace of jailbars and also some sparkle interference if you really look for it, but heck a decade ago if someone showed me a PC Engine with this good a picture I'd have been picking my jaw up from the floor.

As for any further improvement I don't know. We did find a couple niggles with the Voultar board in research.. it has some impedance mismatches on the outputs and the sync voltage seems a little high, but I doubt it's enough to make a difference.

So what research have you done, exactly? You can't really say something like that and not offer data to substantiate. Do you have data to offer?

Impedence mismatch.. So did you actually calculate the thevinin/source impedance on the outputs? There's a nominal, few ohms discrepancy. Not enough to create any sort of reflection issues on the transmission lines (cable). This is the price you pay for attenuating the output-side.

As for the sync voltage being a little high? What does that mean, exactly? Based on what? The c-sync amplitude is perfectly, 100% in spec for ALL SCART appliances. Anything between 210mV and 950mV is perfectly within specification.

All of these transmission signals absolutely meet and adhere to the BT.601 spec.


There's always going to be subtle discrepancies. This is analog video, and the DAC's in these old VDP's, PPU's PC-E's, etc. have a variably mild output swing. We do what we can and often have to do some very precise averaging.

I'm with Voultar on this one. It took me a long time to grasp the concept of 'SCART' tolerance swing on csync, but the only way csync would be 'a little high' is if you scoped it at 1.2V or something like that. What actually did you measure on a scope?

Yeah I mean don't get me wrong I think the amp is great and we've had jailbar free results in other PC Engine consoles, so can't see that any part of this problem is due to the amp, just reporting some things my guy noticed.