Super SD System 3

The place for all discussion on gaming hardware
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: Super SD System 3

Post by Xyga »

keropi wrote:I just saw the post on FBX's patreon page, the rgb lines on the sss3 have issues and even spill interference back to the console... wow
I don't get all the electronics stuff but after he's cut the RGB lines where does he get a complete RGB signal from ?

EDIT: implied sub-question; is this a fix anyone can apply or do you need an RGB amp/mod to take over somewhere anyway ?
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
FBX
Posts: 2347
Joined: Wed Feb 18, 2015 10:18 am
Location: DFW area, Texas
Contact:

Re: Super SD System 3

Post by FBX »

Okay so here's the deal (I'll try to make it as simple as possible)

On the V2 SSDS3, the entire video section is corrupted by high frequency EMI (noise). It is proximity-based, meaning the closer you get to areas on the board with digital signals & power regulation, the worse the noise gets. The worst offending area is the mini-DIN itself, which is surrounded by digital planes, power, and middle layers of who knows what. The 4-layer design of the board is a major factor of this noise, because ALL 4 layers must be sectioned off and away from the video side of the board (which it isn't).

As proof of concept, I tested Voultar's internal bypass mod board "V.69" in my Super Grafx with all video LPF turned off (jumper set to unfiltered and OSSC video LPF turned off). This let me see just how much high frequency noise was present in the console with the SSDS3's video pins completely removed from the expansion port. I then took jumper wires and tested the green channel on various unpopulated areas of the SSDS3's video section to show how much (if any) actual high frequency noise is being generated by the SSDS3 from proximity contamination. Below are the results of this test:

Image

Points taken from this test:

1. The left sample is with no wire connecting the console's expansion port green channel to the SSDS3. Note there is very little high frequency noise. Setting the OSSC to 9MHz LPF will cause this image to look a perfect solid green, which is why I turned LPF off in the first place so I can see the full effect of any noise introduced into the console.

2. The 2nd from the left image sample is connecting the green channel to an isolated pad on the unpopulated video section of the SSDS3. Take note of how even with the pad being completely isolated on the SSDS3, there's still enough proximity EMI from the SSDS3's 4-layer design to actually 'infect' the isolated pad.

3. The 3rd sample is taken from the pin hole that the SSDS3's female expansion socket actually feeds into. Note how because this is a through-hole via, it passes through all 4 layers of the SSDS3. As such, the proximity EMI is even worse than the isolated pad.

4. Now look at the final image sample. This is taken from the trace that leads to the green pin of the mini-DIN socket. Keep in mind there are no shorted circuits. ALL of that noise is proximity EMI, and the reason it is so strong at the mini-DIN is because that mini-DIN is surrounded by digital ground planes, power regulation, and on top of that, all of the pins of the mini-DIN go clean through all 4 layers of the SSDS3 using through-hole soldering.

So what this means is not only is the SSDS3's video output contaminated with noise due to proximity EMI, but that very same contamination will actually crawl back inside your console and corrupt any RGB bypass modding you do to circumvent the noisy output of the SSDS3. Now the OSSC does a good job of hiding this noise as I said before using Video LPF set to 9MHz. But if you're on a Framemeister or some other device, you're going to see that noise show up in your internal bypass mods.

In conclusion, my regretful suggestion is to remove at the very least, the R, G, and B pins from ever reaching the SSDS3 so your internal bypass mod is not contaminated by that EMI. I myself spent over an hour desoldering the entire socket from the SSDS3 as seen here:

Image

And then I removed the R, G, B, csync, comp video, and video ground pins before soldering the connector back onto the SSDS3. I now have clean internal RGB that is no longer contaminated by the SSDS3's EMI. Now this is a pain in the ass. So the quick (but more destructive) solution is to use flush cutters and snip the RGB pins on the SSDS3. That will be enough to keep your internal RGB lines free from contamination.

Lastly, this testing also brings bad news in that Voultar's FU-RGB board will be subject to that same contamination. The ONLY way to fix the contamination is to never allow those various video pins to ever reach the SSDS3. This also means the mini-DIN cannot be used as-is either. It must be completely removed from the SSDS3 and installed on an isolated board that has no connection to the SSDS3.
Last edited by FBX on Sat Jul 07, 2018 11:39 pm, edited 1 time in total.
User avatar
keropi
Posts: 323
Joined: Sat Sep 20, 2008 9:33 am
Location: Ioannina , Greece

Re: Super SD System 3

Post by keropi »

since we are getting the RGBS signals directly from the ppu pins aren't there some capacitors/resistors/filters to remove on the mobo so we break the connection to the expansion port that way? Maybe a better option than cutting pins? :?:
User avatar
NoAffinity
Posts: 1018
Joined: Mon May 07, 2018 5:27 pm
Location: Escondido, CA, USA

Re: Super SD System 3

Post by NoAffinity »

keropi wrote:since we are getting the RGBS signals directly from the ppu pins aren't there some capacitors/resistors/filters to remove on the mobo so we break the connection to the expansion port that way? Maybe a better option than cutting pins? :?:
If I read it correctly, there can be no connection of video circuitry between ssds3 and console or contamination will leak back via the circuitry. Hence, the reason for removing the pins at the connection between console and ssds3, in order to isolate the contamination to defunct circuitry at the ssds3.

Sent from my SM-G955U using Tapatalk
User avatar
Syntax
Posts: 1774
Joined: Wed Aug 09, 2017 12:10 am
Location: Australia

Re: Super SD System 3

Post by Syntax »

Nah cut the rgbs video pins and route the ssds3 audio back into the pce.

Told you that din sheild was cursed FBX.

What I don't get is Voultars FU-RGB magically fixed all video problems with captures where that's somewhat impossible to do with the fu-rgb.
Was it a v1 he got it working on?

So funny how I'd rather the first revision SSDS3 now, those guys wasted alot of money making this thing run worse.

Wonder who they'll blame, how they'll sweep this one under the rug...


And for those of you that don't want to cut expansion port pins or mod the ssds3 get yourself some header extensions.
https://imgur.com/yiEbEd3
User avatar
FBX
Posts: 2347
Joined: Wed Feb 18, 2015 10:18 am
Location: DFW area, Texas
Contact:

Re: Super SD System 3

Post by FBX »

Syntax wrote:
What I don't get is Voultars FU-RGB magically fixed all video problems with captures where that's somewhat impossible to do with the fu-rgb.
Was it a v1 he got it working on?
His work was on the V1 as far as I saw. And also keep in mind that if you're using an OSSC, you can actually mask and hide quite a bit of the high frequency noise using the video LPF feature. The thing is you shouldn't have to rely on the OSSC for that, and of course it's not going to be a perfect solution to begin with. The entire video section of the V2 SSDS3 is like a toxic waste area that should be avoided at all costs (i.e. doing an internal bypass mod in the console and removing those video pins from the SSDS3's connector).

