Amiga – Multiple OSSC power cycles needed to sync

NewHome Forums OSSC & OSSC Pro OSSC – Discussion and support Amiga – Multiple OSSC power cycles needed to sync

Tagged: ,

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #26168

    Hello, I use an OSSC with my NTSC Amiga 1000 and have been having this same issue all the way through to the latest firmware, and I’m wondering if anyone is experiencing anything similar. The LED remains red while the OSSC display flickers between 263p and “NO SYNC”. However, if I cycle the OSSC’s power a number of times, the OSSC finally decides to sync, and it remains synced perfectly fine until I reboot.

    Here’s a video of someone else with a PAL machine demonstrating what I’m experiencing at the timestamp:

    He claims to have fixed it by repairing the CPU socket on his motherboard, but I experience this when using either the onboard CPU or an external CPU on an expansion card, so it’s unlikely that the CPU is the issue. The Amiga’s main CPU also doesn’t handle any kind of video timing, to my knowledge.

    Furthermore, the OSSC randomly decides to sync at 59.75Hz, 59.79Hz, or 59.82Hz. Any of them may work and display a clear image, or sometimes it syncs while the image remains black. After enough power cycles, I can always get the OSSC to sync, but sometimes it takes a really long time.

    Anyone else experience this issue, whether on Amiga or another console? Thanks in advance for any info you may have.


    Can you post the details shown on the info screen (press INFO on remote) when it’s synced. I also recall some Amiga models/modes needed H-PLL pre and post coast adjusted to 3 in sync menu.


    Sure thing, here’s the standard display:
    AV1: RGBS 263p
    15.72KHz 59.79Hz (sometimes 59.75Hz or 59.82Hz at random)

    Second display, from what I assume is the INFO button as I’m using a non-standard remote:
    Prof.0 1600×240
    263p* 451305 (sometimes 451306 or 451307)

    H-PLL adjustments had no effect, nor did any other setting seem to in the sync options. By this way, this occurs both on my custom profile and a profile with fully default settings.


    Ok, the asterisk in 263p* indicates that Amiga is using alternate field ID on VSYNC, and unfortunately the digitizer chip has trouble locking to that reliably (like with Jaguar in PAL mode or Taito F3). There are a couple workarounds (e.g. having another source initially connected to component input or SCART via a switcher, and then changing to Amiga input after both machines are powered on) but the only reliable solution is to hook the problematic system to VGA input (RGBS mode) which has a bit different sync processing.


    Understood, thanks for providing that info. I dug up a DB23<->VGA cable I forgot I had and tried VGA input. It syncs at RGBHV, but it’s perfectly stable and works on every power-on. The downside is that video LPF doesn’t work with VGA RGBHV/RGBS, and I was previously using it to filter out some of the noise coming in. So as of now, it’s a small hit to the image clarity in exchange for hassle-free syncing. I think I can safely blame the noise on the Amiga hardware and not my settings. Here’s hoping someone eventually designs a digital RGB output for Amiga, as the video chip outputs digital RGB which is then converted to analog using an onboard circuit.


    I have not noticed this issue with other Amiga models, maybe it’s specific to the A1000?


    Could be, I’m not familiar with how the sync is generated. But have you seen them tested with SCART, or just VGA? VGA syncs fine for me, but the noise in the video signal is just too much of a drawback.

    Would you be able to help determine, from a technical standpoint, what might be causing this kind of noise/jitter? To get a good video sample of the noise, I deliberately offset the H. samplerate by a few values and sharpened the video output:

    A1000 OSSC noise sample

    You can see that the vertical bars are so jagged that there is no vertical slice of the screen that is free of noise. So even with a perfect samplerate and sampling phase, bits of the screen are in constant horizontal jitter. Here it is with a perfect samplerate and phase, again sharpened to better display the noise:

    Applying a video LPF of 9MHz (EDTV) eliminates most of this noise, with the exception of the largest spikes.

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