OSSC not syncing until reconnect

[uchristo]

Hi folks

I got a problem with an simulated Amiga connected via YPbPr to AV1 of OSSC. Everytime I Switch from 720p60 (Workbench resolution) to a game, OSSC starts flickering because it is unable to decide which input mode to choose. I need to replug the input source into AV1 to sync the OSSC to 313p. I took two Videos of this behavior……..
Video 1
Video 2

[BuckoA51]

Can I ask a bit more detail about this simulated amiga? 720p is pretty high resolution for Amiga are you using some sort of graphics board or simulated RTG board?

[uchristo]

It‘s an MiST FPGA with simulated minimig RTG. I‘m running 720p60 at 8bit Colours without problems. But as soon as I switch to PAL LoRes or PAL HiRes resolution, the behaviour in the Video starts. I disconnect AV1 and when I plug it in again, the OSSC immidiately syncs..

[BuckoA51]

I’d strongly advise against disconnecting and reconnecting with the power on, does changing to another input then back again not work?

[uchristo]

Switching to AV2 and back again to AV1 worked (did only one quick test)

Edit: I must add that input switching is quite laggy when ossc is quick toggling between input mode. You‘ll have to press the input button quite long before ossc recognizes the desire of input switching

• This reply was modified 2 years, 2 months ago by uchristo.

[uchristo]

Is there a way to debug this? Maybe serial connection logging?

[marqs]

I’m afraid that kind of behaviour is due to sync detection issues in TVP7002 video ADC. I’ve been thinking about rewriting the firmware for a while and one of the various things to improve would be bypassing video ADC sync processing as much as possible and handle those functions by FPGA. Most likely that’d involve a small HW modification since raw SOG signal from the chip is not currently connected on the board.

If you have USB Blaster JTAG programmer, you could try resetting TVP7002 sync processing (as done in tvp_disable_output()) when mode change is detected.

[uchristo]

I‘m afraid I do not own any JTAG Programmer at all…. If I understood correctly, I‘d have to disable a feature in TVP (permanently?) which could be implemented in FPGA in a better way (combined with an additional trace on pcb)

[marqs]

No, the suggestion was to just tweak the existing firmware in a small way to work around the issue. The rewrite is completely different topic that could provide proper fixes to some of the sync issues caused by the TVP chip. For the proposed tweak I could also consider generating a test firmware, but without similar setup to try the workaround it may be hit and miss.

[uchristo]

Is there a safe way to detect the issue on fpga-side? One could possible workaround by switching tvp to a dummy input? If I understood correctly, egbhv-input on component terminals would never be possible, so this could be the dummy input. But it depends on proper detection of the issue.

The TVP7002 contains three identical analog channels that are independently programmable. Each channel consists of a clamping circuit, programmable gain control, programmable offset control, and an ADC.
Analog Input Switch Control
TVP7002 has three analog channels that accept up to ten video inputs. The user can configure the internal analog video switches via the I2C interface. The ten analog video inputs can be used for different input configurations, some of which are:
• Up to three SDTV, EDTV, or HDTV component video inputs (limited by number of SOG inputs)
• Up to two 5-wire PC graphics inputs (limited by number of HSYNC and VSYNC inputs)
The input selection is performed by the input select register at I2C subaddress 19h a 1Ah (see Input Mux Select 1 and Input Mux Select 2).

I‘d agree to hit and miss development approach 😉

• This reply was modified 2 years, 2 months ago by uchristo.

[uchristo]

Any news on this? I‘d rather not send my MiST through the world… a lost parcel does not really matter, but rare hardware is hard to replace these days.

[marqs]

I have early version of the new firmware, but it still needs a bit more work to be usable. Anyone planning to test it needs perform a small HW mod on the board and should have USB Blaster as a backup. Expect more details in 1-2 weeks.

[uchristo]

Great news! I‘ll get familiar with the USB Blaster

[marqs]

Details for a beta fw are now on this thread.

[Author]

Posts