So if two devices with filters will cascade and cause interference ie the framemeister or ossc what purpose does having a low pass filter on a 7374 amp have? Is there some other scaler or solution that would benefit from that onboard filter? I would imagine the majority of people using this amp would have a framemeister or osscVoultar wrote:No that's a very good point that you bring up!borti4938 wrote:What a bummer... of course. Sorry for that stupid question. It was too early in the morning
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.
THS7374 vs THS7314 + 1 chip brightness fixing
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Voultar wrote:I read what I said up above and may have even confused myself. lolborti4938 wrote:What I don't get is:Voultar wrote:
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.
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).
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.
So are you saying that the 1.2 k resistors are a sweet spot in attenuation and each mini outputs slightly differently? So you would need to test each mini that is fitted with a bypass amp to get it perfect? sorry I'm an noob but I get curious to these things and I may not be understanding perfect but I this stuff interests me. also the mini has two different variations of the s rgb encoder the ba6595f(srgb) and the ba6596f(srgb a) from your findings are there any slight variations of output of these two?
Re: THS7374 vs THS7314 + 1 chip brightness fixing
SD content is particularly low in the bandwidth spectrum. Ideally, you don't want all of those higher frequencies getting out and essentially letting the floodgates wide open. The purpose of the filter toggle on the 7374 is to select a proper cut-off between SD and HD content. The problem isn't with the filter, but how MANY filters you have in the chain. If you were to have no filter on the SD video, you would get a good deal of aliasing.Frankym2612 wrote:
So if two devices with filters will cascade and cause interference ie the framemeister or ossc what purpose does having a low pass filter on a 7374 amp have? Is there some other scaler or solution that would benefit from that onboard filter? I would imagine the majority of people using this amp would have a framemeister or ossc
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Yes so the framemeister and ossc have good filtering so what scenario would benefit from the filter on the amp direct to a pvm perhaps?
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Appreciate the reply. No, I'm not seeing lots of thin lines like that, but wider dark bars, spaced farther apart. Unfortunately I don't have a capture device, and my cell camera can't quite pick it up either.Voultar wrote: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?
Spoiler
I'll keep looking into it.
Switching subjects: Regarding your findings on the proper attenuation of the 1CHIP RGB output -- if one did the three-resistor mod with the stock encoder, like on RetroRGB's page here, is it still correct to use 750 Ohm resistors? Or do you recommend a new resistor value now?
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Those bars in blue are they in motion? I think that is ghosting a problem that I was trying to find the best fix for different snes video output is all over the place in my messing with models but I will say with voultars board I didn't see any white bar or ghosting. About the resistors tgat is kindof what I was asking above if what is already determined resistor value for the mini and one chip is still preferred or if you would have to use different ones based on console . Borti has another fix for ghosting but it seems to dangerous to the console may easily damage it
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Also a couple more things you only do the 3 wire on a snes mini so it would be 1.2 k resistors but using the stock encoder is not recommended and I would agree it's difficult and a bypass board is easier and more effective if I were you I'm no expert and am not technical but I would remove that extra resistor you put for the vertical it's not needed using that bypass board and I would get a really good shielded c sync cable and a good power strip also I would use 75 ohm sync not ttl
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Sorry also 1 more thing I thought of how did you know how to do the 1 chip install? Bobs guide isn't even up yet I know you have to remove some resistors on the board or lift the rgb pins maybe you didn't do that and that's why?
Re: THS7374 vs THS7314 + 1 chip brightness fixing
http://www.retrorgb.com/snes1chip7374.htmlFrankym2612 wrote:Sorry also 1 more thing I thought of how did you know how to do the 1 chip install? Bobs guide isn't even up yet I know you have to remove some resistors on the board or lift the rgb pins maybe you didn't do that and that's why?
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Nice! Thanks i must have missed it
Re: THS7374 vs THS7314 + 1 chip brightness fixing
The clearest place I've seen my problem so far is in Magical Quest Starring Mickey Mouse. This is not my capture, but is rather grabbed from a MLIG episode. I believe this would have been captured on Coury's unmodded 1CHIP. This is what the background normally looks like, a smooth dark blue color:
Except on my 1CHIP-02+THS7374, I have around 15 darker vertical bar areas throughout the background. Contrary to what I said earlier, I actually do still see it with FBX's SNES profile.
Frankym2612: No, the bars are not in motion. Regarding the resistors, I was asking because I might like to try the brightness correction on a different system without a bypass board, so I can compare the different methods myself.
I'm hoping for Voultar or RetroRGB's opinion on the resistor values... It sounded like, during the Retro Roundtable, they were talking about different values now being better, although I may not have followed correctly.
Except on my 1CHIP-02+THS7374, I have around 15 darker vertical bar areas throughout the background. Contrary to what I said earlier, I actually do still see it with FBX's SNES profile.
Frankym2612: No, the bars are not in motion. Regarding the resistors, I was asking because I might like to try the brightness correction on a different system without a bypass board, so I can compare the different methods myself.
I'm hoping for Voultar or RetroRGB's opinion on the resistor values... It sounded like, during the Retro Roundtable, they were talking about different values now being better, although I may not have followed correctly.
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
You should have seen bob and voultar yesterday they had a full test of all the filters on boards and the stock encoder with the ossc! Which has opened my eyes to what voultar was saying about cascading filters I hope the new framemeister if we get one will have filter options like the ossc and I think bob used 1.1 k resistors in his testing
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Plus I'm not telling you not to because I love experimenting too but I wouldn't recommend the 3 wire mod with the stock encoder because like voultar says even with the resistors it's not good to tap straight from that encoder plus if you haven't soldered a lot it's tricky to solder to those tiny pins and running wire and putting resistors it's a pain but bob should be putting all his tests on his page. Im sure you are like me and want the sharpest and clearest picture so I'm still awaiting the perfect result too so far voultars board no filter on a mini through a framemeister or ossc seems the best but I await more testing and want to test myself too once his boards are in stock
Re: THS7374 vs THS7314 + 1 chip brightness fixing
So yesterday RetroRGB and I did a live Twitch Stream where we exposed some new mythology that's been lurking around. It's pretty important and long, no spoilers, I'm a manly man.
The SNES used was a Mini, and the RGB drivers that were employed were:
S-RGB Encoder
7314 -Attenuated
7316 -Attenuated
7374 -PROPERLY Attenuated
To prove a point with filter cascade, Bob took a series of screen captures of all of these different RGB mods while manipulating the LPF filter ON the OSSC.
Let's take a look:
This is the S-RGB encoder with the filter OFF in the OSSC.
This is the S-RGB encoder with the filter ON, set to 9Mhz (typical bandwidth for SD content)
So what's happening here? Well, it's really simple. The S-RGB encoder doesn't have a low order filter on the outputs. All of those high frequencies are getting out and running a muck. And since the OSSC isn't low passing the video bandwidth, you get this aliasing pattern, the vertical bars. This isn't a problem for analog devices like SD CRT's. This is a DIGITAL process, and the the low order filter only becomes relevant when you pass it off for digital conversion. But this is important to note. Some TV's, for example, may only have a filter cut-off for HD bandwidth. Now, this is perfectly fine providing that you have some kind of low order filtering in the video chain somewhere (the console). But if you don't, THAT is what you're going to see. Ergo the 1CHIP-02 capture that I shared, earlier.
Now, let's take a look at the 7314 with NO filter set on the OSSC. Remember, the 7314 has a 5th order Ms. Buttersworth filter that's has a cut-off @ 8.5Mhz. So even though the OSSC's LPF is disabled, we still have a video filter in our video chain doing the job.
The results are quite predictable. We still have a filter in the video chain to the TV, so even though it's off on the OSSC, we're still catching those high frequencies and mitigating any aliasing effects.
Let's now look at the 7314 with the OSSC set to 9Mhz on the LPF:
^ We now have two filters in the video chain. This is where we see a "cascading" effect. The image is losing its sharper detail, and things get a little mucky when have multiple filters in the chain.
Let's now look at the 7316. This chip is an appropriate drop-in replacement for the 7314 boards running around. It has a 35Mhz filter.
7316 with filter off on the OSSC:
Ah, look at all of the aliasing! 35Mhz isn't nearly tight enough for low bandwidth video so the filter is effectively useless. We can again see all of the aliasing in the image output.
Let's look at the 7316 with the filter set to 9Mhz on the OSSC:
This is much, much better. With the 9Mhz low-pass filter enabled on the OSSC, we're catching all of the high frequency stuff, again. Mitigating the aliasing effect.
Now we'll take a look at the 7374. This is a 4 channel video driver with a 9.5Mhz 6th order Ms. Butterworth filter. The LPF on this chip is superior to that found on the 7314. But, we can also disable the onboard filter of the THS7374, only leaving the 150Mhz op-amp, effectively killing ALL filtering.
Let's take a look at the 7374 with the filter off on both the chip AND the OSSC:
Yet again, quite predictable. We're not filtering out all of the higher frequency content of this low bandwidth video. We're getting a lot of aliasing, as a result.
Now, the the 7374 with the filter still off, but the OSSC has its LPF on and set to 9Mhz:
The point of all of this is to clear of any confusion over these THS video drivers and their cut-off filtering. It's not about having no filtering (that's bad). It's about HOW MANY filters you have in the chain.
The 7314 is perfectly fine. It CAN be just as sharp as the 7374 and the 7316, providing that it's the ONLY filter in the chain. To put this matter to bed and finish proving the point, take a look at this:
From left to right: 7316 with 9Mhz filter enabled, 7314 with OSSC set to 9Mhz, 7314 with OSSC filter set to OFF. Notice how the 7314 picture on the far right rivals the 7316. It's not about the filter, it's about HOW MANY filters.
The only caveat to the 7316 is that it doesn't have the capability of enabling/disabling this filter. Someone messaged me this morning asking if the low pass filter strap was necessary on my designs. I guess Bad-Ass Consoles was looking at one of my boards or something on his LiveStream, and was wondering why I would even bother with giving people the option as it wasn't necessary. Well, analog video is a fickle bitch. Unfortunately there IS equipment out there including TV's that will treat SD content as HD content as far as the filtering spectrum is concerned. So everything will typically be parsed through a 30Mhz+ low pass aliasing filter. If you don't at least have the option of turning it off and on, you MAY run into some trouble like you see in the pictures above. By default, ALL of my boards are configured with the LPF to be disabled. BUT.. if you DO run into trouble with a particular device, you can easily short a jumper and tie the enable pin low. So it's really not a burden for anyone. And as far as I'm aware. the OSSC is the ONLY hardware I can find that allows you to directly manipulate the low-pass filter directly. That's why we used it in our testing methodology. So if you're using an OSSC or a Frameister, having the filter permanently disabled is completely fine. But if you plan on using other equipment, there's a small chance that you'll run into this. That's why I started putting the LPF toggle on all of my designs. It will probably never be an issue, but you just never know how that $10 RGB scaler is going to handle it. Component inputs on some TV's might ALSO not be geared toward lower bandwidth video. I'd wager that the amount of TV's that do so are very, very limited. But I'm sure they do exist. The Frameister certainly doesn't afford you the ability to manipulate the bandwidth of the video filter. Keep all of this in mind.
Again, NO filters is bad. CASCADING filters is what causes this degradation during the ADC process.. Try to have only 1 filter in your video chain.
The SNES used was a Mini, and the RGB drivers that were employed were:
S-RGB Encoder
7314 -Attenuated
7316 -Attenuated
7374 -PROPERLY Attenuated
To prove a point with filter cascade, Bob took a series of screen captures of all of these different RGB mods while manipulating the LPF filter ON the OSSC.
Let's take a look:
This is the S-RGB encoder with the filter OFF in the OSSC.
This is the S-RGB encoder with the filter ON, set to 9Mhz (typical bandwidth for SD content)
So what's happening here? Well, it's really simple. The S-RGB encoder doesn't have a low order filter on the outputs. All of those high frequencies are getting out and running a muck. And since the OSSC isn't low passing the video bandwidth, you get this aliasing pattern, the vertical bars. This isn't a problem for analog devices like SD CRT's. This is a DIGITAL process, and the the low order filter only becomes relevant when you pass it off for digital conversion. But this is important to note. Some TV's, for example, may only have a filter cut-off for HD bandwidth. Now, this is perfectly fine providing that you have some kind of low order filtering in the video chain somewhere (the console). But if you don't, THAT is what you're going to see. Ergo the 1CHIP-02 capture that I shared, earlier.
Now, let's take a look at the 7314 with NO filter set on the OSSC. Remember, the 7314 has a 5th order Ms. Buttersworth filter that's has a cut-off @ 8.5Mhz. So even though the OSSC's LPF is disabled, we still have a video filter in our video chain doing the job.
The results are quite predictable. We still have a filter in the video chain to the TV, so even though it's off on the OSSC, we're still catching those high frequencies and mitigating any aliasing effects.
Let's now look at the 7314 with the OSSC set to 9Mhz on the LPF:
^ We now have two filters in the video chain. This is where we see a "cascading" effect. The image is losing its sharper detail, and things get a little mucky when have multiple filters in the chain.
Let's now look at the 7316. This chip is an appropriate drop-in replacement for the 7314 boards running around. It has a 35Mhz filter.
7316 with filter off on the OSSC:
Ah, look at all of the aliasing! 35Mhz isn't nearly tight enough for low bandwidth video so the filter is effectively useless. We can again see all of the aliasing in the image output.
Let's look at the 7316 with the filter set to 9Mhz on the OSSC:
This is much, much better. With the 9Mhz low-pass filter enabled on the OSSC, we're catching all of the high frequency stuff, again. Mitigating the aliasing effect.
Now we'll take a look at the 7374. This is a 4 channel video driver with a 9.5Mhz 6th order Ms. Butterworth filter. The LPF on this chip is superior to that found on the 7314. But, we can also disable the onboard filter of the THS7374, only leaving the 150Mhz op-amp, effectively killing ALL filtering.
Let's take a look at the 7374 with the filter off on both the chip AND the OSSC:
Yet again, quite predictable. We're not filtering out all of the higher frequency content of this low bandwidth video. We're getting a lot of aliasing, as a result.
Now, the the 7374 with the filter still off, but the OSSC has its LPF on and set to 9Mhz:
The point of all of this is to clear of any confusion over these THS video drivers and their cut-off filtering. It's not about having no filtering (that's bad). It's about HOW MANY filters you have in the chain.
The 7314 is perfectly fine. It CAN be just as sharp as the 7374 and the 7316, providing that it's the ONLY filter in the chain. To put this matter to bed and finish proving the point, take a look at this:
From left to right: 7316 with 9Mhz filter enabled, 7314 with OSSC set to 9Mhz, 7314 with OSSC filter set to OFF. Notice how the 7314 picture on the far right rivals the 7316. It's not about the filter, it's about HOW MANY filters.
The only caveat to the 7316 is that it doesn't have the capability of enabling/disabling this filter. Someone messaged me this morning asking if the low pass filter strap was necessary on my designs. I guess Bad-Ass Consoles was looking at one of my boards or something on his LiveStream, and was wondering why I would even bother with giving people the option as it wasn't necessary. Well, analog video is a fickle bitch. Unfortunately there IS equipment out there including TV's that will treat SD content as HD content as far as the filtering spectrum is concerned. So everything will typically be parsed through a 30Mhz+ low pass aliasing filter. If you don't at least have the option of turning it off and on, you MAY run into some trouble like you see in the pictures above. By default, ALL of my boards are configured with the LPF to be disabled. BUT.. if you DO run into trouble with a particular device, you can easily short a jumper and tie the enable pin low. So it's really not a burden for anyone. And as far as I'm aware. the OSSC is the ONLY hardware I can find that allows you to directly manipulate the low-pass filter directly. That's why we used it in our testing methodology. So if you're using an OSSC or a Frameister, having the filter permanently disabled is completely fine. But if you plan on using other equipment, there's a small chance that you'll run into this. That's why I started putting the LPF toggle on all of my designs. It will probably never be an issue, but you just never know how that $10 RGB scaler is going to handle it. Component inputs on some TV's might ALSO not be geared toward lower bandwidth video. I'd wager that the amount of TV's that do so are very, very limited. But I'm sure they do exist. The Frameister certainly doesn't afford you the ability to manipulate the bandwidth of the video filter. Keep all of this in mind.
Again, NO filters is bad. CASCADING filters is what causes this degradation during the ADC process.. Try to have only 1 filter in your video chain.
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Thanks for this voultar! And thanks to you and bob for streaming that now I know what you were saying about the filters. Ya so much can go wrong in analog I have gotten interference before just by using a cheap power strip for my cables! Also I know that every revision console can have slim through different boa ds even within the same revision and better/cheaper components even in the same run so lots of tests seem to need to be done for the best. I'm fortunate to have a 1 chip 03 with no white bar and a good picture even with the 7314 so I can't wait to swap with voultars new board and also it's good that filter is on there in case of any aliasing or whatever else but I don't think ille have that problem a mini I modded with the board looked perfect also I hope micomsoft will put the filter option on their next scaler
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Thank Bob. He did all of the hard work yesterday doing all of the captures and testing. We unfortunately lost the stream. But he's going to post all of the results onto a nice, comprehensive page on his website.Frankym2612 wrote:Thanks for this voultar! And thanks to you and bob for streaming that now I know what you were saying about the filters. Ya so much can go wrong in analog I have gotten interference before just by using a cheap power strip for my cables! Also I know that every revision console can have slim through different boa ds even within the same revision and better/cheaper components even in the same run so lots of tests seem to need to be done for the best. I'm fortunate to have a 1 chip 03 with no white bar and a good picture even with the 7314 so I can't wait to swap with voultars new board and also it's good that filter is on there in case of any aliasing or whatever else but I don't think ille have that problem a mini I modded with the board looked perfect also I hope micomsoft will put the filter option on their next scaler
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Everything in that post is spot-on and as soon as I have a few hours (tomorrow morning?) all my pages will be updated to reflect this. The only thing that I don't 100% agree with is that I will always recommend people either use the 7316 amp or the 7374 amp with the filter off. Any CRT or analog equipment won't have any issues with "unfiltered" video...that's why the S-RGB doesn't have one. It really is only an analog to digital issue and in almost every scenario, a filter will be in there somewhere (even the gscartsw has a filter). I'm really glad this was explained though, both because I love knowing why things work the way they do and in case anyone runs into an issue with this. I honestly think the ONLY scenario where you'd want the filter on would be direct into capture cards without a filter (most have them), bad upscalers and new flat-screens that don't process analog 240p signals correctly (meaning 240p analog with no upscaling, directly into an HDTV).
Voultar explains that pretty clearly above, but in such a long post (no offence), that point may have been lost. I also agree that having the option on his boards to toggle it on and off is always better then not having the option.
Voultar explains that pretty clearly above, but in such a long post (no offence), that point may have been lost. I also agree that having the option on his boards to toggle it on and off is always better then not having the option.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Bob is right. Like I said, I agree with that 90% of the time. But IF and I mean IF you have a funky device or you're parsing your analog RGB through a television that DOES process 240P but treats it with a filter designed for HD bandwidth, you may run into those problems. The likely hood of that is quite low, but I never take anything completely off of the table.
For 95% of you, this shit doesn't matter. Continue on in your sexual life.
For 95% of you, this shit doesn't matter. Continue on in your sexual life.
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Ya thanks bob! That was a interesting and funny stream and informative! So I thought I heard the resistors you used were 1.1? And is that what voultars boards have?
Re: THS7374 vs THS7314 + 1 chip brightness fixing
That will be for later. I'm going to show the various loads across several 1CHIP and Mini systems to put another old myth to rest concerning attenuation. I've sorta already done that and proven a point. But there's still work to be done here.Frankym2612 wrote:Ya thanks bob! That was a interesting and funny stream and informative! So I thought I heard the resistors you used were 1.1? And is that what voultars boards have?
ESPECIALLY when it comes to attenuating the amplitude for the 6.5db S-RGB encoder.
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Cool can't wait to see your loads wait that sounded wrong lol!
Re: THS7374 vs THS7314 + 1 chip brightness fixing
What about the framemeister?
So, S-RGB Encoder + Framemeister = Ok and THS7314 + Framemeister = bad because of cascading filters?
So, S-RGB Encoder + Framemeister = Ok and THS7314 + Framemeister = bad because of cascading filters?
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Ripthorn wrote:What about the framemeister?
So, S-RGB Encoder + Framemeister = Ok and THS7314 + Framemeister = bad because of cascading filters?
Save the pictures that I posted, blow the S-RGB up and compare it to the others. Driver characteristics need to be taken into account, too.
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
I wouldn't say any of them are "bad" more just preference I have the 7314 going through the framemeister and I think it looks good albeit a slight bit bright but me personally I like razor sharp so I'm going to replace with the 7374 I think most people would be happy with any board
-
- Posts: 17
- Joined: Tue Oct 07, 2014 9:25 am
- Location: Spain
Re: THS7374 vs THS7314 + 1 chip brightness fixing
About the ghosting issue, I guess it's a different matter that makes no difference when using one board or another, right?
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Thanks for all the testing and information about the filters. Quite ironic that all the people getting the 7314 mod and using a Framemeister have a worse picture than with the stock encoder.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Well, "worse picture" is a relative term. This experiment was done to test the filter-on-filter issues, as well as see if we can squeeze .01% more out of the SNES' video output. There is absolutely nothing wrong with using a THS7314 and it's my opinion that if you already have a 7314 mod, unless the SNES is your absolute, favorite system then don't bother swapping it out. That being said, if you're doing the mod for the first time, you might as well use the 7374 with filter toggle, as it's only a few dollars more and the best you can get at the moment.paulb_nl wrote:Thanks for all the testing and information about the filters. Quite ironic that all the people getting the 7314 mod and using a Framemeister have a worse picture than with the stock encoder.
-
- Posts: 30
- Joined: Thu Dec 29, 2016 5:43 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
In a couple days I'm going to take some pics of my 1 chip 03 going through the framemeister with the 7314 chip to show how it looks
Re: THS7374 vs THS7314 + 1 chip brightness fixing
That's a good explaination Voultar. I think it solved some questions but also created others for me:
- Is there an optimal setup that is also versitle? (1 SNES console that will be optimal on PVM, OSSC and XRGB)?
1) xrgb lpf can't be controller like ossc. It's intensity also changes based on firmware you use! Need best solution here given there's a lot more xrgb mini users than ossc.
2) OSSC - good answers above
3) PVM - the noise seems to be high frequency coupled into the data lines. OSSC/XRGB samples the analog data and sees it; assuming it's part od the picture (hence jailbars). These frequencies too fast for CRT and hence it doesn't see it. There should be no visible difference between lpf on or off on pvm.
- Is there an optimal setup that is also versitle? (1 SNES console that will be optimal on PVM, OSSC and XRGB)?
1) xrgb lpf can't be controller like ossc. It's intensity also changes based on firmware you use! Need best solution here given there's a lot more xrgb mini users than ossc.
2) OSSC - good answers above
3) PVM - the noise seems to be high frequency coupled into the data lines. OSSC/XRGB samples the analog data and sees it; assuming it's part od the picture (hence jailbars). These frequencies too fast for CRT and hence it doesn't see it. There should be no visible difference between lpf on or off on pvm.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Yes, no filter on the console side.leonk wrote:- Is there an optimal setup that is also versitle? (1 SNES console that will be optimal on PVM, OSSC and XRGB)?
The XRGB-Mini has a good short order filter, regardless. Leaving it off on the 7374 or using the THS7316 is perfectly fine.leonk wrote: 1) xrgb lpf can't be controller like ossc. It's intensity also changes based on firmware you use! Need best solution here given there's a lot more xrgb mini users than ossc.
Analog (SD) CRT's are designed for this. The grand majority of SD video encoders don't have any low passing on the outputs. What were talking about is completely in the digital space. So in 99% of cases, leave the filter off. If you have some strange oddball device that doesn't do this before the ADC, you may want to turn it on.leonk wrote: 3) PVM - the noise seems to be high frequency coupled into the data lines. OSSC/XRGB samples the analog data and sees it; assuming it's part od the picture (hence jailbars). These frequencies too fast for CRT and hence it doesn't see it. There should be no visible difference between lpf on or off on pvm.