Page 2 of 2

Re: RGB to SCART Video * solved *

Posted: Sun Apr 07, 2019 10:08 pm
by stephen_usher
Dave wrote:
stephen_usher wrote:If you try and OSSC, which does cost a lot more but is worth it, it's better than you'd get with a TTL RGB display.
That would be a magical transformation indeed. Even higher fidelity than the original.
That's easy, CRTs smear sideways due to the speed at which the beam can switch on and off and are not precise as the dot has slightly fuzzy edges. Also they flicker.

Producing a properly aligned, digitised version of the signal and then passing it on to a digital display can therefore produce a more precise and flicker-free image, better than the TTL RGB display.

Re: RGB to SCART Video * solved *

Posted: Sun Apr 07, 2019 10:57 pm
by Dave
stephen_usher wrote:
Dave wrote:
stephen_usher wrote:If you try and OSSC, which does cost a lot more but is worth it, it's better than you'd get with a TTL RGB display.
That would be a magical transformation indeed. Even higher fidelity than the original.
That's easy, CRTs smear sideways due to the speed at which the beam can switch on and off and are not precise as the dot has slightly fuzzy edges. Also they flicker.

Producing a properly aligned, digitised version of the signal and then passing it on to a digital display can therefore produce a more precise and flicker-free image, better than the TTL RGB display.
You know RGB works directly with TTL RGB displays that use LCD panels too, right? And that even a massively oversampled digital copy of that digital RGB signal* will still have some aliasing effects compared to the original? The point is, you can't put in information that wasn't already there.

Also, OSCC is *stupidly* over-priced for what it is.

* For the purposes of argument, RGB on the QL is a bit like light. It acts like an analogue and a digital signal. For the practical purposes of display, it is a digital signal.

Re: RGB to SCART Video * solved *

Posted: Mon Apr 08, 2019 10:19 pm
by stephen_usher
You could think of the TTL signal as a three line parallel digital signal but that's not how the TV/monitor sees it as it's treated as three sets of analogue signals. These are then put through an A-to-D converter. Scan line synchronisation could be an analogue circuit like old monitors or it could be done after digitisation, which is what the OSSC is doing.

Most TVs do an OK conversion on the SCART interface but are usually tuned for analogue video rather than a digital input and think that a sharp contrast is noise and hence tries to anti-alias sharp transitions. The also usually sharpen afterwards to give more "punch" to video, but this merely causes more artefacts. Of course, this depends upon the TV. Some TVs even send the VGA and decoded HDMI signals through these filters if it's not the screen's native resolution, as does my Curry's branded TV I use.

Cheap SCART->HDMI converters merely digitise, de-interlace and pass the data on with resolution information in the HDMI signal. It's then up to the TV/Monitor to do the rest, if it can.

The benefit of the OSSC (other than low latency) is that it's able to super-sample the incoming analogue signal allowing a far more precise registration of the pixels. It's also able to re-format the output, such as increasing the resolution of the HDMI output to be at or close to the TV/Monitor's native resolution. The combination of these and its flexibility does allow a superior display and it's half the price of the equivalent commercial scan converter.

Not only does this allow the full display of the QL output on any TV/monitor but it allows me to display the output from my Atari TT's VGA which follows a pre-standard VGA pixel clock that no normal VGA display can handle.

Re: RGB to SCART Video * solved *

Posted: Mon Apr 08, 2019 11:50 pm
by Dave
About half of what you said was right.

It's over-sampling, not super-sampling. The OSSC can only do 3x oversampling on the QL PAL signal, which means the start and end of each pixel can vary by up to 33%, and the maximum difference between a short and long pixel is 1:1.67. It does a decent job of trying to derive a dot clock from the sampling but only does at best an average job. The problem with 1.67:1 is that it can theoretically make a 1 pixel shift in position of the HSYNCH signal.

Anyway, I'm going to get back to the video system of Issue 8 now. It won't gain anything from the OSSC at all, as the timing will be fixed and output video will have PAL-legal timing.
Screen Shot 2019-04-08 at 5.49.54 PM.png

Re: RGB to SCART Video * solved *

Posted: Tue May 28, 2019 9:34 am
by tcat
Hi,

Taking interest in the topic at last. Just an idea, what sort of circuirty has been used inside Sinclair RGB monitors, those that connect right to the QL, and cope with overscan displaying correctly all 85 chars across. Is it worthwile to analyse and reproduce with todays component base? I mean not the whole CRT, just the RGB demodulation part.
Can it possibly fit in the SCART connector?

Tomas

Re: RGB to SCART Video * solved *

Posted: Tue May 28, 2019 12:01 pm
by tofro
The modification needed to a "real" CRT should actually be relatively easy. It would need slight modifications of the timing circuitry inside the CRT (basically "compressing" the screen into the available real estate and changing the horizontal offset of the beam).

That means, however, a modification inside the CRT and cannot happen on the input lines. What you do is basically extending the range of your convenient "horizontal Position" and "size" potentiometers most old CRTs have.

This approach is, however, impossible on modern LCD screens - they work entirely different.

Tobias

Re: RGB to SCART Video * solved *

Posted: Tue May 28, 2019 4:47 pm
by 1024MAK
TV standard CRT monitors just need some adjustments or modifications to the horizontal time base circuitry. Of course, this is easier said than done on most of them.

*Some* LCD monitors that can handle TV standard video have nearly enough adjustments. TVs often don’t have any provision for any adjustments, as there is no perceived need for such a thing.

By TV standard video, I mean 625 line 15625Hz/50Hz timing or system I.

The problem with the QL is that it starts producing picture information before the point that the TV standard says you can do so. Then continues to produce picture information after the end of where the TV standard says the picture information should stop.

No amount of messing with any external signals can change this. Unless you sample the signal and then replay it at a different speed...

Mark

Re: RGB to SCART Video * solved *

Posted: Wed May 29, 2019 10:14 am
by tcat
Hi,

Thank you, CRT beam timing simply escapes me. I know there is some vertical and horizontal timing, then some waits at each line, also when the beam reaches bottom right corner, as it has to come back to the top left corner again, this happens 50/60Hz, the complete TV refresh. Also other standards e.g. VGA, may have some different line metrics and possibly faster refresh. I am zero on HDMI. At a time people were building SCART to VGA convertors, as they could connect QL to their PC CRT monitor.

Now we have flat LED screens, suprisignly they may still offer VGA, next to HDMI, if it were a TV set, it can also offer SCART, unlike flat LED monitors.

My CRT tely, is not dumb 80's model, seems digital, it can scale, 4:3 and 16:9, hope I got it right. I use it for Speccy, ATARI ST, and the QL.

4:3, on the QL, I can get some more pixels across but not 85 columns, I still loose some 4 chars at the left, as the picture is a narrow strip in the middle, I prefer 16:9 where is bigger, even I loose more pixels on either side.

Tomas