In other related work, I just got done remapping the entire analog audio circuit (as I'm going to be making a complete bypass board for audio that features an additional novelty optical Toslink output for digital CD audio sound tests). I'm sure a lot of you heard I discovered the analog Vref circuit was missing a stabilizing cap, which when added, removed at least 90% of the ARM access noise. Well, in rebuilding the entire analog circuit (lots of multimeter work) I realized the only reason there was ARM access noise to begin with is the ARM's pin 100 connects to the power rail to the DAC and decouples to the analog ground plane! Meanwhile, the ARM chip's pin 99 hooks into digital ground plane! It's no wonder there was so much access noise! So I'm hoping I can get away with completely transplanting the DAC to my bypass board. It should work according to the datasheet, and I'd just pull the digital audio data and clock lines using a 0.5mm pitch 4-pin FFC flex cable.

Anyway, so that's been my project I've been working on today. As I said, just finished the schematic part, but the real fun is now routing the board and adding an FFC jack footprint to it.

-FBX
User avatar
Syntax
Posts: 1774
Joined: Wed Aug 09, 2017 12:10 am
Location: Australia

Re: Super SD System 3

Post by Syntax »

Make an all in one audio video bypass amp with an onboard din that fits the rf area and you can have my first born.
MKL
Posts: 407
Joined: Wed Feb 02, 2005 9:33 pm
Location: Pordenone, Italy

Re: Super SD System 3

Post by MKL »

If the mini-din port is the worst offender why wasn't an attempt made at replacing it with an alternative connector (DB-9 for instance) mounted on the unit's back panel? Before throwing the baby out with the bathwater it could be worth a try.
Pete2014
Posts: 7
Joined: Fri Apr 06, 2018 2:34 am

Re: Super SD System 3

Post by Pete2014 »

Nice detective work FBX, is it possible you could clarify where the expansion pin locations are for R, G, B, csync, comp video, and video ground pins.

Image

FBX wrote:Okay so here's the deal (I'll try to make it as simple as possible)

