YPbPr transcoder too "fancy", getting confused by Sega sync, unstable picture

[BazookaBen]

I have Crescendo Systems TC1600 https://www.curtpalme.com/TC1600.shtm

It was a very high end RGB->YPbPr transcoder back in the day, I recently grabbed one.

It looks beautiful with my PS1, SNES, and CRT Emudriver PC, but I cannot get a stable picture from Sega Genesis and Master System.

I'm guessing the transcoder is too sensitive, maybe has too complex sync processing circuitry, and losing sync because of the inherent sync jitter (EDIT: actually, high impedance sync) from the consoles. Jitter is discussed here in a blog from HD Retrovision: https://www.hdretrovision.com/jitter

Anybody have any potential suggestions on ways I can work around this?

What I've tried already:

Running to an Extron RGB first. I realized the Extron RGB itself can't get a good reading of sync in the first place, it bounces between "no signal" and " 15.7kHz". So it seems like it can't do anything for me.

I've also tried removing caps and resistors from sync in the SCART head, didn't seem to make a difference

pics of board: https://imgur.com/a/KJhcqxh

[BazookaBen]

Currently talking to Gemini to see if I can create "dumb mode" mod that bypasses any advanced sync processing. Apparently one of the chips is utilizing a "phase lock loop" which is too picky for this ancient hacky console sync.

But yeah, I am not currently equipped to tell how hard I'm being hallucinated at about this potential mod.

[Guspaz]

You could try an Extron sync processor like the SC 210. Its manual specifically mentions acting as a sync stabilizer to eliminate jitter. Even if it doesn't help with your problem, it's also handy in that it can convert any type of sync input to any type of sync output (RGsB/RGBS/RGBHV/RsGsBs input, RGsB/RGBS/RGBHV/RsGsBs output). I don't remember how much I paid for mine, but I remember it was very cheap. There's also the SCS300 and SS200, which are newer devices with digital processing, but are also advertised as sync stabilizers.

Could also try HD Retrovision cables as your transcoder instead of the Crescendo device.

[BazookaBen]

Thanks I'll need to look up those Extron devices to see what they do that's unique vs. Extron RGB's with ADSP.

HD Retrovision isn't ideal, I can't really buy one cable that works with all my consoles, because of how they're wired. Not just the connectors at the end, but also the console-specific signal termination built into each cable.

And I'm not a high enough roller to buy multiple HD Retrovision cables. I'd like to keep it to one transcoder.

Absolute last resort, if external solutions or modding the transcoder itself aren't viable, I'll just look into some of the other transcoders on the market. Maybe even look at some of the DIY designs I've seen here and elsewhere

[jd213]

Hmm, I wonder if CVBS sync (or sync on luma if you have a Genesis with an encoder chip that has Y/C) instead of CSYNC would work, might be worth trying if you can easily rig up a test cable

[BazookaBen]

Hmm, I wonder if CVBS sync (or sync on luma if you have a Genesis with an encoder chip that has Y/C) instead of CSYNC would work, might be worth trying if you can easily rig up a test cable

I used to have a Panasonic TV that was sensitive to Genesis Csync jitter, and in testing I sent composite video to the component Luma input (got a grainy black and white image) and it was free of jitter.

So making an RGB cable using CVBS instead with a sync separator might be the way to go. Or even just redirect the motherboard's luma to the c-sync output, and add a LM1881 to my current cable.

There might even be a chance an LM1881 will clean the raw sync signal enough to be sync-able, though I have my doubts about that.

I'm leaning more towards modding the transcoder itself, if I can do it without accidentally killing it. I'm working up some plans with Gemini and Claude in parallel. If they converge on similar solutions, I may give it a try

[Unseen]

If I remember correctly the sync output of the Megadrive outputs a rather high-impedance signal. If the transcoder expects to be fed from a low-impedance source, the resulting level on its input may not be high enough. This could be fixed by adding a suitable non-inverting buffer on the sync line between the devices without opening either one, e.g. two gates of a 74HCT14 in series.

[vol.2]

