"Fixing" SNES for OSSC

[Sumez]

Ever since I've gotten my OSSC I've had a problem with both of my SNES consoles, where the picture (and sound) would occasionally black out for a second or two. Rarely, but often enough to be annoying (and completely unacceptable during any action game), with the frequency usually increasing the longer you've been playing. Obviously, on CRTs, nothing visibly happens at all.

Surprisingly I've found very little documentation of this issue. But that fact that it happens on two different cables and two different SNES consoles (a 2-chip PAL, and an RGB modded US SNES Jr) clearly tells me it's an artifact of the SNES rather than an issue unique to my stuff.

I've speculated two likely sources, one being getting the sync from composite video, and the other being just the quality of the video cables overall being low.
The only documentation of the issue I've been able to find is this thread, which speculates that the source is the former: https://videogameperfection.com/forums/ ... sync-drop/
EDIT: I forgot to mention, a third explanation might be needing a dejitter mod, but the issues I've seen discussed where people recommend this doesn't sound similar to what I'm experiencing. I'm not getting this behavior from my NES consoles either.

So assuming I need to get CSYNC to fix the issue, that's easy for the NTSC SNES. I already hooked a csync line to pin 3 of the AV out, and just need a compatible cable.
For the PAL console however, that's a bigger issue. The csync pin is instead used for 12v on all PAL consoles.
The typical approach I see is to use the Luma signal for sync. Whether this is good enough to fix the issue with OSSC is unclear to me however, and I'm worrying whether I'd get any better results this way.

I could make my own cable, but the SNES uses a proprietary standard, and unfortunately you won't find any Multi AV cables out there with every pin wired, so a regular RGB cable won't have the Luma pin. People have made PAL RGB cables using luma for sync however, so if it works that should be able to fix it (I can't find any sellers within EU though, so that's another issue, but not relevant right now).
That said, I'm a bit obnoxious about these things, and would really like to use the same cable for both consoles, so even better would be if I could get the sync signal on Pin 3, making it compatible with NTSC style RGB cables. Of course, that would require me to disconnect the 12V line on pin 3, so I'm curious if anyone here has any experience doing this, or any good ideas?

The connector is soldered directly to the PCB, so I need the pin that goes through there. If there's another pin I can lift somewhere to break the connection, that would be perfect
The schematic I can find just draws it as connected to "+12v", and to ground via a small capacitor at C46 (small SMD cap), so I'm not sure where to look, and if it's even feasible. The entire underside is covered by a solid brown layer, which makes it very inconvenient to try to break any traces.

Also, if I could do this, wouldn't I also be able to just take the CSYNC signal from pin 100 on S-PPU2 and use that instead of luma?
Sorry for asking stupid questions.

[Konsolkongen]

You can cut the pin on the AV out on the top side of the board and bend that upwards to disconnect 12V.

I would just install the dejitter mod to be sure. Csync or not I was not able to get a stable image with my SNES through my OSSC before I did the dejitter.

How old is your NESRGB? Dejitter has been built in for a while now, and you can even install a custom firmware in the older boards that adds dejitter, but looses the palette switch (no loss really).

[Sumez]

You can cut the pin on the AV out on the top side of the board and bend that upwards to disconnect 12V.

I'm not really seeing any way to do that without desoldering the whole thing (and taping over the 12v connection to be sure)? Remember I still need the pin for the sync. Sounds like a cumbersome operation if there's a different place to break the connection.

I've made a few different NESRGB installations, and ordered kits in 2014, 2015, and 2019, pretty sure at least one of the ones I've been using on my OSSC was the 2014 one.

I'd like a dejitter some time, but it's an expensive project to implement on two different consoles if it turns out to not be the source of the problem. I'm not sure you can even get kits right now? I also seem to recall hearing something about it not working on PAL consoles (not sure about PAL in 60hz mode).

[Konsolkongen]

You can get at it with small sidecutters. It's very straight forward and easy.

Just cover the wire you solder to the pin with some heat-shrink.

Dejitter works fine in my PAL 1CHIP. I only play 60Hz games.

[Sumez]

Is it lifted from the PCB? I haven't had the PAL console opened recently, but on the SNES Jr. I just worked with, the AV connector is soldered completely flat on to the PCB, so there's no getting to the pins from the top side.
If that's not the case, it should make things a lot easier.

[Konsolkongen]

The back row of pins on my 1chip are exposed and easily cuttable. Maybe the connector is slightly different on the jr.

[DiegoPonga]

Hi, I am having a similar error as well:

PAL SNES
SuperCIC mod
OSSC v1.6
gscartsw v3.4
SNES RGB SCART cable SYNC on LUMA for PAL console (by RetroGamingCables)

