Question about SNES sync drop

Viewing 15 posts - 1 through 15 (of 21 total)
  • Author
  • #26211


    I’ve seen that sometimes SNES are known to drop sync. But I’m not having the typical consistant drop out
    The sync drops are not often. like 1 time every 1-3hrs for a few seconds. But it’s a bit of an issue when trying to speedrun. (can invalidate run and such)

    However, I’m wondering if there is any option on the OSSC that I can adjust slightly to possibly eliminate these very ocassional sync drops?

    Would H-PLL precoast at a higher value help? also what exactly does it do, what does it affect turning it up?

    (my Scart cable also isn’t “amazing” quality either, could that cause it too?)


    To my knowledge, there’s nothing the OSSC can do; whatever sync errors it receives, it passes on.

    As for the problem itself (which happens with the NES as well), what happens is that, every other frame, the scanline preceding the first visible line gets cut short. That means that the horizontal sync pulses are not consistent, and a lot of contemporary hardware will have trouble accommodating it.

    I think you’ll either have to install a dejitter mod and then hope that doesn’t invalidate speedruns (should probably lobby for its acceptability moving forward), or you’ll need to do your speedruns on a display that can handle the SNES’s sync jitter, like a CRT, or perhaps a known-compatible plasma or LCD.


    Do you have a 1-CHIP SNES? If the OSSC itself loses sync then it could be another issue which happens with 1-CHIP SNES with Composite video or Luma sync cables.

    You can read about it here:


    I’m pretty sure this SNES is one of the earlier releases.
    It says 1991 on it, it’s very yellow, and Final Fantasy Mystic Quest debug says
    cpu ver.1
    ppu1 ver.1
    ppu2 ver.1
    I have a pretty cheap Scart cable, I have no clue which sync it’s using. I plan on getting a packapunch csync soon enough.

    I’ve seen other threads talking about adjust H-pll pre and post, and some others talking about vth might help out.
    I’d like to know what they actually do, help/hurt


    Adjusting H-pll pre and post sadly only hinders the SNES due to the jitter issue.


    And how about VTH?

    Michal Stepien

    I have similar problem. OSSC + 1chip PAL SNES not modded + Top Gear == losing sync when starting race etc. When the screen is black for a moment I’ve got sync loss and music stops playing. The OSSC in this very moment has a red light. The cable is RGC C-SYNC (LM1881 based) for SNES PAL. I tried to increase VTH but is changes nothing. I see that I’m not the only one with such problem.

    BUT I’ve Retrotink 2x-Scart, too. And with Retrotink my configuration and Top Gear works FLAWLESSLY and PERFECT. Thus the problem is not SNES, not a cable. The problem is OSSC. There is some serious bug in ossc firmware or in ossc hardware.


    It’s not that simple, unfortunately. The red light in an incidation that OSSC loses sync lock which may occur due to source switching mode (which can be very temporary with certain systems/games) or noise/glitches on sync signal. The digitizer chip is not very tolerant to any sync deviations since its primarily designed for graphics systems with stable and regular sync. To rule out cable etc. issues, you can try the following:

    1. Set “Analog sync LPF” to 2.5MHz and “Analog STC LPF” to 0.5MHz (SDTV). You can try additionally adjusting “Analog sync Vth”.
    2. If you have composite cable for SNES, try connecting it to Y-input (B/W picture on AV2) and see if the issue reproduces
    3. Freeze reading of incoming video status after booting a game by pressing “profile load” hotkey on remote and leaving it on the prompt

    Anyone else can try that particular game to see if this is related to mode changes?


    I have similar issues with Street Fighter 2 Turbo (PAL), in character screen and in-game. OSSC is dropping the signal constantly.


    I have some different cables to test:

    • Composite video to AV2: Needs Analog sync Vth at 214mV for stable sync.
    • RGB cable with Luma sync: Needs Analog sync Vth at 214mV for stable sync.
    • Universal SNES cable with sync stripper on Composite video: Always loses sync

    It appears the sync stripper in the cables is not able to process the malformed sync signal on Composite Video/Luma from the 1-CHIP SNES consoles. Profile load hotkey didn’t change anything.

    With a non 1-CHIP console there is no issue at all.

    Michal Stepien

    Thus let’s make it official in OSSC specs, I mean sth like that “Don’t use cables with CSYNC, ONLY LUMA SYNC COMPATIBLE”.
    But eventually it works with Retrotink 2x-Scart. So maybe it is not a cable, after all? I think that OSSC is a great
    piece of hardware but as an opensource it should not hide its flaws.


    OSSC works fine with Csync. This specific problem is 1-CHIP SNES with sync stripper in the cable.

    The NTSC 1-CHIP SNES has native Csync so the cable doesn’t have a sync stripper and it has no problems.

    Most likely the Retrotink is more resilient against bad sync than OSSC.

    Michal Stepien

    So sth like that in description of OSSC is ok for you?
    IMHO “being non-resilient” is a bug. And bug is ok if we know about that. For some
    bugs there are no workarounds or fixes.

    BTW, according to your findings Universal RGC SNES Scart cable is not universal any more 😀
    Let them know about it.


    @paulb_nl: are the resuls with Analog STC LPF set to 0.5MHz (SDTV)?

    Also, could someone take a picture of the LM1881 circuit built into the cable? If it’s not done properly (e.g. missing termination on input), it can do more harm than good. It’s not that anyone is trying to hide the fact OSSC is fairly sensitive to sync noise, or the by-design sync jitter of SNES. For example, there’s a sticky thread about the latter on this forum and on wikipage. Similar issues are not that uncommon across video frontends – I had to mod c-sync output to most of my consoles already 10-15 years ago to make them work reliably with XRGB and displays of that era.

    Michal Stepien

    The cable I’ve got is not exotic or something. Mine is RGC:

    but considering post of paulb_nl the issue is IMHO related also to:
    I’m going to return mine and replace it with LUMA version, which seems to work after tweaking “Analog sync Vth”, thus I do not want to open that — I have two left hands. I’ve already send a message to RGC about the issue.

Viewing 15 posts - 1 through 15 (of 21 total)
  • You must be logged in to reply to this topic.