If I remember correctly the sync output of the Megadrive outputs a rather high-impedance signal. If the transcoder expects to be fed from a low-impedance source, the resulting level on its input may not be high enough. This could be fixed by adding a suitable non-inverting buffer on the sync line between the devices without opening either one, e.g. two gates of a 74HCT14 in series.

I was thinking also something like this, but maybe use an IC that would clamp the sync signal. Maybe your suggestion would just do that anyway and it's simpler, but I know there are some sync processing ICs out there that could just take the jittery sync and output something normal at whatever level you chose, using some passive components.

[BazookaBen]

If I remember correctly the sync output of the Megadrive outputs a rather high-impedance signal. If the transcoder expects to be fed from a low-impedance source, the resulting level on its input may not be high enough. This could be fixed by adding a suitable non-inverting buffer on the sync line between the devices without opening either one, e.g. two gates of a 74HCT14 in series.

I think I have one of those types of buffer chips leftover from a project where I was making an output buffer for my Neo Geo, so I may give this a shot.

But I guess I may not understand what "high impedance" means in this case, because Genesis SCART cables come with 470hm resistor on sync. If that's needed, doesn't that mean the output at the system itself is low-impedance? I've tried connecting to the transcoder both with the 470ohm resistor present and removed.

[vol.2]

I can't answer for Unseen, but I can give you a way to measure it.

First of all, the 470 ohm resistor is probably in-line (limiter), and not a termination resistor (not to ground, not creating a voltage divider). If so, it's there to drop TTL to roughly normal video level. If your transcoder is finicky or has high input impedance, that could be the issue.

Measure the peak to peak voltage level of the sync signal to see what you are working with.

You can measure it hooked up to the transcoder and see if it's high enough, which would probably be the easiest way to get an idea.

If you want the exactly output impedance of your console, then measure both the open circuit voltage levels (peak-to-peak) and also the voltage levels with a 75ohm resistor to ground at the end.

You can then do math to calculate the console's output impedance just using a voltage divider calculation.

[Gara]

That is indeed a fancy device! I wonder if the guy who has been selling them for the last few years on ebay finally ran out. It's probably about to be much more uncommon if so. I've had the RTC2200 on my Ebay search list for years and I haven't seen a single one.

Was what the gscartsw does with sync regeneration and also the Master System sync fix for picky monitors ever replicated? It has been a good device for getting those troublesome sync sources working in my own setup.

I hope you can get it going. If not then what other RGB to YPbPr transcoder were you thinking of trying?

[BazookaBen]

If I remember correctly the sync output of the Megadrive outputs a rather high-impedance signal. If the transcoder expects to be fed from a low-impedance source, the resulting level on its input may not be high enough. This could be fixed by adding a suitable non-inverting buffer on the sync line between the devices without opening either one, e.g. two gates of a 74HCT14 in series.

This was the solution! Thanks a lot! I wired up a THS7374 buffer, passed SCART's sync through a 0.1uf cap, into pin 1, and output through a 75ohm resistor into a 220uf cap, negative towards display.

This worked for both Genesis and Master System

So I guess the best thing to do is to integrate this buffer into the TC1600 itself? I would probably need to intercept both H and V sync inputs (so this will still be compatible with PC and Dreamcast), run them through pins 1 and 2 on the buffer respectively, inject as early as possible after the VGA connector.

I'm just hoping this won't cause any issues with compatibility for the other consoles the TC1600 already works with: SNES, PC, PS1, etc

[BazookaBen]

I guess the other possible solution, instead of lightly modding the TC1600, is to lightly mod the Sega consoles like this:

https://www.youtube.com/watch?v=xKZ9-Q8SL8w

Apparently c-sync is not grabbed from the video encoder on Genesis consoles, but if change it so it is, you get a more usable sync signal?

But from what I'm reading, not all Genesis consoles have C-SYNC OUT on their decoder chips? So this would only be a solution that works for my specific consoles.

So in that sense, adding a buffer to the TC1600 would be the universal fix, as long as the buffer works well for everything beyond Sega as well

[vol.2]