So what this means is not only is the SSDS3's video output contaminated with noise due to proximity EMI, but that very same contamination will actually crawl back inside your console and corrupt any RGB bypass modding you do to circumvent the noisy output of the SSDS3.

In conclusion, my regretful suggestion is to remove at the very least, the R, G, and B pins from ever reaching the SSDS3 so your internal bypass mod is not contaminated by that EMI.

I removed the R, G, B, csync, comp video, and video ground pins before soldering the connector back onto the SSDS3. I now have clean internal RGB that is no longer contaminated by the SSDS3's EMI. Now this is a pain in the ass. So the quick (but more destructive) solution is to use flush cutters and snip the RGB pins on the SSDS3. That will be enough to keep your internal RGB lines free from contamination.
thebigcheese
Posts: 707
Joined: Sun Aug 21, 2016 5:18 pm

Re: Super SD System 3

Post by thebigcheese »

[quote="FBX"}So the quick (but more destructive) solution is to use flush cutters and snip the RGB pins on the SSDS3. That will be enough to keep your internal RGB lines free from contamination.

Lastly, this testing also brings bad news in that Voultar's FU-RGB board will be subject to that same contamination. The ONLY way to fix the contamination is to never allow those various video pins to ever reach the SSDS3. This also means the mini-DIN cannot be used as-is either. It must be completely removed from the SSDS3 and installed on an isolated board that has no connection to the SSDS3.[/quote]

When you say it's a proximity issue, do you mean the proximity of the traces to one another? I only ask because if that is the case, there is potentially another option. You could cut the pins on the connector then solder some wires to what's left of the pins to connect Voultar's board directly to the output of the console. In this way you have created an external solution that (theoretically) has no contamination. You would also need to desolder the DIN and connect wires directly to it. Maybe put it on its side and glue it to the board to keep it in place, that way it isn't actually connected (electrically) to the SSDS3 but you can still run video etc to it. This assumes the issue is contaminated traces rather than it just being generally interference-prone inside the unit.

Wonder if a similar approach could be applied to the TG16 internals, now that I think about it. That thing is a nightmare to get clean video out of...

@Pete2014, they are the ones labelled Red, Grn, Blu, Sync, Vid, and GND :p The GNDa is analog ground, GNDd is digital ground.
User avatar
FBX
Posts: 2347
Joined: Wed Feb 18, 2015 10:18 am
Location: DFW area, Texas
Contact:

Re: Super SD System 3

Post by FBX »

Pete2014 wrote:Nice detective work FBX, is it possible you could clarify where the expansion pin locations are for R, G, B, csync, comp video, and video ground pins.

Image

It shows you right there in the image you linked, although keep in mind you're looking at the pin assignments looking into the console rather than looking at the the connector on the SSDS3. So take that image and mirror it to see how the pins line up on the SSDS3. This means the last vertical row of pins for RGB are on the left side of the SSDS3's pin connector (where the video section is of course). You'll also see pins designated in orange as "sync" and "vid", and right next to "vid" on the bottom row is a grey "GNDa". I removed all those pins too (for a total of 6 pins removed on that side). That ensured no part of the video signals of the console would ever be contaminated.

