THS7374 vs THS7314 + 1 chip brightness fixing
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Forgot to mention:
- I always use cables with my SNES build for "sync on luma" (with no add. components). On the luma pin of the SNES I output sync designed for 75ohm termination.
- In the EU it is even more risky to have a "sync on raw csync" (i.e. using pin 3 of the MultiAV port) as unmodified PAL consoles outputs 12V there even if only the PSU is active and the console is off!
It's a quite convenient way I found for me. There is no risk to overdrive something just because I use my self-made cable on an unmodified console.
- I always use cables with my SNES build for "sync on luma" (with no add. components). On the luma pin of the SNES I output sync designed for 75ohm termination.
- In the EU it is even more risky to have a "sync on raw csync" (i.e. using pin 3 of the MultiAV port) as unmodified PAL consoles outputs 12V there even if only the PSU is active and the console is off!
It's a quite convenient way I found for me. There is no risk to overdrive something just because I use my self-made cable on an unmodified console.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
So I noticed something. When I use S-Video with my Extron Lancia line doubler through my CRT monitor, the "jailbars" disappear completely, although when I use RGB (tested both CSync and Sync on Luma) (using both borti's old 7314 board for SHVC-CPU-01 and stock), S-Video, or CVBS with any other display (tested with 3 CRTs now), I get the "jailbars." Is there some kind of filtering going on with either the line doubler or the CRT monitor?
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Let's not forget why people are so hungry for using C-Sync only. It's not because it's "better". It's because 95% of cables are designed incorrectly. Or at least, they have a bad design flaw.
The squiggly sine-wave in the chroma burst is unique in the fact that your other transmission lines (red green and blue) don't have a similar wave-form.. If the CVBS line isn't shielded through the cable, it will easily couple into the others. If it was shielded from point to point, C-Sync would have never been a popular topic point.
The squiggly sine-wave in the chroma burst is unique in the fact that your other transmission lines (red green and blue) don't have a similar wave-form.. If the CVBS line isn't shielded through the cable, it will easily couple into the others. If it was shielded from point to point, C-Sync would have never been a popular topic point.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Yeah I really dont understand this recent obsession with using CSYNCborti4938 wrote: If you use a stock console and a 75ohm sync termination one should use composite video or luma in my point of view. The sync information in there is the same and with a good cable composite video / luma part of the signal has very very minor influence on the R, G, B lines.
I have yet to see any evidence that using CSYNC produces a much better picture than using either Composite Video or Luma for sync with a well shielded cable. Its especially odd when you consider that both Composite Video and Luma are designed for 75ohm and work equally well, whereas CSYNC output levels can vary depending on the console.
....Is there something i'm missing? <EDIT> Just seen Voultar's post, so I guess it really is just a case of people using poor quality unshielded cables?
Re: THS7374 vs THS7314 + 1 chip brightness fixing
With a properly shielded cable, there is no difference in quality, but many devices require a "clean" sync signal. Using csync that's properly attenuated just removes any chance of interference from cvbs and ensures compatibility.Link83 wrote:Yeah I really dont understand this recent obsession with using CSYNC
I have yet to see any evidence that using CSYNC produces a much better picture than using either Composite Video or Luma for sync with a well shielded cable. Its especially odd when you consider that both Composite Video and Luma are designed for 75ohm and work equally well, whereas CSYNC output levels can vary depending on the console.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Hmm, but if a particular device requires a clean sync signal, wouldn't it make more sense to fit a sync stripper such as the LM1881 inside the device (Or even inside an adapter block just before the devices RGB input) Rather than trying to acquire CSYNC from every console?retrorgb wrote:With a properly shielded cable, there is no difference in quality, but many devices require a "clean" sync signal. Using csync that's properly attenuated just removes any chance of interference from cvbs and ensures compatibility.Link83 wrote:Yeah I really dont understand this recent obsession with using CSYNC
I have yet to see any evidence that using CSYNC produces a much better picture than using either Composite Video or Luma for sync with a well shielded cable. Its especially odd when you consider that both Composite Video and Luma are designed for 75ohm and work equally well, whereas CSYNC output levels can vary depending on the console.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Link83 wrote:Hmm, but if a particular device requires a clean sync signal, wouldn't it make more sense to fit a sync stripper such as the LM1881 inside the device (Or even inside an adapter block just before the devices RGB input) Rather than trying to acquire CSYNC from every console?retrorgb wrote:With a properly shielded cable, there is no difference in quality, but many devices require a "clean" sync signal. Using csync that's properly attenuated just removes any chance of interference from cvbs and ensures compatibility.Link83 wrote:Yeah I really dont understand this recent obsession with using CSYNC
I have yet to see any evidence that using CSYNC produces a much better picture than using either Composite Video or Luma for sync with a well shielded cable. Its especially odd when you consider that both Composite Video and Luma are designed for 75ohm and work equally well, whereas CSYNC output levels can vary depending on the console.
No. An LM1881 is going to generate a certain amount of line delay. And based on how many uS that line-delay is, the raster will start drawing the screen "too late" causing a horizontal shift in the picture. That's on top of all of the nasty reflection problems and other things you have to take into account. If you have a device that requires a logic level sync signal, you should use what the console provides. An LM1881 should really only be used if you don't have access to this.
Just my $0.02 on the matter.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Basically what it boils down to is a proper csync signal is the most 'compatible' method. However, there are many instances where sync-on-luma works every bit as well. I've got a ps1 and a saturn luma-sync cable, and they both perform identically to csync on the Framemeister.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Managed to get some clear pictures of the jailbars on my SHVC-CPU-01 on my CRT. Manual focus in a dark room FTW. Most obvious on the FF6 opening. Also happens on my modded Mini, but the bars are of different widths. This is also with borti's 7314 board installed, so I have a LPF installed (also happens on a stock one).
https://imgur.com/a/1cyrT
I also can't figure out what's causing the purple bar on the left side, but that happens on all my SNESs (including my modded Mini). I've tested multiple SNESs on multiple CRTs (including my RGB modded CRTs), and they all have the same issue. Doesn't happen on any of my other consoles.
https://imgur.com/a/1cyrT
I also can't figure out what's causing the purple bar on the left side, but that happens on all my SNESs (including my modded Mini). I've tested multiple SNESs on multiple CRTs (including my RGB modded CRTs), and they all have the same issue. Doesn't happen on any of my other consoles.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
are you using sync on composite video?
I noticed one of the RGB modded TV's (Sony) I did this to had this problem. Moving to csync fixed it.
I noticed one of the RGB modded TV's (Sony) I did this to had this problem. Moving to csync fixed it.
-
- Posts: 1530
- Joined: Thu Mar 02, 2017 6:53 pm
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Is the current, preferred, fix for the 1Chip's being too bright still simply adding the 3x 750 Ohm resistors? Or is there a better fix people are using now?
I have a SNES, original/phat, 1CHIP-02 and would like to fix the brightness so I don't have to turn down all my monitors every time I play SNES.
I have a SNES, original/phat, 1CHIP-02 and would like to fix the brightness so I don't have to turn down all my monitors every time I play SNES.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Nope. CSync everywhere with very well shielded Monoprice SVGA cabling (RGB individually shielded). Homemade cables, so I know it's good. And before you ask, I do have the correct amount of resistance to drop the TTL sync down to 75 Ohm compliant levels. Both issues also show up with both composite and S-Video as well.leonk wrote:are you using sync on composite video?
I noticed one of the RGB modded TV's (Sony) I did this to had this problem. Moving to csync fixed it.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Well that's weird because in all my life of using various SNES consoles on various CRTs, I've never seen that before. You must have some of the worst luck to have that purple stripe happen on so many different consoles on different TVs. Unless by chance you're using the same power supply on those tests?syboxez wrote:
I've tested multiple SNESs on multiple CRTs (including my RGB modded CRTs), and they all have the same issue. Doesn't happen on any of my other consoles.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
On the XRGB3, using clean sync also solves the problem of sync drop outs when the image is too bright. But who uses XRGB3 now OSSC is out right?Let's not forget why people are so hungry for using C-Sync only. It's not because it's "better". It's because 95% of cables are designed incorrectly. Or at least, they have a bad design flaw.
OSSC Forums - http://www.videogameperfection.com/forums
Please check the Wiki before posting about Morph, OSSC, XRGB Mini or XRGB3 - http://junkerhq.net/xrgb/index.php/Main_Page
Please check the Wiki before posting about Morph, OSSC, XRGB Mini or XRGB3 - http://junkerhq.net/xrgb/index.php/Main_Page
Re: THS7374 vs THS7314 + 1 chip brightness fixing
I've also tried different power supplies. Right now, I'm using a power supply that I built (transformer, bridge rectifier, Pi filter with a ton or capacitance), so I know it's good clean power.FBX wrote:Well that's weird because in all my life of using various SNES consoles on various CRTs, I've never seen that before. You must have some of the worst luck to have that purple stripe happen on so many different consoles on different TVs. Unless by chance you're using the same power supply on those tests?syboxez wrote:
I've tested multiple SNESs on multiple CRTs (including my RGB modded CRTs), and they all have the same issue. Doesn't happen on any of my other consoles.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Well there's gotta be something unique to your setup for a purple stripe to happen on every SNES and CRT combo you've tried. Obviously there would be plenty of other people with the same issue if it were so common as to show up on multiple CRTs and consoles.syboxez wrote: I've also tried different power supplies. Right now, I'm using a power supply that I built (transformer, bridge rectifier, Pi filter with a ton or capacitance), so I know it's good clean power.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Weird. Either way, I'm much more concerned about the jailbars than the purple stripe. The stripe is really only visible on the FF6 intro.FBX wrote:Well there's gotta be something unique to your setup for a purple stripe to happen on every SNES and CRT combo you've tried. Obviously there would be plenty of other people with the same issue if it were so common as to show up on multiple CRTs and consoles.syboxez wrote: I've also tried different power supplies. Right now, I'm using a power supply that I built (transformer, bridge rectifier, Pi filter with a ton or capacitance), so I know it's good clean power.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
I also have this problem of jail bars with every SNES revision I have. SNES is also really the only console I have this problem with. Some worse than others (RGB-01 is by far the worst). I have a SFC 1CHIP-01 that I would like to make my main SNES but even on this one the jail bars are quite noticeable. I added the 750 ohm resistors but while it improved the colors the jail bars are unaffected.
I tried various ways of connecting the SNES to see what effect it has. SNES - sync strike - PEXHDCAP they are quite noticeable. It gets reduced with the combination SNES - gscart - OSSC with low pass filter - Tendak - Extron RXI - PEXHDCAP at the cost of some sharpness but it's still quite visible. I'm surprised some people don't have any of these bars visible.
I also tried SNES - Extron Crosspoint - OSSC 2X - Tendak - Extron RXI - BVM D24 (yeah it's quite the setup) and while it produces a beautiful 480p image on the BVM these lines are also noticeable on the BVM itself (less so with direct 240p connection).
I'm wondering if doing the RGB bypass + ghosting fix + low pass filter will fix this?
I tried various ways of connecting the SNES to see what effect it has. SNES - sync strike - PEXHDCAP they are quite noticeable. It gets reduced with the combination SNES - gscart - OSSC with low pass filter - Tendak - Extron RXI - PEXHDCAP at the cost of some sharpness but it's still quite visible. I'm surprised some people don't have any of these bars visible.
I also tried SNES - Extron Crosspoint - OSSC 2X - Tendak - Extron RXI - BVM D24 (yeah it's quite the setup) and while it produces a beautiful 480p image on the BVM these lines are also noticeable on the BVM itself (less so with direct 240p connection).
I'm wondering if doing the RGB bypass + ghosting fix + low pass filter will fix this?
Spoiler
SNES 1CHIP-01 - sync strike - PEXHDCAP
SNES 1CHIP-01 - Extron Crosspoint - OSSC 2X- Tendak - Extron RXI - PEXHDCAP
SNES 1CHIP-01 - gscart - Extron Crosspoint - OSSC 2X - Tendak - Extron RXI - PEXHDCAP
SNES 1CHIP-01 - Extron Crosspoint - OSSC 2X- Tendak - Extron RXI - PEXHDCAP
SNES 1CHIP-01 - gscart - Extron Crosspoint - OSSC 2X - Tendak - Extron RXI - PEXHDCAP
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Those lines are what I see when I run a SNES with a video pipeline that is completely lacking an LPF. In my case, turning on the LPF on the OSSC solves it.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
But I do have an LPF in the chain in the form of the THS7314 (in the pictures I linked). Scalers/linedoublers aren't an option for me since I use CRTs.Guspaz wrote:Those lines are what I see when I run a SNES with a video pipeline that is completely lacking an LPF. In my case, turning on the LPF on the OSSC solves it.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
@WMJ: I'm sorry if I missed it, but did you try your SNES directly into the OSSC with the OSSC's LFP turned on? Also, is your RGB cable syncing on cvbs, luma, etc? Have you tried a different PSU?
Re: THS7374 vs THS7314 + 1 chip brightness fixing
I have tried a 2 different PSU's with identical results. Because I'm in Europe I have to use a drop down converter with the Nintendo PSU but I tried a European one with the right specs (I use it normally for the AV Famicom) but it had the same results.retrorgb wrote:@WMJ: I'm sorry if I missed it, but did you try your SNES directly into the OSSC with the OSSC's LFP turned on? Also, is your RGB cable syncing on cvbs, luma, etc? Have you tried a different PSU?
If I connect the SNES directly to the OSSC via the SCART plug with LPF set to SDTV (9 MHz) the image looks like the last picture I posted (so partly cleans up the vertical lines). I get an identical image with connecting the SNES to a gscart switch (that has the LPF build in). I have also tried running the SCART output of the gscart into the OSSC with 9 MHz LPF so there are 2 in a row but the image stays the same with the vertical lines. It really is improved though with 1 LPF in the chain but still not completely gone as can be seen in the last picture.
I found out the OSSC doesn't apply the LPF to the D-Sub connector (how I normally have it connected in my setup via the Extron Crosspoint). For some reason doing a BNC to SCART out from the Crosspoint to the OSSC the signal is not recognized but via a BNC to D-Sub it's fine.
As for the cables I use. I have used the Nintendo brand Gamecube SCART cable with composite video as sync, the retro console accessoiries extra shielded csync SCART cable as wel as the retro gaming cables csync SCART cable (latest version). They all look identical.
I think my next step will be doing the Borti bypass board when it becomes available again for orders.
I did see these lines on all 3 SFC revisions I have tried (GPM-02, RGB-01, 1CHIP-01). RGB-01 is by far the worst one, GPM-02 is similar to the 1CHIP-01 with the vertical lines but image is more blurry as is already known.
I have all my (non-HDMI) consoles connected to the crosspoint switch and SFC is really the only one with these lines (Saturn, PS1/2, Dreamcast, N64, Famicom (with NESRGB) and Gamecube all don't have it). I don't have a Genesis to test now so that one may be worse with the stock RGB.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Thanks a lot for the clarifications (especially the summary from Voultar + retrorgb).
Just for my personal understanding a short summary:
* Without any LPF you will always have some noise when doing digital sampling of an analog signal
* Having a single LPF in the chain will remove this noise, but will cause a _slightly_ softer image
* Having multiple LPFs in the chain has no benefit, and will degrade (soften) the image quality further
I also started a checklist for my equipment to decide where in my personal chain the LPF makes the most sense:
* Framemeister - older Firmware has LPF always on, up-to-date Firmware has it on only in GAME_1 or MEISTER modes (but those should not be used for other reasons)
* gscartsw - contains an LPF
* gscartsw_lite - contains no LPF
* N64RGB - contains an THS7374 with LPF set to ON
* SNES - see this thread (THS 7314 has LPF always ON, THS 7316 has LPF always OFF, THS 7374 has a jumper for ON or OFF)
-> Since my N64RGB contains a "forced" LPF, for me personally it makes most sense to have the LPF contained in all of my console mods, use the gscartsw_lite and Framemeister with LPF off (PICTURE mode).
-> An alternative would be to have LPF off in all console mods and use the gscartsw
Some open questions:
* Is there a source for the "N64RGB has LPF active" claim? (http://etim.net.au/n64rgb/ does not really mention this)
* I assume unmodified SNES / unmodified consoles in general have no filtering? (For example I'm using an unmodified Sega Mega Drive 2, following the logic in this thread I should have no LPF and see visual noise, but as far as I can tell there is none)
* Does the "have at 1 LPF in chain" rule apply to all retro consoles with analog output (especially regarding N64, SNES, SMD2, PS2)?
Just for my personal understanding a short summary:
* Without any LPF you will always have some noise when doing digital sampling of an analog signal
* Having a single LPF in the chain will remove this noise, but will cause a _slightly_ softer image
* Having multiple LPFs in the chain has no benefit, and will degrade (soften) the image quality further
I also started a checklist for my equipment to decide where in my personal chain the LPF makes the most sense:
* Framemeister - older Firmware has LPF always on, up-to-date Firmware has it on only in GAME_1 or MEISTER modes (but those should not be used for other reasons)
* gscartsw - contains an LPF
* gscartsw_lite - contains no LPF
* N64RGB - contains an THS7374 with LPF set to ON
* SNES - see this thread (THS 7314 has LPF always ON, THS 7316 has LPF always OFF, THS 7374 has a jumper for ON or OFF)
-> Since my N64RGB contains a "forced" LPF, for me personally it makes most sense to have the LPF contained in all of my console mods, use the gscartsw_lite and Framemeister with LPF off (PICTURE mode).
-> An alternative would be to have LPF off in all console mods and use the gscartsw
Some open questions:
* Is there a source for the "N64RGB has LPF active" claim? (http://etim.net.au/n64rgb/ does not really mention this)
* I assume unmodified SNES / unmodified consoles in general have no filtering? (For example I'm using an unmodified Sega Mega Drive 2, following the logic in this thread I should have no LPF and see visual noise, but as far as I can tell there is none)
* Does the "have at 1 LPF in chain" rule apply to all retro consoles with analog output (especially regarding N64, SNES, SMD2, PS2)?
Last edited by RaphM on Mon Sep 04, 2017 1:25 pm, edited 5 times in total.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
It seems to me that the LPF in the N64RGB board is enabled by default. Based on the datasheet http://www.ti.com/lit/ds/symlink/ths7374.pdf, pin 9 on the THS7374 is the LPF bypass pin which needs to be pulled high to turn off the LPF.RaphM wrote: * Is there a source for the "N64RGB has LPF active" claim? (http://etim.net.au/n64rgb/ does not really mention this)
But if you look at the PCB picture,
https://imgur.com/a/6VM49
Seems like pin9 is grounded by default meaning the LPF is turned on. Shorting J4 will disable the LPF. I also confirmed this on my N64RGB board, but it's a 2015 board so I'm not sure if anything changed.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
If you want to bypass the LPF (thus deactivate it) on N64RGB, just short J4, like Woozle said.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Got rid of the purple line issue I was having (it was my switcher, switched to a Crosspoint), but I'm still getting the vertical lines on my CRT. I really want to know why this is happening since it's analog and what I can do to solve it.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
UPDATE: I was trying to solve a gscartsw compatibility issue today with borti's awesome 7374 rgb amp in a snes jr (problem was ebay lady putting 175ohm resistor on csync instead of 330!)
... and ... jailbars ads gone from XRGB with LPF off!! the problem is not lack of LPF! the problem was the scart cable! So if you have jailbars in output, check the csync. It should have 330 ohm resistor!
... and ... jailbars ads gone from XRGB with LPF off!! the problem is not lack of LPF! the problem was the scart cable! So if you have jailbars in output, check the csync. It should have 330 ohm resistor!
Re: THS7374 vs THS7314 + 1 chip brightness fixing
Weird. Didn't think csync voltage would affect jail bars like that.leonk wrote:UPDATE: I was trying to solve a gscartsw compatibility issue today with borti's awesome 7374 rgb amp in a snes jr (problem was ebay lady putting 175ohm resistor on csync instead of 330!)
... and ... jailbars ads gone from XRGB with LPF off!! the problem is not lack of LPF! the problem was the scart cable! So if you have jailbars in output, check the csync. It should have 330 ohm resistor!
Re: THS7374 vs THS7314 + 1 chip brightness fixing
I make all my own cables out of Monoprice SVGA cabling (RGB are mini coax, but sync and audio are shielded from the outside and from RGB, but not from each other). I put the 330 Ohm resistor back when I was using SCART, and I still had jailbars. Now I'm using a Crosspoint which accepts TTL sync, so I put nothing on the line, but on the output I have a 470 Ohm resistor to drop it down to proper levels. I still have jailbars.
I have also tried using Luma as sync and nothing changed.
If it is sync interfering with the other signals somehow, then I wonder if putting a sync stripper on the CSync line (at the console end) would fix it. I don't think it is though.
Also from what I can tell, retro_console_accessories only shields each signal from each other if you upgrade to the expensive mini coax cables, otherwise the cable is only shielded from outside interference.
Perhaps buffering CSync with a capacitor is necessary like it is on the Saturn model 2. I know on my modded SNES Mini, I connected a wire directly from the S-RGB to pin 3 to get TTL sync output, and there is zero buffering in between. I'm not sure if the original SNES had any buffering either. Maybe an engineer could chime in here.
I have also tried using Luma as sync and nothing changed.
If it is sync interfering with the other signals somehow, then I wonder if putting a sync stripper on the CSync line (at the console end) would fix it. I don't think it is though.
Also from what I can tell, retro_console_accessories only shields each signal from each other if you upgrade to the expensive mini coax cables, otherwise the cable is only shielded from outside interference.
Perhaps buffering CSync with a capacitor is necessary like it is on the Saturn model 2. I know on my modded SNES Mini, I connected a wire directly from the S-RGB to pin 3 to get TTL sync output, and there is zero buffering in between. I'm not sure if the original SNES had any buffering either. Maybe an engineer could chime in here.
Re: THS7374 vs THS7314 + 1 chip brightness fixing
All scart cables should be 8 or 9 core coaxial cable.
That way everything is shielded from everything.
That way everything is shielded from everything.