This was the solution! Thanks a lot! I wired up a THS7374 buffer, passed SCART's sync through a 0.1uf cap, into pin 1, and output through a 75ohm resistor into a 220uf cap, negative towards display.

Actually the ths7374 is a video processing IC and one of the many "...sync processing ICs out there that..." can "...take the jittery sync and output something normal."

Unseen was suggesting that you use two sections of a 74HCT14 Schmitt trigger inverter back-to-back in order to clean up the signal and produce clean transitions.

I believe that the result of that solution would be a ~5Vpkpk square wave that you would still have to voltage correct for. It would just take everything from your incoming signal and threshold it so you got 4.5V high level and ~0V low level.

But idk maybe I'm totally missing something.

[BazookaBen]

This was the solution! Thanks a lot! I wired up a THS7374 buffer, passed SCART's sync through a 0.1uf cap, into pin 1, and output through a 75ohm resistor into a 220uf cap, negative towards display.

Actually the ths7374 is a video processing IC and one of the many "...sync processing ICs out there that..." can "...take the jittery sync and output something normal."

Unseen was suggesting that you use two sections of a 74HCT14 Schmitt trigger inverter back-to-back in order to clean up the signal and produce clean transitions.

I believe that the result of that solution would be a ~5Vpkpk square wave that you would still have to voltage correct for. It would just take everything from your incoming signal and threshold it so you got 4.5V high level and ~0V low level.

But idk maybe I'm totally missing something.

Oh ok thanks for the correction. I don't understand what differentiates the buffers. I don't even really understand what "buffer" means in the context of analog video other than to "make it easier to read somehow"

What's interesting is that the transcoder already has two Schmitt triggers inside of it, you can see them labled "AC14" in the picture. So I'm not sure how/if they operate differently from the one Unseen suggested

Also, I've realized the only way I can cleanly add this chip into the transcoder itself is to disconnect the H and V pins on the VGA connector itself, as the transcoder uses a multilayer PCB and the sync signals branch out in all kinds of directions basically right away. So there's no other injection point. So I may regress back to the external solution for simplicity. For now anyway

[bobrocks95]

I'd build a little dongle you can attach for problematic systems and detach for those already working fine, if you can find the right shells/connectors for that.

[vol.2]

I don't understand what differentiates the buffers. I don't even really understand what "buffer" means in the context of analog video other than to "make it easier to read somehow"

The Schmitt trigger is just a series of inverting gates that takes the incoming signal and outputs a TTL signal. It thresholds the input, meaning that it interprets all incoming waveforms above a specific level as high, and all signals below a certain level as low. It uses a power source, Vcc, to set the output level to ~+/-4.5VDC as is common for TTL signals. So you get an output that is a super clean and steady square wave that is clamped to zero volts, which is quite useful. That alone might be enough to work in your setup, as long as the in-line voltage dropping resistor did the trick.

It is an intuitive and simple solution; just a couple of gates that clean up the signal and completely eliminate any jitter at all. If they exist on the inputs to the transcoder, then it is likely that they are there to clean up incoming signals, and the output impedance of the sega console is the more likely culprit. I suspect that the method by which sega chooses to whack down the TTL output to console levels doesn't play nicely with the input stage of your transcoder, and results in the incorrect voltage level.

Like I said, you could figure it out pretty easily by scoping the sync signal while the console is hooked up to the transcoder and running. That should show you what the actual voltage levels are. You could confirm that output impedance is the problem by scoping the output of the console directly, unconnected, and then again by placing a 75 ohm resistor to ground on the output. Then you do some math using the basic voltage divider calcs:
V_loaded = V_open × 75 / (Z_source + 75), becomes Z_source = 75 × (V_open / V_loaded - 1) and you have the output impedance.


The video IC has a more complex filter that is specifically designed to condition signals for video output purposes. The one you chose is designed to take digital signals and output them as clean sync. It was a good choice IMO.

[BazookaBen]

Cool yeah that makes sense, I should look at the signals at some point to have my definitive answer. I still don't have a scope though, I'm overdue to get one at this point.

I'd build a little dongle you can attach for problematic systems and detach for those already working fine, if you can find the right shells/connectors for that.