thebigcheese wrote:
When you say it's a proximity issue, do you mean the proximity of the traces to one another? I only ask because if that is the case, there is potentially another option. You could cut the pins on the connector then solder some wires to what's left of the pins to connect Voultar's board directly to the output of the console. In this way you have created an external solution that (theoretically) has no contamination. You would also need to desolder the DIN and connect wires directly to it. Maybe put it on its side and glue it to the board to keep it in place, that way it isn't actually connected (electrically) to the SSDS3 but you can still run video etc to it. This assumes the issue is contaminated traces rather than it just being generally interference-prone inside the unit.
Mobiusstriptech is working on such a solution. It lightens my work load so I can focus on the audio. We'd discussed making it an all-in-one bypass solution, but we wanted to see how our two projects end up working out first. And yes you could isolate the pins directly into Voultar's board and desolder the DIN and isolate it from the SSDS3, but you're looking at a major project when you consider wiring in audio as well. You're sort of back to needing the bypass board I'm working on. So who knows, it might end up being a single solution board ultimately. I just want to focus on audio to make sure I have it as perfect as it can get.
Last edited by FBX on Fri Jul 06, 2018 4:02 am, edited 2 times in total.
SavagePencil
Posts: 628
Joined: Mon Nov 11, 2013 4:06 pm

Re: Super SD System 3

Post by SavagePencil »

Have you heard anything from the TO team about your findings? Seems like something they will be keen about discussing when they get back from vacation.
User avatar
FBX
Posts: 2347
Joined: Wed Feb 18, 2015 10:18 am
Location: DFW area, Texas
Contact:

Re: Super SD System 3

Post by FBX »

SavagePencil wrote:Have you heard anything from the TO team about your findings? Seems like something they will be keen about discussing when they get back from vacation.
I don't want to bother them about the video stuff. They seemed pretty adamant that they didn't want to fool with analog video problems any more, and there's a good chance they may be moving in the direction of 720p digital video output down the road on a 'pro' version of this board. Not saying it will happen any time soon if it does of course.
Pete2014
Posts: 7
Joined: Fri Apr 06, 2018 2:34 am

Re: Super SD System 3

Post by Pete2014 »

FBX and Bigcheese, thanks. just wanted to make 100% sure.

I think I will buy some extension header pins tomorrow, I really don't want to desolder or cut anything.
User avatar
FBX
Posts: 2347
Joined: Wed Feb 18, 2015 10:18 am
Location: DFW area, Texas
Contact:

Re: Super SD System 3

Post by FBX »

Pete2014 wrote:
I think I will buy some extension header pins tomorrow, I really don't want to desolder or cut anything.
Good idea actually. If you can get it to work out without too much fuss or stress on the connector, that would be the best solution.
User avatar
cr4zymanz0r
Posts: 356
Joined: Sat Oct 19, 2013 6:36 am

Re: Super SD System 3

Post by cr4zymanz0r »

So I tried to replicate FBX's work on the video circuit to clean up the video signal on my PC-Engine when using the SSDS3. Like him I've got a Voultar PCE RGB amp in my PC-Engine, but mine is a Core Grafx rather than a Super Grafx like FBX has (seems like people with a Super Grafx are having better luck with video quality in general). I've also been turning off the video low pass filter (LPF) on the OSSC to see just how much noise is being introduced.

I got in my hot air station today and removed the video components from the SSDS3 and there was little or no visual difference, as expected basically. Next I was going to clip the video pins, but I can't get to all of them while the expansion connector is still attached to the SSDS3. I was able to clip RGB and csync however, so those pins never make it to the SSDS3. However, I can still see interference added by the SSDS3 even when loading hucard games from the SSDS3. This interference is far reduced (and not even the same pattern) when loading a real hucard.

All that's left for me to cut/disconnect is composite video A22 and analog video ground A21. To do this I'll have to pretty much desolder the expansion connector. Before I do this, I have some questions about analog video ground that I'm hoping FBX or someone can answer.

(Note, I am getting RGB from the PCE DIN port, and audio from the SSDS3 mini-DIN port)
So when I was checking things with a multimeter on the SSDS3, it appears only analog video ground (A21) is connected to the SSDS3's mini-DIN. Analog audio ground (A2) was not connected to the mini-DIN. If I disconnect A21, will that not cause some audio issues or at least make the audio cable shielding worse since the mini-DIN's ground would effectively be floating? I know eventually that the mini-DIN would need to be removed and remounted in a way that it's not connected to the SSDS3 in the future if I were to ever put a RGB amp in the SSDS3, but I was hoping to avoid that for now if possible while I'm just getting the video perfect and waiting for a thorough audio solution.
User avatar
FBX
Posts: 2347
Joined: Wed Feb 18, 2015 10:18 am
Location: DFW area, Texas
Contact:

