THS7374 vs THS7314 + 1 chip brightness fixing

[Voultar]

The C-Sync output pin is an open collector. If you're pulling C-Sync directly from the 1CHIP you're going to potentially be sinking a lot of current from that pin, which might not be great.

My SNES RGB board drops the TTL voltage output down while current limiting making it 75 ohm "friendly".

The S-RGB encoder also has slightly higher amplification than the 2V/V 6dB 73XX drivers. That also needs to be taken into account.

These values drift from console to console slightly, so it's best to find the an optimal middle ground.

[SmokeMonster]

I currently have THS7314 based RGB amps in many of my consoles. Would there be a benefit in swapping out their 7314 for 7316? They're cheap and pin-compatible, so it would be a simple little upgrade.

@retrorgb: Were you ever able to directly compare THS7314 to 7316?

[mickcris]

I currently have THS7314 based RGB amps in many of my consoles. Would there be a benefit in swapping out their 7314 for 7316? They're cheap and pin-compatible, so it would be a simple little upgrade.

@retrorgb: Were you ever able to directly compare THS7314 to 7316?

I tried one out and couldn't tell any difference. I am not good at taking screen shots so have no photos.

[RGB0b]

@retrorgb: Were you ever able to directly compare THS7314 to 7316?

No, not yet

I tried one out and couldn't tell any difference. I am not good at taking screen shots so have no photos.

But you can confirm they're definitely pin-compatible and people can just swap them out if necessary, right?

[mickcris]

@retrorgb: Were you ever able to directly compare THS7314 to 7316?

No, not yet

I tried one out and couldn't tell any difference. I am not good at taking screen shots so have no photos.

But you can confirm they're definitely pin-compatible and people can just swap them out if necessary, right?

Yeah. They are.

[RGB0b]

Awesome, thanks. I finally got around to ordering some. They should arrive by the end of the week.

[zeruel85]

I carefully read all the discussion and now I have a big question for the experts.