Yeah, this is the most straightforward answer. It's just I'd have solder a line for 5V from my SCART->BNC adapter, which will be a bit unsightly.

Alternatively, I could back-feed 5v from the transcoder to VGA pin 9, with a protection circuit to avoid damaging anything that already has internal 5v outputting on pin 9, like a PC and maybe dreamcast.

[vol.2]

Yeah, this is the most straightforward answer. It's just I'd have solder a line for 5V from my SCART->BNC adapter, which will be a bit unsightly.

If it was me, I would probably try to stick the sync correction circuit inside the console. If it's outputting better, more correct sync, there's no reason not to use it always.

[BazookaBen]

Yeah, I still need to test Saturn and Dreamcast to see if this issue is only with Genesis and Master System.

And in lieu of this buffer integration, a better option might be to tap into the video encoder's C-sync output (if my models have the correct chips for that)

[Unseen]

What's interesting is that the transcoder already has two Schmitt triggers inside of it, you can see them labled "AC14" in the picture. So I'm not sure how/if they operate differently from the one Unseen suggested

But it also appears to have resistors on the two sync lines labeled 9530 (953 ohms). These are likely pull-down resistors given that almost the entire bottom of the board is a single copper pour. In the Megadrive, the sync line has a 2.2K pullup to 5V, so we have a resistive divider that would only send about 1.5V to the input of whatever chip is connected to them. Unfortunately the traces for the sync lines are obscured by the connectors, but given the position of the sync-related jumpers they will likely end up at the inputs of either the AC14 or the AC86 in the bottom right corner. They are most likely powered from a 5V rail, so the threshold to detect a high level would be much higher - the datasheet spec table mentions 3.2V at 4.5V supply voltage and 3.9V at 5.5V supply. The Megadrive never had any chance to reach that without buffering the CSync line.

If you prefer to modify the transcoder instead of buffering the Megadrive's sync, you could try to replace the two "9530" SMD resistors next to the VGA input with something in the 10K to 50K range.

[BazookaBen]

Appreciate you taking a look.

I've had a chance to test the rest of my consoles and they all work fine. Since the issue is only with the Genesis and Master System, I'm leaning towards the console-side fix. Especially since the Master System has some pretty conspicuous jailbars that will probably be fixed with something like a Triple-bypass type mod.

Thankfully the TC1600 tested fine with: SNES, Saturn, Dreamcast at both 15 and 31kHz, PS1 with clean sync from LM1881, Emudriver PC with both H+V and C-sync, and even a Neo Geo MVS buffered through a ths7374.

But it also appears to have resistors on the two sync lines labeled 9530 (953 ohms). These are likely pull-down resistors given that almost the entire bottom of the board is a single copper pour. In the Megadrive, the sync line has a 2.2K pullup to 5V, so we have a resistive divider that would only send about 1.5V to the input of whatever chip is connected to them. Unfortunately the traces for the sync lines are obscured by the connectors, but given the position of the sync-related jumpers they will likely end up at the inputs of either the AC14 or the AC86 in the bottom right corner. They are most likely powered from a 5V rail, so the threshold to detect a high level would be much higher - the datasheet spec table mentions 3.2V at 4.5V supply voltage and 3.9V at 5.5V supply. The Megadrive never had any chance to reach that without buffering the CSync line.

If you prefer to modify the transcoder instead of buffering the Megadrive's sync, you could try to replace the two "9530" SMD resistors next to the VGA input with something in the 10K to 50K range.

Just for future reference (for me or anybody else interested) those two 953 ohm resistors are indeed termination resistors

After that point, H-sync (or C-sync) goes to pin 1 of the ACT86 and pin 3 of the HC4046. V-sync goes to pin 4 of the ACT86

Or, those are the pins I got direct continuity on. I'm sure they're routed in all kinds of additional directions through the various components on board.

[kitty666cats]

You’re damn lucky having one of those Crescendo transcoders! The circuitry inside them is absolutely bonkers compared to the crap we have today from RetroTink, wakabavideo… it even blows away the Audio Authority 9A60 which was the other main popular one from the time period of your Crescendo