Re: Super SD System 3

Post by FBX »

cr4zymanz0r wrote:
(Note, I am getting RGB from the PCE DIN port, and audio from the SSDS3 mini-DIN port)
So when I was checking things with a multimeter on the SSDS3, it appears only analog video ground (A21) is connected to the SSDS3's mini-DIN. Analog audio ground (A2) was not connected to the mini-DIN. If I disconnect A21, will that not cause some audio issues or at least make the audio cable shielding worse since the mini-DIN's ground would effectively be floating? I know eventually that the mini-DIN would need to be removed and remounted in a way that it's not connected to the SSDS3 in the future if I were to ever put a RGB amp in the SSDS3, but I was hoping to avoid that for now if possible while I'm just getting the video perfect and waiting for a thorough audio solution.

Yes, the audio ground plane never connects to the mini-DIN. In my case since I'm using an analog line amp bypass board hooked into the sound-side grounding pin, I don't use the mini-DIN at all, and this allowed me to get away with removing the video ground plane. My bypass board passes analog audio ground itself so I can hook up audio and completely ignore the video section and contaminated mini-DIN socket. However, I'm working on a new bypass board that relocates the entire analog circuit (includes mixing components and the DAC) to my board such that I can disconnect the analog audio ground plane on the SSDS3 as well. The new board will also have a Toslink output jack for listening to CD audio content in full digital sound.
User avatar
cr4zymanz0r
Posts: 356
Joined: Sat Oct 19, 2013 6:36 am

Re: Super SD System 3

Post by cr4zymanz0r »

Well, I got impatient :P. I desoldered the mini-DIN and expansion connector on the SSDS3, clipped composite video and analog video ground, glued the mini-DIN back in place on it's side with a piece of electrical tape between it and the PCB so ground would not reconnect, reconnected audio, and connected analog audio ground to the mini-DIN........ and it didn't really seem to do anything :\ (I also tested before putting the mini-DIN back in and it was the same).

I'm wondering if the Super Grafx just has more filtering or something inside the console. I recorded a video, but the recording plus youtube transcoding softened the noise effect some, but it's still visible. https://www.youtube.com/watch?v=Kmyds4gSsLc . When playing a game on the SSDS3 with the OSSC LPF disabled, there's 'digital looking snow', kinda like the 'snow' of a old bad antenna signal on an old tv. There's also some diagonal lines going across the screen at different speeds.

First game loaded is direct from hucard. The other ones are from the SSDS3. The LPF on the OSSC is off most of the time, but I turn it on for a couple of seconds twice or so (I was going to add annotations to the youtube video specifying where, but didn't realize they've discontinued the ability to do that).
User avatar
FBX
Posts: 2347
Joined: Wed Feb 18, 2015 10:18 am
Location: DFW area, Texas
Contact:

Re: Super SD System 3

Post by FBX »

Voultar gave me some suggestions on connecting 5V to ground with some 4.7uF caps, so I'm going to give that a try. His board might actually work quite nicely as a bypass, and maybe I'm jumping the gun too soon with my assumptions that the SSDS3 video section cannot be saved. I'll report back with results.
User avatar
FBX
Posts: 2347
Joined: Wed Feb 18, 2015 10:18 am
Location: DFW area, Texas
Contact:

Re: Super SD System 3

Post by FBX »

Damn, the 4.7uf caps didn't work out. Gonna get the FU_RGB board and give it a try anyway. If it turns out it works fine with 9MHz video LPF on the OSSC, then it shouldn't matter about the noise and I can go back to working on the audio board. I'll post lossless pic comparisons between the FU board and Voultar's internal V.69 board with the pins removed, and both with and without OSSC video LPF for posterity when everything arrives.
User avatar
Kez
Posts: 818
Joined: Thu Jul 20, 2017 7:09 am

Re: Super SD System 3

Post by Kez »

Not a big deal, but I'm not really a fan of having an empty HuCard slot with the SSDS3. It just doesn't look right.