Both audio and sync seem to be randomly and suddenly lost for just a sec. But it is constant, can happen some 5-7 times per minute. Can get really irritating and makes my console unplayable.

I'd say however my console is NOT a CHIP1 model. And the SuperCIC mod looks super clean. Can anyone give me a solution?

The problem appears on 60 Hz mode only. But still, pretty annoying.

Thanks a lot guys.

[Sumez]

I guess that just fuels the idea that it's caused by the console's "jitter feature", or at least that luma sync doesn't help it.
Sounds like yours are more severe than what I'm seeing though.

[DiegoPonga]

I guess that just fuels the idea that it's caused by the console's "jitter feature", or at least that luma sync doesn't help it.
Sounds like yours are more severe than what I'm seeing though.

I guess it's also because of my TV, which fits what I've read on the internet. I used a different TV and it worked flowlessly.

I think the best solution is using a dejitter mod.

[Konsolkongen]

Sumez> If you’re installing the dejitter mod you could just cut the trace to pin 9 and run the dejitter boards csync to that. That’s what I did in the end. I’m never using composhite ever again, and doing it this way I can just use standard RGB cables not having to worry about 12V.

[Sumez]

Yeah, I considered that as well, but it leaves me the same issue as doing it with pin 3. The traces on a SNES PCB aren't very obvious.
If you're right though, it's not so difficult to lift the pins from the AV connector as I assumed.

[NewSchoolBoxer]

I was in a Reddit thread about a device chain of SNES RGB -> Rad-2X -> HDMI over YCbCr would black out the screen when it gets too bright. Happens on both their consoles and I assume stock NTSC. Forcing composite input into Rad-2X worked fine. Logically then, is a problem with too much luma information being packed on the Y wire, the same Y wire you're saying PAL cables use as sync. In theory would still happen using composite video as sync (CVBS). I believe the ADC encoding of Y in the 2X or OSSC is the point of impact. Both might even be using the same chip.

Are the black outs actually random-ish or can you get a really bright screen on Super Mario World, Yoshi's Island or a Kirby game and have a greater chance of triggering it? Csync mod seems like a good fix and needed anyway if you're ever going to run RGBS into an RGB capture card.

That doesn't explain audio cutting out though. One thing that seems novel in retro gaming is using a ground loop isolator. Meant for audio to remove 50/60 Hz hum. Since you're losing audio too, I'd unplug L and R RCA connectors to the console and see if black outs still happen. If so, an isolator is cheap and worth a try.

It's hard coming up with a reason why a +12V DC signal would mess with another line. DC doesn't induce a signal in neighboring wires like AC does. It has no frequency response. If the DC is itself jittery and nowhere near a stable +12V then that's different. I guess the heat from it would matter if the current is high. Some multimeters come with temperature sensors. I'd be concerned if temperature near SNES multiout or OSSC input approaches 85°C.

[Sumez]

Are the black outs actually random-ish

Basically completely random. There's no real rhyme or reason to them, and definitely no relation to the picture being output at the time. I want to say I can some times play for ages without them showing up, and then later on they'll become frequent enough to be really annoying. But even that isn't consistent.

That doesn't explain audio cutting out though. One thing that seems novel in retro gaming is using a ground loop isolator. Meant for audio to remove 50/60 Hz hum. Since you're losing audio too, I'd unplug L and R RCA connectors to the console and see if black outs still happen. If so, an isolator is cheap and worth a try.

Not sure what audio RCA connectors you're referring to, those don't exist on neither a SNES nor an OSSC
But I'm pretty sure the audio cutting out is just an effect of the OSSC (or the TV?) losing sync. I'm assuming this is an issue that only happens for a really tiny splitsecond, but the visible blackout (along with the audio being gone) is caused by the OSSC tuning back into the sync signal. The same thing happens consistently on any console whenever they change video modes, or on some consoles during forced blank periods between screen.

It's hard coming up with a reason why a +12V DC signal would mess with another line.

No, that's pretty clear. It's because the line dedicated for csync on an NTSC SNES's pinout is dedicated to +12V on a PAL one
I wouldn't want to try connecting both at the same time.

[NewSchoolBoxer]

Trying to actually contribute here. I assume you're using composite as sync on the PAL console and don't have crap or 25 year old analog cables without checking the RGB capacitors. Other idea is make the signal as high quality as you can. Don't have power cable or surge protector or internet router or microwave nearby anything in the chain. Separate audio from video cables as best you can. Any bends in a cable slightly increase the resistance. Is like a bend in a pipe that water flows through. More pressure on the inside corners. So make as straight as possible. If you live in an apartment, maybe even move all your equipment to the middle to be insulated from EMI from your neighbors.