Assuming that we use a THS7374 in bypass mode (so LPF is disabled) on a SNES 1Chip (or also other consoles, it's not relevant)... Than I connect the SNES to my gscartsw (which has a built-in THS7374 with LPF enabled, AFAIK)... Than I connect the gscartsw to my OSSC (which has a THS7353 and Video LPF set to 'Auto' mode)...

The question is simple: do I really care if LPF on SNES is bypassed or not? I mean... The signals pass through a variety of video amps, and not all of them can bypass the LPF (such as the gscartsw, for example).

I can set OSSC Video LPF in 'Off' mode, but as far as I can tell, it's not relevant if the gscartsw LPF is not bypassed, right?

What's your opinion? Is 'ICs cascade' a real problem or just my imagination?

[borti4938]

A concatenation of filters corresponds to a multiplication of the transfer function or correspondingly a convolution of the impulse responses of these filters. In simple words, this means:

• The order of the filters is not important!
• We just have LPFs, i.e., the overall filter is also a LPF which cut-off frequency is at the minimum cut-off of all three filters.
• Phase shifts of each frequency component are summed up!

Hence, it doesn't matter whether you have switched on the filter of the THS7374 inside the SNES or not if you just look for the attenuation. If you look for the phase shift, which is more crucial, you should observe a minor difference at sharp edges!

[zeruel85]

So, from what I understand, it's better if we can deactivate all the LPFs in the chain, for a better sharpness.

What about the N64RGB? I see that it has a jumper for bypass mode, but you talked about the R2R ladder and the reconstruction of the filter behind it.

Has anybody of you ever tried to make a comparison on N64RGB, with J4 close/open?

[borti4938]

I do have a design where I can select filter mode / bypass mode with one controller input combination. But I cannot see any differences on my setups.

[vol.2]

Borti, What are you using to reinforce cspun pin 155? I was thing of using silicone to reinforce the joint because I am worried about the weight of the resistor on the pin. I use silicone for other fiddly connections, so it seem like a good idea. Maybe epoxy?

If anyone has an actual photo of the finished product, that would be cool to see. Mostly for the orientation of the resistor.

[borti4938]

I do nothing at all...

I have bent one end of the resistor lead under the resistor and shortend the other end as short as possible. Finally it suits very well and gives a very stable construction.

[vol.2]

Thanks Borti!

I think that looks pretty stable. It's a little hard to make out the pin side, but I'm assuming that the pin is just connected directly to the shortened end of the resistor. I suppose that leaving it unglued will allow for a fix if something goes wrong.

[copy]

These instructions are NOT finished (and not "public"), as I made a few mistakes, but they'll show you everything you need: http://www.retrorgb.com/snes1chip7374.html

Also, I only had one 1CHIP to test at the moment. I need to double check that the only components required to remove csync to the multi-out are C46 and R9. I should be able to test again really soon (and update those pictures), but if anyone else already has one open and wouldn't mind checking, I'd really appreciate it. My only concern is there there are a bunch of csync components missing on the 1CHIP-03's and while I'm sure you wouldn't have to remove them all to sever the connection, I want to make sure there's nothing after R9 that matters. Here's the difference: http://www.retrorgb.com/images/1CHIP-01 ... onents.jpg

Awesome work, thank you! I'll wait for your final conclusions on the csync components before I try this.

[RGB0b]

I'll wait for your final conclusions on the csync components before I try this.

One more person tried and they said removing C46 and R9 worked for them. I'm still waiting on a few other people, just to confirm.

[Voultar]

A lot of people are treating these Ti drivers like the on-board S-RGB encoders when it comes to attenuating the amplitude.

I think I mentioned this before, but the S-RGB encoder has a gain of 6.5dB, it is not 2V/V like the Ti drivers.


Let's look at some figures to better clarify:

Below is a typical reading of the RGB outputs from the 1CHIP ASIC. These values can swing up to roughly 40mV+- in all of my testing of a dozen or so SNES mainboards.

All of these are MANUAL measurements.



So this figure is pretty common, 808mV. Now, let's take a look on the output side of the encoder so we can conclude what the true output gain is on the damn thing.



Again, I've done a manual measurement on the output side. And it's very slightly conservative. But let's look at our measurement, it's 1.74vPP. If we do the simple math and crunch our "loose" figures:

808mV * (Gain multiplier)2= 1.616vPP.

That's way, WAY below our measured output. So by knowing this we can conclude that the RoHM S-RGB encoder has a gain setting of 6.5dB, roughly 2.10V/V, even with my pseudo sloppy measurements.

Take this into consideration while attenuating the amplitude of the RGB outputs. Ti drivers with a fixed gain 2 should not be treated the same as the on-board RGB encoder when shaping up the signal for proper .7vPP/1.4vPP transmission. If you treat it the same, you're going to be over saturated. Just like this chicken I'm eating.

[Pasky]

Out of curiousity, at what point were you measuring those values? (I.E. what was being displayed on the screen).

If you want an accurate rating for color amplitude you'd need a solid screen of said color or a screen that is completely white (all colors at full amplitude).

[Voultar]

Out of curiousity, at what point were you measuring those values? (I.E. what was being displayed on the screen).

If you want an accurate rating for color amplitude you'd need a solid screen of said color or a screen that is completely white (all colors at full amplitude).

That's right, this is a full load. All measurements are being captured under "peak" luma conditions.

Here's another system for ya. This is the 1CHIP ASIC RGB outputs and the S-RGB Encoder (6.5dB) outputs.






There's a bit of DC offset on the outputs, naturally. The 220uF offset caps will take care of that pretty nicely.

Using the sync-tip clamp input mode of the THS73XX chips is perfectly fine. You just want to be careful with the undershoots as things could muck up if those bounce under. But that's really not a problem, either. The same goes for the N64. Even though my scope says AC, the 1CHIPs RGB outputs are DC coupled.


THS7374 outputs measured with 1.8K(R) on the inputs.



Whether you're using the on-board BA6596F or an external video line driver.. 1.2K resistors are insufficient to drop the amplitude down to a proper transmission level. The ghosting, shimmering and reflections are a bi-product of this.

[borti4938]

THS7374 outputs measured with 1.8K(R) on the inputs.

Whether you're using the on-board BA6596F or an external video line driver.. 1.2K resistors are insufficient to drop the amplitude down to a proper transmission level. The ghosting, shimmering and reflections are a bi-product of this.

What I don't get is:
On the one hand, you measured with additional 1.8k resistor loads at the S-CPUN RGB outputs (160ohm load is on the SNES mainboard installed), which gives you around Upp=1.4V at after a 6dB amplifier.
On the other hand, you say that 1.2k is not sufficient for proper attenuation.
From my understanding, 1.2k in parallel with 160ohm is a higher load (less resistant) than 1.8k parallel to 160ohms. So 1.2k || 160ohm should give an output of Upp < 1.4V after the 6dB amp.
Do you mean with proper attenuation that you want to met the standard of Upp = 0.7V (after 50:50 voltage divider with 75ohms); or do you mean with proper attenuation that you want to achieve Upp < 0.7V (which can be done with 1.2k || 160ohm even though it is a bit to dark).

________________________

However,
I have tested the THS7374 with filters in bypass mode (finally) as well as the THS7316 and THS7373 as replacements. What I don't get is that as long as I have the console directly connected to a TV everything is fine. If I connect the console to the OSSC (Video input filter off to see effect) I get jailbar like pattern on the screen if the THS7373 / THS7374 is in bypass mode or if I use a amp with HD filters. With the THS7314 and THS7374 (filters not bypassed) everything is fine...

Here is a picture to show what I meant with "jailbar like pattern".

Spoiler

(THS7374 (filters in bypass mode), THS7316, THS7373 / OSSC input filter off)

[zeruel85]

How did you set Video LPF on OSSC?

[borti4938]

For the picture, I set the video filter off to see the impact of the video filters inside the console. I tested it on two different consoles with three different cables.#
However, also for the HD filters it does not change anything of the pattern if I set the video filter of the OSSC to HD, too, to nearly met 'matched filter principle'.

Of course, if I set the input filter of the OSSC to SD, the pattern is nearly gone as the overall cut-off is 9MHz (maybe the jailbars were just in my mind as I have seen them by switching on/off the OSSC video filter). The best picture without any jailbars I achieve with the SD filter inside the console (THS7314 and THS7374 with LPF on) and SD filter on the OSSC.

[zeruel85]

For the picture, I set the video filter off to see the impact of the video filters inside the console. I tested it on two different consoles with three different cables.#
However, also for the HD filters it does not change anything of the pattern if I set the video filter of the OSSC to HD, too, to nearly met 'matched filter principle'.

Of course, if I set the input filter of the OSSC to SD, the pattern is nearly gone as the overall cut-off is 9MHz (maybe the jailbars were just in my mind as I have seen them by switching on/off the OSSC video filter). The best picture without any jailbars I achieve with the SD filter inside the console (THS7314 and THS7374 with LPF on) and SD filter on the OSSC.

I can try with N64 and SNES Mini with THS7374 in bypass mode and see what happens on my setup.
When I have some free time I'll let you know the results.

[Voultar]

For the picture, I set the video filter off to see the impact of the video filters inside the console. I tested it on two different consoles with three different cables.#
However, also for the HD filters it does not change anything of the pattern if I set the video filter of the OSSC to HD, too, to nearly met 'matched filter principle'.

Of course, if I set the input filter of the OSSC to SD, the pattern is nearly gone as the overall cut-off is 9MHz (maybe the jailbars were just in my mind as I have seen them by switching on/off the OSSC video filter). The best picture without any jailbars I achieve with the SD filter inside the console (THS7314 and THS7374 with LPF on) and SD filter on the OSSC.

What you're seeing is aliasing. The framemeister, for example has a low order anti-aliasing filter which when cascaded with another filter (such as that found on a THS7314) yields a less than ideal picture output.

I don't quite understand what you're asking regarding the amplitude/attenuation of the SNES. Again though, the onboard encoder isn't a 6dB driver.

[borti4938]

What a bummer... of course. Sorry for that stupid question. It was too early in the morning

[Voultar]

What a bummer... of course. Sorry for that stupid question. It was too early in the morning

No that's a very good point that you bring up!

So let's dive into it.

When we are using these TI chips, they typically have a low order 8.5ishmhz filter for SD content.

Now, most of the endpoint equipment that we use also has an AA filter that serves the same purpose. What happens is both of these filters cascade, which causes things to get mucky in the bandwidth, which is why (typically) the 7314 and similar SD video line drivers look muddied when compared to a 7374 or something similar.

When you bypass the 9MHz SD filter on the 7374, the only thing left remainimg is the actual opamp which is 150Mhz. . This basically allows the TV or endpoint (scaler) to handle all of the anti-aliasing itself, without cascading. This is why the picture is generally sharper.

In other words, the more LOW order filters you chain, the more blurry the picture output. A 7316 with its 35mhz filter should yield a close result to the 7374.

Let ONE device handle the bandwidth/filter cutoff.

If the OSSC has a proper aliasing filter (as it should) the results should be good!

99% of the time. The TV/Display/equipment you're using at the end point doesn't have the capability of modifying something like that. We can however control it on the console end.

[Voultar]

THS7374 outputs measured with 1.8K(R) on the inputs.

Whether you're using the on-board BA6596F or an external video line driver.. 1.2K resistors are insufficient to drop the amplitude down to a proper transmission level. The ghosting, shimmering and reflections are a bi-product of this.

What I don't get is:
On the one hand, you measured with additional 1.8k resistor loads at the S-CPUN RGB outputs (160ohm load is on the SNES mainboard installed), which gives you around Upp=1.4V at after a 6dB amplifier.
On the other hand, you say that 1.2k is not sufficient for proper attenuation.
From my understanding, 1.2k in parallel with 160ohm is a higher load (less resistant) than 1.8k parallel to 160ohms. So 1.2k || 160ohm should give an output of Upp < 1.4V after the 6dB amp.
Do you mean with proper attenuation that you want to met the standard of Upp = 0.7V (after 50:50 voltage divider with 75ohms); or do you mean with proper attenuation that you want to achieve Upp < 0.7V (which can be done with 1.2k || 160ohm even though it is a bit to dark).

I read what I said up above and may have even confused myself. lol

So let's look at look at the RGB outs with a 1.2K load in concert with the 160ohm on the board:



There's still as slight overshoot in there on the rising edge. But we'll call that 712-725mV.

Now, let's look at the outputs of the BA6596F encoder with the 1.2K load:



Finally, let's compare that with a THS 2:1 Gain driver with the same load:



From my own testing of a few SNES Mini's; There's a mild swing/variance on the RGB outputs of the 1CHIP ASIC. 1.2K is "okay" for 6dB video-drivers or op-amps in such a configuration. Nonetheless, it is way off the mark when employing the stock, S-RGB encoder and very very non ideal for that application.

[Pasky]

Voultar, for comparability purposes, what exact screen are you using to test RGB levels? I ask because if someone also wishes to test their RGB levels on their SNES it would be much easier to get comparable results if everyone tested the same screen.

I use the the SNES 240P test suite (https://sourceforge.net/projects/testsu ... /SNES_SFC/)

Then, test patterns -> White & RGB Screens.

Then either use the white or R, G, B screens individually.

[Voultar]

Voultar, for comparability purposes, what exact screen are you using to test RGB levels? I ask because if someone also wishes to test their RGB levels on their SNES it would be much easier to get comparable results if everyone tested the same screen.

I use the the SNES 240P test suite (https://sourceforge.net/projects/testsu ... /SNES_SFC/)

Then, test patterns -> White & RGB Screens.

Then either use the white or R, G, B screens individually.

That's precisely what I use.

And for clarity, looking at the composite video output unveils some pretty interesting stuff that could explain a few things..

I annotated it for anyone who's not familiar with how analog CVBS works.

[copy]

I'm happy to say I finally installed Voultar's THS7374 bypass board in my 1CHIP-02. Thanks to Voultar for the board, and RetroRGB for the instructions! So far overall, it looks very nice indeed.

One thing I notice is that the 1CHIP+7374 picture through the XRGB-Mini seems unexpectedly noisy with the XRGB's default color settings. I even see some faint alternating light/dark jailbars, roughly 15 across the screen, on dark blue backgrounds. Lemmings shows it well. Switching to FBX's 4x SNES profile seems to make all this noise go away, though. (To compare, my original non-1CHIP SNES has a lot less noise, and maybe only barely visible jailbars, with default XRGB settings.)

Is this noise maybe caused by the THS7374, or is it common to 1CHIPs? I don't think it was happening on this 1CHIP-02 before I installed the bypass, but I can't say for sure. It was a recent purchase, and I didn't spend a lot of time trying it with the stock RGB.

Side note: This 1CHIP-02 originally had a prominent case of the center vertical bar. Before doing the RGB bypass, I also did a full re-cap. As an experiment, I filled in the "missing" C58 spot with a 2200uf cap. (Credit to this post at Assembler Games for the idea.) Afterward, to my delight, the center bar was rendered almost completely invisible. I can only slightly make it out now in Lemmings, and again only with the default XRGB settings. Perhaps reinstalling this big cap in systems where it was left out is a good solution for the bar.

[Voultar]

I'm happy to say I finally installed Voultar's THS7374 bypass board in my 1CHIP-02. Thanks to Voultar for the board, and RetroRGB for the instructions! So far overall, it looks very nice indeed.

One thing I notice is that the 1CHIP+7374 picture through the XRGB-Mini seems unexpectedly noisy with the XRGB's default color settings. I even see some faint alternating light/dark jailbars, roughly 15 across the screen, on dark blue backgrounds. Lemmings shows it well. Switching to FBX's 4x SNES profile seems to make all this noise go away, though. (To compare, my original non-1CHIP SNES has a lot less noise, and maybe only barely visible jailbars, with default XRGB settings.)

Is this noise maybe caused by the THS7374, or is it common to 1CHIPs? I don't think it was happening on this 1CHIP-02 before I installed the bypass, but I can't say for sure. It was a recent purchase, and I didn't spend a lot of time trying it with the stock RGB.

Side note: This 1CHIP-02 originally had a prominent case of the center vertical bar. Before doing the RGB bypass, I also did a full re-cap. As an experiment, I filled in the "missing" C58 spot with a 2200uf cap. (Credit to this post at Assembler Games for the idea.) Afterward, to my delight, the center bar was rendered almost completely invisible. I can only slightly make it out now in Lemmings, and again only with the default XRGB settings. Perhaps reinstalling this big cap in systems where it was left out is a good solution for the bar.

The Framemeister has a pretty good low order filter, so I highly doubt it's the 7374.

But for clarity, I captured these from a bone stock 1-CHIP-02 into a Startech capture card, does it look anything like this?