[Zacabeb]

When testing connecting the component luma signal to a composite input, you only need to make sure the OSSC Pro outputs in 480i.

The result should be a black-and-white but stable and reasonably bright picture. If so, there’s likely a problem with the component input on the TV.

[Zacabeb]

Going by the photo, it looks as if the TV fails to clamp the luma signal fully back to its intended level. I’m not sure if that’s the cause of the random lines too.

While you’re waiting for the composite cable, you can try connecting the green (i.e. luma) connector on the component cable to one of the composite inputs.

Check if you get a stable black-and-white picture then with the OSSC Pro set to output 480i, including the test pattern. That could help rule out a fault with the OSSC Pro or its expansions.

There could be a fault in the component cable, so if the problem remains another thing you can try is swapping the green connector for the red or blue one on both ends and see if it changes how the fault appears.

[Zacabeb]

Try switching the option Output opt.->CSync combiner to Type B (XNOR+).

A photo or short video may indeed help figuring out the issue. 🙂

[Zacabeb]

To me it looks like aggressive sharpening/edge smoothing being done in the display as part of rescaling the input, possibly because the TV assumes a 50 Hz signal to be a video source rather than graphics irrespective of resolution (many TVs don’t even accept non-standard resolutions at 50 Hz.)

Make sure that the TV picture profile is in Custom mode or similar and all picture enhancements are disabled.

[Zacabeb]

The adaptive de-interlacing is quite basic in its interpretation of the picture, so it does make mistakes. Altera has a more sophisticated version than is used in the OSSC Pro, but it consumes substantially more resources.

The de-interlacing logic measures the difference in contrast across fields between the same and neighboring pixels to determine if there is motion. The resulting value controls whether the pixel is left as-is (weaving) or is given a weighted mean of the value across fields (effectively bobbing or blending.) The Motion Shift adjustment controls the threshold between those modes by dividing the motion value by a power of 2 (shifting the bits in the variable right to decrease the value, hence the somewhat unintuitive name Motion Shift.) At 0 it basically forces bobbing and at 7 it forces weaving.

Dropping Motion Shift to 1 or 2 may reduce the artifacts, but at the cost of increased bobbing in static parts of the image.

The more sophisticated version Altera has uses Sobel edge detection to derive motion vectors and more intelligently determine what to do, but I don’t know if it’s realistic to implement in the OSSC Pro given the additional performance overhead. Sharp pixel graphics are also more unforgiving since they more easily confuse the de-interlacer and reveal artifacts more clearly.

[Zacabeb]

@marqs Thank you so much for adding the aspect ratio adjustment to scaler mode! It’s great being able to adjust it on the fly. 🙂

[Zacabeb]

Those giant Gateway Destination monitors were sold as part of their short-lived attempt at making a PC the center of the living room. They reportedly have CRTs with coils for the 30-40 kHz range, so from what I understand they display 800×600@60 natively.

The little information available on them however suggests that they should handle most standard resolutions in that range, such as 640×480@60, but the model in question may be intentionally picky.

[Zacabeb]

What refresh rate is reported by the OSSC? If the PC outputs at 70 Hz, the TV as well as capture devices may not like the resulting signal.

They may also not like the output from an OSSC Classic or an OSSC Pro in pure line multiplier mode if the resulting output resolution is too far away from a standard TV or computer resolution.

If you have an OSSC Pro, using scaler mode and setting frame lock to 60 Hz should resolve the issue, at the cost of judder if the input has a different refresh rate.

[Zacabeb]

I remember experiencing an issue with the OSSC Classic on my Sony TV (an old 2007 model) where the Cr and Cb samples got mixed up in its internal processing under some circumstances, which was fixable by offsetting H.backporch by 1. It was some time ago though, so I no longer remember the exact details.

It could be a similar issue, the display getting confused and swizzling the components around because of the input signal being non-standard.

[Zacabeb]

That sounds awesome!

Could the six unlabelled buttons be included for custom configuration as well? They’d need some form of naming scheme to hint at which one is which and be marked in the picture of the remote on the wiki.

[Zacabeb]

Check the file for the Legacy AV In adapter case, the lid is probably the same.

[Zacabeb]

Yeah, it’s probably a very rare issue.

[Zacabeb]

I think the P and color buttons should be user configurable. Possible even the unlabeled buttons could be. So, for each of those buttons you’d be able assign a command from a list.

That way, any of the P or color buttons could be used for either a profile shortcut or another command such as power.

[Zacabeb]

The D1 diode looks to be the right way around in the picture.

I noticed though that pin 8 (CVBS signal status) in the SCART socket is unconnected in the adapter, which might cause issues with some TVs as they only switch to the input if it has voltage (+5V to +12V) and otherwise ignore it, even if pin 16 (RGB signal status/fast blanking) is active. I don’t know if the Grundig and Sony TVs in question are affected by that quirk though.

Edit: Marqs’ suggested causes in the post above are probably the more likely ones.

[Zacabeb]

Looking at the schematics, it seems that the two LSBs of each component from the TVP7002 are just floating.

https://raw.githubusercontent.com/marqs85/ossc_pcb/v1.8/doc/ossc_board.pdf

From what I gather, 30-bit color would require more bandwidth and GPIO pins than the FPGA has available.

[Author]

Posts