I designed a 3D model of a dummy HuCard to slap an SSDS3 logo on.

Image

I can't upload it to thingiverse just yet as I only just created an account, but if there is interest I will make sure it gets up there as soon as I'm allowed to submit stuff.
User avatar
opt2not
Posts: 1283
Joined: Fri May 20, 2011 6:31 pm
Location: Southern California

Re: Super SD System 3

Post by opt2not »

Kez wrote:Not a big deal, but I'm not really a fan of having an empty HuCard slot with the SSDS3. It just doesn't look right.

I designed a 3D model of a dummy HuCard to slap an SSDS3 logo on.

Image

I can't upload it to thingiverse just yet as I only just created an account, but if there is interest I will make sure it gets up there as soon as I'm allowed to submit stuff.
That's looking sweet! I'd be interested if you can upload the model online.

You should post this in the Terraonion forum, I'm sure a lot of people would also be interested in getting the model as well.
User avatar
Kez
Posts: 818
Joined: Thu Jul 20, 2017 7:09 am

Re: Super SD System 3

Post by Kez »

opt2not wrote:That's looking sweet! I'd be interested if you can upload the model online.

You should post this in the Terraonion forum, I'm sure a lot of people would also be interested in getting the model as well.
Thanks, I've published it now. It has a 50x40mm raised bed that I've put the sticker on. I also tried to replicate the grip arrow thing on the base of HuCards but it didn't come out great in my print (got it made online - I don't have a 3D printer). Might look better with a higher print resolution or maybe printed sideways.

https://www.thingiverse.com/thing:2998019

I'll post on TO at some point.
User avatar
waiwainl
Posts: 464
Joined: Tue Jun 24, 2014 9:23 am
Location: Netherlands

Re: Super SD System 3

Post by waiwainl »

Kez wrote:Not a big deal, but I'm not really a fan of having an empty HuCard slot with the SSDS3. It just doesn't look right.

I designed a 3D model of a dummy HuCard to slap an SSDS3 logo on.

Image
That is a pretty Cool idea!! Thanks for uploading the design.
Visit: https://shmu.ps
Experience the National Video Game Museum in the Netherlands
User avatar
NoAffinity
Posts: 1018
Joined: Mon May 07, 2018 5:27 pm
Location: Escondido, CA, USA

Re: Super SD System 3

Post by NoAffinity »

FBX wrote:Damn, the 4.7uf caps didn't work out. Gonna get the FU_RGB board and give it a try anyway. If it turns out it works fine with 9MHz video LPF on the OSSC, then it shouldn't matter about the noise and I can go back to working on the audio board. I'll post lossless pic comparisons between the FU board and Voultar's internal V.69 board with the pins removed, and both with and without OSSC video LPF for posterity when everything arrives.
Hey FBX, any luck with your additional testing? :)

Just another independent data point, confirming that simply doing a bypass within the SSDS3 will not improve things. I disabled the internal RGB circuits, within the SSDS3, and soldered to the existing pins at pass-thru connector and at multi a/v out. No improvement to the interference/noise, and in fact the image was a bit darker than unmodded SSDS3 output. Probably a shortcoming of this RGB amp. It was inexpensive, and I got it to do a bypass within my Core Grafx 2, but thought I'd give this configuration (represented below) a quick try.

This humble tinkerer is looking forward to a solid solution from the experts. :)

Image

R13, R14, R16, C12, C17 and C15 lifted
Image
User avatar
FBX
Posts: 2347
Joined: Wed Feb 18, 2015 10:18 am
Location: DFW area, Texas
Contact:

Re: Super SD System 3

Post by FBX »

NoAffinity wrote:
FBX wrote:Damn, the 4.7uf caps didn't work out. Gonna get the FU_RGB board and give it a try anyway. If it turns out it works fine with 9MHz video LPF on the OSSC, then it shouldn't matter about the noise and I can go back to working on the audio board. I'll post lossless pic comparisons between the FU board and Voultar's internal V.69 board with the pins removed, and both with and without OSSC video LPF for posterity when everything arrives.
Hey FBX, any luck with your additional testing? :)

