Tips & Tweaks: Lx3, Lx4, Lx5 modes

[James-F]

Few questions from a newb:

Does the OSSC first samples (ADC) then scales (x2, x3, x4, x5) or vise-versa?
Is the LPF analog?
Can someone please post a proper signal path from Analog to Digital inside the OSSC?
Something like: Analog -> LPF -> Sampling -> Scaling -> Post Processing.

Another question/clarification related to timing, sampling, and TV compatibility;

The H.samplerate is effectively the “Total Pixels” while the Active Pixels is the visible resolution, everything else is for back/front porches and sync, just like in Nvidia Custom Resolution correct?

Does the process of sampling (digitization) include the analog sync signal, or the analog sync is used as a trigger only for the digital sampling process?
I ask because the Sync options are in uS instead of pixels.

Basically, is the OSSC H.samplerate is between the red lines?
https://s17.postimg.org/noqm51men/Analog_Timing.png

What do incompatible TVs don’t like then, the difference between active vs total pixels counts, or are the TVs expect exact timings according to spec “to-the-last-pixel” to show picture?
What is the general tolerance of TVs to off-spec timings?

If so many TV do not support the abnormal timings, why not use the HDTV EDID timings and insert “black pixels” as part of the active pixels to compensate and essentially standardize the OSSC timing?
That would solve all the problems for all TVs… no?

https://www.mythtv.org/wiki/Modeline_Database

[Harrumph]

I’ll try to answer, however this is all at the border of my understanding of analog and digital video (or the OSSC itself for that matter), so hopefully someone will correct me if I’m totally off-base with some of this.

Does the OSSC first samples (ADC) then scales (x2, x3, x4, x5) or vise-versa?

Yes, sample then scale.

Is the LPF analog?

Yes to my understanding, both video and sync LPF are analog (prior to ADC).

Analog -> LPF -> Sampling -> Scaling -> Post Processing

Yes, I believe this is correct (possibly some post-processing is done prior to scaling, others after, not sure).

The H.samplerate is effectively the “Total Pixels” while the Active Pixels is the visible resolution, everything else is for back/front porches and sync, just like in Nvidia Custom Resolution correct?
[…]
Basically, is the OSSC H.samplerate is between the red lines?

Yes and yes.

Does the process of sampling (digitization) include the analog sync signal, or the analog sync is used as a trigger only for the digital sampling process?
I ask because the Sync options are in uS instead of pixels.

Well more like both, hsync is used to generate pixelclock, but afaik the sync is still separated, sampled and recombined to be output as the digital clock stream. At least I know that digital RGB still consists of three channels for image information (pixel RGB values), and one channel for pixelclock/sync. If the digital sync signal is further processed, it’s very possible it is “regenerated” rather than sampled and piped through, but I do not know.
Sync options relate to the incoming analog sync, so I guess it’s natural it’s given as seconds.

What do incompatible TVs don’t like then, the difference between active vs total pixels counts, or are the TVs expect exact timings according to spec “to-the-last-pixel” to show picture? What is the general tolerance of TVs to off-spec timings?

Well, that’s the million dollar question… 😉 I don’t know if an answer can even be given, except that “it’s a bit of everything”. The tolerance for pixelclocks, line count and refresh all interact, and when they separately and combined are not in line with standardized specs, it’s very hard to predict compatibility. And the only one of those factors the OSSC can influence is the pixel clock (by varying samplerate).

If so many TV do not support the abnormal timings, why not use the HDTV EDID timings and insert “black pixels” as part of the active pixels to compensate and essentially standardize the OSSC timing?

OSSC has only limited line buffering capabilities due to memory constraints, it cannot hold more than a handful of lines at a time and thus compensations are very limited or even non-existant. Standardization would inevitably include frame conversion, and from what I’ve read from the likes of Marqs, a dedicated frame buffer is really the only way to deal with this.

[James-F]

Thank you, for the much needed clarification!

And the only one of those factors the OSSC can influence is the pixel clock (by varying samplerate).

As I understand, the OSSC can be adjusted to the hi-res spec timings even if the samplerate is not accurate for the specific console.
Sync problems with the OSSC lie in: First adjusting sampling rate (total H pixels) for the specific console, and only then the (A+P+S) parameters, which is in reverse order. 🙂
To me it seems that with proper tweaking any display can be synced in x4,x5 modes with slightly less accurate samplerate, unless of course the display doesn’t like the Total.H.pixel.count in the first place.
Basically adjust the OSSC for on-spec hi-res HDTV specs even if the H.samplerate is not accurate for the console.
Can you please try that (my ossc is yet to arrive)?