Not sure what audio RCA connectors you're referring to, those don't exist on neither a SNES nor an OSSC
But I'm pretty sure the audio cutting out is just an effect of the OSSC (or the TV?) losing sync. I'm assuming this is an issue that only happens for a really tiny splitsecond, but the visible blackout (along with the audio being gone) is caused by the OSSC tuning back into the sync signal. The same thing happens consistently on any console whenever they change video modes, or on some consoles during forced blank periods between screen.

Oh yeah, I was messing with computer cables the past few days and merged the pinouts together. I don't have an upscaler myself but sync information isn't encoded in audio so seemed strange to me to be affected. That said, device OSSC set up so that if video cuts out then audio follows suit does make some sense. I knew upscalers have some delay on resolution change and that is similar logic to losing sync for a brief moment.

It's hard coming up with a reason why a +12V DC signal would mess with another line.

No, that's pretty clear. It's because the line dedicated for csync on an NTSC SNES's pinout is dedicated to +12V on a PAL one
I wouldn't want to try connecting both at the same time.

I get that it seems convenient to take the +12V pin for yourself and run csync on it. I would just rely on OSSC's sync stripper to keep SNES stock and avoid messing with its composite or S-Video ability. Stock is easy to re-sell. I thought PAL used the +12V to tell the television to display 4:3 instead of 16:9.

Actually, I read through the full message board link this time. One user says sync stripper method de-syncs on 1-CHIP and has specific Analog sync Vth level for others. I looked up what that was:

Sets the sync slicer threshold. May help with dropouts as the last resort - sync LPF and coast settings should be tested through first.

0-350mV: threshold voltage. [default=124mV]

So the threshold means it caps sync to that maximum value and is the amplitude and not Vp-p? Too bad OSSC doesn't do 5V TTL sync over SCART despite it being the native NTSC SNES output but I'm sure you knew that. I think the most standard "low voltage sync" is 300mV based on Extron and PVM manuals so the 124mV surprises me. Up that if you haven't tried. I don't know OSSC specifics but if you can turn all LPFs off, it's worth a try. Reasoning is chips add an ever so slight delay between video and sync lines.

Obviously the rough part about this is if everyone's SNES de-synced on OSSC, there'd be 10000x more posts about it. I just have to speculate but we've read about 1-CHIP sync issues and there are good mods and there are bad mods.

[Sumez]

Obviously the rough part about this is if everyone's SNES de-synced on OSSC, there'd be 10000x more posts about it. I just have to speculate but we've read about 1-CHIP sync issues and there are good mods and there are bad mods.

Yeah, that's actually what confuses me the most!
It happens on two different cables across two different SNES consoles, so it's kinda weird.

It's hard to find really high quality SNES RGB cables though, but since the last time I searched, some solder-able Nintendo AV connectors have actually surfaced from a German seller, so I bought a few of those, and I'm gonna try making better cables when I get them.

Maybe I should also consider actually upgrading my OSSC firmware. I'm just kinda afraid of losing my presets.

[Konsolkongen]

A lot of people have problems with SNES and the OSSC. But in reality it seems to be more of an issue with your TV not liking what the OSSC feeds it. They actually made a SNES compatibility column in this forum post:
https://videogameperfection.com/forums/ ... atibility/

On my LG C8 I had a fairly stable image using 3x scale. 4x and 5x was dropping out like crazy, but works with every other system I own. Dejitter mod fixed it. Just do that

[Sumez]

Interesting, maybe I should try out different scaling modes. Not sure more than one of them even works on my (LG) TV though.
It's such a hard thing to test, too, since you can some times play for like an hour without getting any issues, even if nothing has changed (which feeds the theory that it relates to signal quality, not snes jitter)

Just do that

[Konsolkongen]

I seriously doubt you will gain anything from building a new cable. Like I said, csync made no difference for me. The dropouts were also very random for me when I had the issue. Everyone suggests the dejitter mod for this exact reason. You already have been given the solution to your problem.

It’s a shame the mod is out of stock on VGP so I guess you’ll just have to be patient and wait until they get them back in stock.

[Harrumph]

Just get a luma-sync cable from RGC (UK based) and be done with it.
In fact it’s also the conclusion of that thread you linked so I’m not sure what you’re on about.
This whole idea of messing with the pin-out seems ill advised, just a hassle for no gain really.

[Konsolkongen]

I’m on about how to stop sync drop out on the OSSC. If Csync doesn’t help neither will luma as sync… I am speaking from personal experience. But whatevs… :/

[NewSchoolBoxer]

I'm getting invested in this discussion. I want truth and justice.

The Reddit thread had a happy ending. Turns out they were using PAL SCART cable on NTSC SNES. Issue is NTSC puts 75 ohm resistor in console and PAL in the cable, causing a big impedance mismatch. Power loss and reflected interference gets worse the higher the frequency and/or amplitude so makes sense that too bright a screen would cause a de-sync. You know is 75 ohms if color bars from outside in go purple, green, black. Discussion: https://gbatemp.net/threads/need-help-w ... le.539101/