Just another independent data point, confirming that simply doing a bypass within the SSDS3 will not improve things. I disabled the internal RGB circuits, within the SSDS3, and soldered to the existing pins at pass-thru connector and at multi a/v out. No improvement to the interference/noise, and in fact the image was a bit darker than unmodded SSDS3 output. Probably a shortcoming of this RGB amp. It was inexpensive, and I got it to do a bypass within my Core Grafx 2, but thought I'd give this configuration (represented below) a quick try.

This humble tinkerer is looking forward to a solid solution from the experts. :)

Image

R13, R14, R16, C12, C17 and C15 lifted
Image
Ben Fong was getting fantastic results using Voultar's FU-RGB bypass board, and he took snaps that look pretty darn good (although from a TV screen running with the Framemeister). He's sent me a spare FU-RGB board so I can do lossless screencaps and scope plots compared to Voular's internal V.69 bypass board on my Super Grafx. So having both the lossless screencaps at the scope plots will satisfy the scrutiny of both nerds and general fans of the consoles.

I will say that if the FU-RGB board does pass these inspections on my end, then I'd totally recommend it. I'm just a little skeptical because of how much noise I pick up on my internal bypass mod by even touching the unpopulated video section of the SSDS3. The hope is the FU-RGB board is somehow filtering out all that noise, bu we'll see when it arrives. While photos of a TV screen hint at success, I don't want to 'think' it passes visual inspection, I want to KNOW it does. So I'm reserving judgement until the board arrives, which should be any day now.
User avatar
Fudoh
Posts: 13015
Joined: Mon Mar 06, 2006 3:29 am
Location: Germany
Contact:

Re: Super SD System 3

Post by Fudoh »

So I'm reserving judgement until the board arrives, which should be any day now.
very much looking forward to it! Thanks for the effort!
User avatar
NoAffinity
Posts: 1018
Joined: Mon May 07, 2018 5:27 pm
Location: Escondido, CA, USA

Re: Super SD System 3

Post by NoAffinity »

Yes, anxiously awaiting here as well. I've got all the components for the FU-RGB, except the bare board itself, which shipped on Friday. So, hoping to be able to do some "shotgun" testing in parallel with your efforts as well. Admittedly, I don't have a scope or would even know how to use it, but I'm prepared to lift pins, isolate the FU-RGB within the SSDS3...basically follow the lead of others to satisfy my OCD. :)

But, pixel perfection aside, the SSDS3 is a pretty cool device. Yesterday was the first time I really sat down and gave it some play time. The interference is noticeable if you're looking for it, but if you're focused in-game, you don't really notice it. I played through some Castlevania Rondo, Blazing Lasers, SF2 Champion Edition. All play flawlessly. 8)
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: Super SD System 3

Post by Xyga »

NoAffinity wrote:FU-RGB
What a name for a board meant to solve an RGB signal issue tho...
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
NoAffinity
Posts: 1018
Joined: Mon May 07, 2018 5:27 pm
Location: Escondido, CA, USA

Re: Super SD System 3

Post by NoAffinity »

Xyga wrote:
NoAffinity wrote:FU-RGB
What a name for a board meant to solve an RGB signal issue tho...
I always assumed the naming was completely intentional. :lol:

Some more observations here, from moving the RGB amp into the Core Grafx 2. Possibly all things that are already known, but I'll offer it any way. :)

With the RGB amp in the CG2, the image produced from this amp is dimmer, however, it seems less noisy. I am able to use FBX's optimization and get a more stable image - which is to say, less "shimmer" or waviness with OSSC sampling phase set to the best possible result - 202 or 213.

I'm not discounting that the Genesis 1 cable that I'm using with this CG2 internal mod is not adversely influencing the results - it is a lower end cable...but does correctly have 75 ohm resistors at the console end and 220uf caps at the SCART end. I also do not have audio routing through it currently, this is strictly a video test. On the same token, I was also noticing the image was dimmer, with this RGB bypass board installed in the SSDS3, also.

This is the RGB amp I'm using, if anyone knows anything about them (good or bad): https://www.ebay.com/itm/PC-Engine-RGB- ... 2749.l2649

Anway, just some observations while I prep and wait to be able to test the FU-RGB.
Post Reply