Questions:
Basically (active+porch+sync) = (1,2,3,4,5)*(H.Samplerate), but do the (A+P+S) tied to the scaler too, or are they independent?
Ex. 5x(A+P+S) = 5x(H.sr), or the (A+P+S) controller independently?

Are the advanced timings open in General (4:3) mode, or it is on-spec to work with all displays?

[Harrumph]

To me it seems that with proper tweaking any display can be synced in x4,x5 modes with slightly less accurate samplerate, unless of course the display doesn’t like the Total.H.pixel.count in the first place.

This was a hypothesis I had for a while, attempting to ”chase the pixel clock”. I even made a spreadsheet to more easily calculate what samplerate should be to match certain VESA & CEA pixel clocks for various resolutions.
However, my conclusion is that it doesn’t really work like this.
An equally (or perhaps rather more) important factor is the line count, which when different to the standard specs also equates to off-spec horizontal frequency, i.e. it’s not as much about total pixels or vertical refresh, but how fast each line is drawn. Especially CEA 720p and 1080p has sigificantly fewer lines than VESA PC modes, which is probably why the 256-vertical tweak has seen some success.

Some clarification to earlier post: scaling is actually misleading term, line-multiplication is more proper. However, it’s also different for generic and optimized modes.
Generic mode simply samples the analog signal at the full rate which matches the final vertically multiplied target.
Optimized, on the other hand, samples at only the ”base level” i.e. 1x, and set to match the dot rate of a console. In this case, it actually is scaled horizontally, by using pixel repetition.
Interestingly, the pixel repetition can be set to different factor for active vs total portion of signal. E.g., for 256×240 4:3 Lx3 mode, H active area is multiplied (pixels repeated) 4 times, while total area is multiplied 5 times.

As I interpret this, this way the active window (as seen by display) and total samplerate conforms more closely to the widescreen format of 720p. In effect, the OSSC creates a “fake” active window of 1280 length, which is only filled by 1024 by the original active signal (“close” to 4:3 aspect). In this way the signal (originally 4:3) is manipulated to output something more similar to a 16:9 signal (the actual picture area is compressed in relation to the total length). This is explained in the “optimal timings” page on the OSSC wiki. (Tbh, this section of the wiki could probably be expanded/clarified even more.)

Example: optimized 256×240 4:3 Lx3 mode
Incoming dot rate, sampled at: 341
Outgoing 341×5 = 1705 (close to 1650 of 720p)
Outgoing H active 256×5 = 1280 (ie resulting active area 1280×720, as expected for 720p)
Actual picture in H active 256×4 = 1024 (resulting display AR 1024/720 = 1,42)

EDIT: was a bit confused regarding the pixel repetition in original reply, and have added an example of how I interpret it to work. I would be happy if someone corrected me on this, because I am not sure I’m understanding it correctly myself.

[James-F]

Misleading post removed.

[Harrumph]

Edited my above post to hopefully clarify (or give someone the opportunity to correct me 🙂 )

[James-F]

Didn’t you mix x5 sampling and x3 optimized in your edit? Shouldn’t they have the same multiplier?
Have a look at my previous post, I think the vertical timing parameters are more important for TV to sync.

Can’t Marqs clarify this? Or is it some sadistic game he plays and lets us figure this out the hard way? 🙂

[Harrumph]

No, it’s described as 5x (horizontal factor). Well, thinking about it some more, it could actually happen in two additional alternate ways, so yeah some clarification from Marqs would be neat.

Using example from previous post again, optimized 256×240 4:3 Lx3
Alt 1: described in above post
Alt 2: whole output line is actually constructed by 4x pixel repetition, only that output H active is defined as 5x, and the extra pixels to make up the difference are subtracted from blanking (ie. 128 pixels on each side of picture data). Resulting output total H.samplerate would be 341×4 = 1364. This seems unreasonable as it leaves only 1364-1280= 84 for blanking.
Alt 3: pixel repetition is applied separately for output H active and blanking. Such that blanking receives x5 and active x4. However, output H.Active is again defined as x5 and the difference made up by subtracting from blanking. Resulting output samplerate would be (341-256)x5 + 256×4 = 1449. This seems more plausible given that VESA specs for 1280×720 and 1280×768 has 1440 (in newer “reduced blanking” modes).

I don’t know regarding your observation on vertical lines. It seems less likely to be a factor to me, simply given that TVs are probably preprogrammed to recognize only certain vertical active heights.

[James-F]

Misleading post removed.

[Harrumph]