Obviously we got stock NTSC and RGB modded PAL here but checking for resistor in the sync cables should be done if SCART end is twist + snap. Hopefully same cable isn't used for both.

Konsolkongen brings up good point about possibility of TV itself being incompatible. I was aware of the marqs dejitter mod and used that link before to show OSSC seemingly high incompatibility and counter argument was chart is outdated and have been firmware updates. I don't know the truth. I've seen plenty of dejitter mod discussion on NES. On eBay there is marqs selling SNES dejitter + install service in US and one seller in England. Isn't sync jitter only a thing on 60 Hz so not PAL unless 60 Hz modded? Is what UK seller says mod is for.

Yeah if you aren't ever going to an RGB capture card that needs csync, luma sync is fine. I think paying $10 extra for a sync stripper in the PAL cable is a hustle. If luma is messing with the sync, sync is already going to be dirty before it's separated from luma by the chip. Maybe digital transcoder does better with csync than luma as sync but it's going to have to generate a digital Y signal regardless.

[Harrumph]

I’m on about how to stop sync drop out on the OSSC. If Csync doesn’t help neither will luma as sync… I am speaking from personal experience. But whatevs… :/

I didn’t include a quote, so I guess it was unclear, I was adressing Sumez.
And even then my intent was not to be snarky.

[Konsolkongen]

Fair enough

[Sumez]

I trust Konsolkongen on this subject, but as long as I don't really have the option of dejitter (let alone on two consoles), I'm gonna experiment a bit more with the options I do have right now.

[Sumez]

Made a cable using the clean csync line from the NTSC SNES Jr. and as Konsolkongen promised, it regrettably did nothing to change the issue. It was of course expected, but it's nice to at least rule out a few factors, since different people have made different claims.

While the NES and SNES's jitter features are definitely an off-spec annoyance, I also think "requiring" dejitter is frustrating as well. Whenever the sync drop doesn't happen, I'm still getting what to me at least is a fantastic and crazy sharp picture from both consoles. So while I guess you can't expect it to specifically handle edge cases, I do think the OSSC not being able to deal with a stock SNES is honestly a pretty big strike against it, and I'm a little curious if it would be possible to add in a feature to somehow handle it via firmware.

Another "odd" thing is that even with a clean sync signal lifted directly from the PPU, the OSSC didn't want to recognize the sync via the VGA input. But if I ran the signal via an adapter into the SCART input (no sync seperator circuit in it), it worked fine. Not sure why that makes a difference for the OSSC, but I do know the signals are handled differently between the two ports, which is also kinda confusing.

I'm guessing that can be fixed by recreating the circuit normally found in a SNES with RGB output? Or maybe it's just the sync signal being weird in other ways?

Sigh :\

[maxtherabbit]

Not possible, it would require buffering which the original OSSC cannot do.

The OSSC isn't the only device that can't handle the jitter FWIW, my Datapath VisionAV didn't work to capture my SNES until I dejitter modded it.

[Sumez]

Is buffering really necessary? I wouldn't mind the picture dropping out for just one frame, but a whole second or two sounds like a design problem to me moreso than a slight issue with the signal.


EDIT: Did some more research on the Dejitter mod, and although the documentation for it is a little jumbled (the installation guide linked on the store page is incredibly specific to just one pcb/installation type, I had to peruse the docs on github and get a little more information from some of the issues posted there, to understand the exact nature of each connection), it seems like a super easy installation, and not as intrusive as I first thought it was.

If only it was possible to actually get my hands on one. Konsolkongen, you wouldn't happen to have a couple of extra kits lying around I could buy from you? :\

[Konsolkongen]

Sorry I don’t have any. Would have offered you one if I did

[Guspaz]

Is buffering really necessary? I wouldn't mind the picture dropping out for just one frame, but a whole second or two sounds like a design problem to me moreso than a slight issue with the signal.

The image dropping out for 1-2 seconds is probably happening on your TV, not the OSSC. Even if the OSSC briefly loses sync, TVs typically take some time to resync.

[Sumez]

[
The image dropping out for 1-2 seconds is probably happening on your TV, not the OSSC. Even if the OSSC briefly loses sync, TVs typically take some time to resync.

Interesting. Are there any settings that can usually combat that? I got a new TV pretty recently, and specifically went for one that I figured would be good for OSSC, but that really just sounds dumb.

Also, if OSSC briefly loses sync, is there anything that prevents it from just going on a frame or two with a potentially jumbled picture (or, more likely, just a completely black one, in the case of forced blanking between scenes on certain consoles), rather than just immediately "giving" up, and telling the TV there's no signal now?