Ok, I understand, you’re trying to test if you’re screen is compatible, using that software right?

Maybe you’ll find useful, this google sheet I put together of the OSSC default sampling values.

OSSC default sampling parameters

If you have a NeoGeo or PAL PSX (which have additional lines), there is a page on the wiki with modelines if you want to test compatibility.
http://junkerhq.net/xrgb/index.php?title=OSSC_potential_incompatibilities

unlike generic which samples AFTER multiplication of the standard 428 sampling value.

Horizontal sampling values in generic mode is input directly and not calculated via multiplications. Once you have the OSSC in front of you, you will see that you can enter any value for those parameters, regardless of line multiplication mode (within the limits of OSSC sampling capability, of course).
There are however some adjustments applied internally “under the hood”, eg in Lx5 mode (and I think Lx3 mode). See e.g. here:
v-backporch-increase-upper-limit

Also it can be noted that sync polarity is always negative, as Marqs described here:
output-sync-polarity-option

[James-F]

Fantastic, this is exactly the info I was missing.
I received the OSSC just few hours ago and tested with my Dell U2410 monitor, the Genesis,Snes,PS1,PS2 which work perfectly in all LineX modes.
480i in Line4x (bob) works great, while passthru has huge lag and distorted colors on my monitor.
All my rgb cables are from retrogamingcables.co.uk and I don’t see any video noise even with both LPF’s off.

I should say that Generic mode is great while the Optimized mode if not set correctly is very distorted and ugly.
Sometimes even 1 pixel in H.samplerate makes Optimized mode go crap, definitely not for noobs.

I think it would be very helpful if noobs can find your excel sheets in the wiki.
Thanks for the patience Harrumph. :blush:

[James-F]

Aspect Ratio info;

From measurement the OSSC in Generic x3,x4 modes creates aspect ratio of 4:3 according to 224 vertical lines, so 224*4/3 = 298 horizontal.
That means 22 pixels horizontally and 16 pixel vertically are overscan.
Also, games that use 240 vertical pixels on the Genesis or Snes will have 300/240 (3.75:3) aspect ratio.

My CRT is set to show the Genesis and Snes halfway between 224 and 240, so 224 is slightly underscan and 240 is slightly overscan, for best of both worlds and support for PS1 (240) without overscanning too much.

This is an image of Genesis 240p suite in Linex3 Generic mode including the borders.
Masking tape marks are 4:3 ratio on this 16:9 monitor.

Now a PS1 game is 320×240 but I can see that horizontally it is not fully 4:3.
Looks like OSSC Generic mode treats 320 horizontal lines as active+overscan.

[James-F]

I successfully managed to tweak advanced timing in Generic Line3x mode (960×240) and 480i Line2x (bob) mode so all my consoles have almost perfect 4:3 ratio with very minor overscan between them, which my old AOC monitor took without much fuss.

I had to jump back and forth between console and check that one console adjustment did not crop some area from another console, until all consoles fit just fine in 4:3 size picture with some minor underscan too support them all.

240p Line3x mode (960×240):
H.samplerate 1260 (from 1170)
S.synclen 54 (default)
H.backporch 179 (from 128)
H.active 960 (default)
V.synclen 3 (default)
V.backporch 15 (default)
V.active 240 (default)

480i Line2x (Bob) mode:
H.samplerate 940 (from 858)
S.synclen 62 (default)
H.backporch 110 (from 57)
H.active 720 (default)
V.synclen 3 (default)
V.backporch 15 (default)
V.active 240 (default)

In short:
Increasing H.samplerate will stretch the image.
Increase H.backporch to bring the image to the center.

Some screen pics I took to demonstrate the result:

PS1 480i

PS1 240p

Genesis 320x224p

Genesis 256x224p

Genesis 480i

Snes 256x224p

Snes 256x239p

Snes 480i

[BuckoA51]

Nice post thank you!

There is a lot of information to digest through this thread and I do try and update the wiki with it from time to time.

[James-F]

I should add that my Pioneer DVD player (DV-400V) outputs RGB from its Scart output, and looks fantastic through the OSSC in 480i Line2x bob.
But the DVD output requires the default 480i timing of the OSSC to not crop some horizontal resolutions on the sides.

It seems that all Consoles I tested (Sega, Snes, PS1, PS2) have big underscan, if the CRT or the OSSC is adjusted for a standard DVD or NTSC 480i signal, this is probably because most TVs had a lot of overscan while game developers wanted all the game image to be visible.
Luckily the OSSC has presets which is an incredibly useful feature.

[Author]

Posts