maxtherabbit wrote on 2020-06-06, 14:03:

All of those inline VGA to HDMI dongles are absolute garbage

They do tend to overpromise and underdeliver. Considering they have no controls (and usually no scaler anyway), you have to hope they do what you want them to do in terms of output, even when they do handle the input (70Hz) .

they also have no LPF so you get a ton of noise, and they only have a handful of sampling profiles for common PC resolutions - if you deviate at all you end up with a blurry mess

So, I now have an OSSC .

After some phase adjustments, it works great in all pass-through resolutions, that is anything with more than 400 lines of vertical resolution, up to and including 1600x1200 at 60Hz .
720x400@70Hz and 640x400@70Hz display fine in pass-through mode and with line2x, but are stretched by the monitor .

I then tried 720x400@70Hz and 640x400@70Hz with the line3x option and found that they were glitchy on my OSSC unit at least (on screen shimmering) .
I understand that the 1600x1200 @70Hz mode that is being output is out of spec (189MHz) and that the TMDS in the OSSC likely does not like it .

What I do not understand is why it was not possible to implement 1600x1200@70Hz with reduced blanking to fit under 162MHz and avoid over-specing the TMDS . Is this due to the line-multiplication only implementation of OSSC and thus lack of a frame buffer ?

Another thing I do not understand is why, in line3x mode, does horizontal sampling need to be set to 2000 lines? The actual horizontal resolution of the source does not change when line3x is enabled, so why is horizontal sampling not set to 900 or 800 total lines (including inactive lines for 720x400@70Hz and 640x400@70Hz ), like in line 2x or pass-through mode ?

Sorry if these are dumb questions and if this is not the best place to ask, but there does not seem to be a lot of info about using 400-line DOS modes with an OSSC , or at least not that I have found .

Any insight, suggestions or references to good beginner docs on using an OSSC, especiallly with DOS VGA modes, would be greatly appreciated .

darry wrote on 2020-06-07, 06:07:

So, I now have an OSSC . […]
Show full quote

So, I now have an OSSC .

After some phase adjustments, it works great in all pass-through resolutions, that is anything with more than 400 lines of vertical resolution, up to and including 1600x1200 at 60Hz .
720x400@70Hz and 640x400@70Hz display fine in pass-through mode and with line2x, but are stretched by the monitor .

I then tried 720x400@70Hz and 640x400@70Hz with the line3x option and found that they was glitchy on my OSSC unit at least (on screen shimmering) .
I understand that the 1600x1200 @70Hz mode that is being output is out of spec (189MHz) and that the TMDS in the OSSC likely does not like it .

What I do not understand is why it was not possible to implement 1600x1200@70Hz with reduced blanking to fit under 162MHz and avoid over-specing the TMDS . Is this due to the line-multiplication only implementation of OSSC and thus lack of a frame buffer ?

Another thing I do not understand is why, in line3x mode, does horizontal sampling need to be set to 2000 lines? The actual horizontal resolution of the source does not change when line3x is enabled, so why is horizontal sampling not set to 900 or 800 total lines (including inactive lines for 720x400@70Hz and 640x400@70Hz ), like in line 2x or pass-through mode ?

Sorry if these are dumb questions and if this is not the best place to ask, but there does not seem to be a lot of info about using 400-line DOS modes with an OSSC , or at least not that I have found .

Any insight, suggestions or references to good beginner docs on using an OSSC, especiallly with DOS VGA modes, would be greatly appreciated .

I think I understand where the 2000-line sample (1600 active) comes from . The OSSC can't scale, so if it can't integer multiply( like for line2x, where 2x720=1440 or 2x640=1280) , the only way to get 1600 lines out 720 or 640 actual ones is to digitise at 2000 (1600 active) .

EDIT: Now if there was a way to decouple the sampling timings from the output timings, 1600x1200 @70Hz with reduced blanking intervals (and <162MHz pixel clock) should still be possible .

There will never be a way to truly decouple sample timing from output timing with the OSSC, due to the lack of frame buffer as you mentioned. The upcoming OSSC Pro will address these issues and more.

The best result with the 400p line modes is to digitize them correctly and output at line2x. Which it sounds like is exactly what you are doing already. If your display is stretching them to 16:9, see if you can change something in the display menu to force 4:3. That's a display limitation for sure, since they work fine in 4:3 for me

maxtherabbit wrote on 2020-06-07, 19:44:

There will never be a way to truly decouple sample timing from output timing with the OSSC, due to the lack of frame buffer as you mentioned. The upcoming OSSC Pro will address these issues and more.

The best result with the 400p line modes is to digitize them correctly and output at line2x. Which it sounds like is exactly what you are doing already. If your display is stretching them to 16:9, see if you can change something in the display menu to force 4:3. That's a display limitation for sure, since they work fine in 4:3 for me

There is a OSSC Pro coming ?!

Prez wrote on 2020-06-07, 19:59:

maxtherabbit wrote on 2020-06-07, 19:44:

There will never be a way to truly decouple sample timing from output timing with the OSSC, due to the lack of frame buffer as you mentioned. The upcoming OSSC Pro will address these issues and more.

The best result with the 400p line modes is to digitize them correctly and output at line2x. Which it sounds like is exactly what you are doing already. If your display is stretching them to 16:9, see if you can change something in the display menu to force 4:3. That's a display limitation for sure, since they work fine in 4:3 for me

There is a OSSC Pro coming ?!

huge thread about it over at shmups bro

https://shmups.system11.org/viewtopic.php?f=6&t=65892

maxtherabbit wrote on 2020-06-07, 19:44:

There will never be a way to truly decouple sample timing from output timing with the OSSC, due to the lack of frame buffer as you mentioned. The upcoming OSSC Pro will address these issues and more.

The best result with the 400p line modes is to digitize them correctly and output at line2x. Which it sounds like is exactly what you are doing already. If your display is stretching them to 16:9, see if you can change something in the display menu to force 4:3. That's a display limitation for sure, since they work fine in 4:3 for me

Thank you for your response . I just, likely needlessly, opened a feature request for this https://github.com/marqs85/ossc/issues/56 , so I will get an official response too .

Sadly, even with its aspect preservation mode on, my display (Acer VW257 1920x1200 75Hz ) stretches everything that isn't exactly 4:3 , 16:9 or 16:10 (assuming square pixels) , so line2x gets stretched . It makes sense, in a way, because there is no real way for the display to guess the actual pixel aspect ratio, so it stretches anything that does not look 4:3 , 16:9 or 16:10) . What display are you using ? Is it 4:3 ?

EDIT: Corrected inaccuracy

darry wrote on 2020-06-07, 20:02:

Thank you for your response . I just, likely needlessly, opened a feature request for this https://github.com/marqs85/ossc/issu […]
Show full quote

maxtherabbit wrote on 2020-06-07, 19:44:

There will never be a way to truly decouple sample timing from output timing with the OSSC, due to the lack of frame buffer as you mentioned. The upcoming OSSC Pro will address these issues and more.

The best result with the 400p line modes is to digitize them correctly and output at line2x. Which it sounds like is exactly what you are doing already. If your display is stretching them to 16:9, see if you can change something in the display menu to force 4:3. That's a display limitation for sure, since they work fine in 4:3 for me

Thank you for your response . I just, likely needlessly, opened a feature request for this https://github.com/marqs85/ossc/issues/56 , so I will get an official response too .

Sadly, even with its aspect preservation mode on, my display (Acer VW257 1920x1200 75Hz ) stretches everything that isn't exactly 4:3 , 16:9 or 16:10 (assuming square pixels) , so line2x gets stretched . It makes sense, in a way, because there is no real way for the display to guess the actual pixel aspect ratio, so it stretches anything that does not look 4:3 , 16:9 or 16:10) . What display are you using ? Is it 4:3 ?

EDIT: Corrected inaccuracy

I'm using a 59" Samsung plasma TV. Def not 4:3 😉

maxtherabbit wrote on 2020-06-07, 20:06:

darry wrote on 2020-06-07, 20:02:

Thank you for your response . I just, likely needlessly, opened a feature request for this https://github.com/marqs85/ossc/issu […]
Show full quote

maxtherabbit wrote on 2020-06-07, 19:44:

There will never be a way to truly decouple sample timing from output timing with the OSSC, due to the lack of frame buffer as you mentioned. The upcoming OSSC Pro will address these issues and more.

The best result with the 400p line modes is to digitize them correctly and output at line2x. Which it sounds like is exactly what you are doing already. If your display is stretching them to 16:9, see if you can change something in the display menu to force 4:3. That's a display limitation for sure, since they work fine in 4:3 for me

Thank you for your response . I just, likely needlessly, opened a feature request for this https://github.com/marqs85/ossc/issues/56 , so I will get an official response too .

Sadly, even with its aspect preservation mode on, my display (Acer VW257 1920x1200 75Hz ) stretches everything that isn't exactly 4:3 , 16:9 or 16:10 (assuming square pixels) , so line2x gets stretched . It makes sense, in a way, because there is no real way for the display to guess the actual pixel aspect ratio, so it stretches anything that does not look 4:3 , 16:9 or 16:10) . What display are you using ? Is it 4:3 ?

EDIT: Corrected inaccuracy

I'm using a 59" Samsung plasma TV. Def not 4:3 😉

Your display is a TV and I imagine it lets you force 4:3 aspect ratio onto any received signal (like most TVs, AFAIK), including 1280x800 .

I guess for me it's either back to the Extron or living with a stretched image until a not so likely OSSC update for line3x (got a answer on the feature request, sampling and output decoupling is only possible in a limited way) happens or the OSSC Pro comes out .

This is unless somebody can suggest an HDMI/DVI scaler that handles 70Hz in an out, has reasonable latency and does not cost an arm and a leg .

darry wrote on 2020-06-07, 20:24:

Your display is a TV and I imagine it lets you force 4:3 aspect ratio onto any received signal (like most TVs, AFAIK), including […]
Show full quote

maxtherabbit wrote on 2020-06-07, 20:06:

darry wrote on 2020-06-07, 20:02:

Thank you for your response . I just, likely needlessly, opened a feature request for this https://github.com/marqs85/ossc/issues/56 , so I will get an official response too .

Sadly, even with its aspect preservation mode on, my display (Acer VW257 1920x1200 75Hz ) stretches everything that isn't exactly 4:3 , 16:9 or 16:10 (assuming square pixels) , so line2x gets stretched . It makes sense, in a way, because there is no real way for the display to guess the actual pixel aspect ratio, so it stretches anything that does not look 4:3 , 16:9 or 16:10) . What display are you using ? Is it 4:3 ?

EDIT: Corrected inaccuracy

I'm using a 59" Samsung plasma TV. Def not 4:3 😉

Your display is a TV and I imagine it lets you force 4:3 aspect ratio onto any received signal (like most TVs, AFAIK), including 1280x800 .

I guess for me it's either back to the Extron or living with a stretched image until a not so likely OSSC update for line3x (got a answer on the feature request, sampling and output decoupling is only possible in a limited way) happens or the OSSC Pro comes out .

This is unless somebody can suggest an HDMI/DVI scaler that handles 70Hz in an out, has reasonable latency and does not cost an arm and a leg .

I would stick this hypothetical scaler between the OSSC and the display, the OSSC digitization is top notch .

darry wrote on 2020-06-07, 20:24:

Your display is a TV and I imagine it lets you force 4:3 aspect ratio onto any received signal (like most TVs, AFAIK), including 1280x800 .

It does indeed. I have definitely seen monitors with this feature as well though. If you are super attached to that specific display I get it but I'd definitely try some others if I were you.

maxtherabbit wrote on 2020-06-07, 20:48:

darry wrote on 2020-06-07, 20:24:

Your display is a TV and I imagine it lets you force 4:3 aspect ratio onto any received signal (like most TVs, AFAIK), including 1280x800 .

It does indeed. I have definitely seen monitors with this feature as well though. If you are super attached to that specific display I get it but I'd definitely try some others if I were you.

I am not that attached to the display, which I just purchased a month ago , but there aren't that many 1200P displays available and it seems to be a gamble as to which ones will actually let you force 4:3 aspect ratio onto an arbitrary input signal rather than just preserve the aspect ratio of an existing signal if it happens to fit within certain criteria (which is what my monitor does) .

I have been googling HDMI scalers for a while and am starting to think that what I want does not exist for mere mortals or is the kind of thing the belongs in a studio/production facility with corresponding price tag, overkill (for me) feature set and size .

I'd rather have a 1080 panel that can properly preserve aspect ratios and run VGA modes at line2x (with a tolerably crisp scale from 800/960 line inputs) than worrying about UXGA support for a retro PC application.

maxtherabbit wrote on 2020-06-07, 22:10:

I'd rather have a 1080 panel that can properly preserve aspect ratios and run VGA modes at line2x (with a tolerably crisp scale from 800/960 line inputs) than worrying about UXGA support for a retro PC application.

I agree . I was expecting the 1200p vertical resolution to be better for retro applications because it's 3x400 , not because I explicitly need UXGA support. To be fair, had it been possible to force a 4:3 aspect ratio on the monitor (or if my OSSC handled a 189MHz pixel clock), it would have been an ideal setup, with integer vertical scaling and minimal horizontal scaling .

I still have the FX 5900 over DVI to fallback on, in the meantime . Aspect ratio and 70Hz are preserved, but the scaling is really soft .

I used the info here https://videogameperfection.com/forums/topic/ … e-for-retro-pc/ to achieve a usable 640x400@70Hz . I do not fully understand everything said there (I get where the 2000 sampling rate comes from, but not what the 1347 means nor the why the 667 sampling rate is significant for 4:3), but I tried these timings in line2x mode :
H. Samplerate : 700
H. Synclength : 64
H. backporch : 52
H. Active : 570
V. Synclength : 2
V. Backporch : 34
V. Active : 400

and they are serviceable, for the most part . The aspect ratio is pretty close and the uneven sampling on the horizontal axis is hardly noticeable .

EDIT: That said, an OSSC Pro is practically going to be an insta-buy, even if the price ends up being steep .

EDIT2: Integer scaling 640x480 to 1280x960 really brings back memories of that pre LCD-everything is-interpolated era. I had almost forgotten what that was like. It's like a breath of fresh air .

the correct sample rate for 640x400p70 is 800px/line, you're losing quite a bit of resolution by undersampling it at 700

maxtherabbit wrote on 2020-06-08, 14:10:

the correct sample rate for 640x400p70 is 800px/line, you're losing quite a bit of resolution by undersampling it at 700

Well, yes and no . Since the 640 is actually double-scanned 320, it's not that bad resolution wise .

The bogus sample rate does give somewhat slightly uneven pixel widths, which is not very noticeable .

The whole point of this is getting a 4:3 image . I do not quite understand why it works . The monitor sees 1140x800 , does not stretch to fill the screen horizontally and aspect ratio is almost spot-on .

oh yeah good point, the uneven pixel widths would still bother me though

maxtherabbit wrote on 2020-06-08, 16:48:

oh yeah good point, the uneven pixel widths would still bother me though

I'm not crazy about it either. I wish I could capture the output (good luck with those non standard resolutions and timings). I will try to take some photos .

I still have hope that I will get better results when I understand this stuff better . I do have a grasp of the basic concepts (total vs active , back and front porch, etc), but I get lost in the implementation . I wish there was some good tutorial about this stuff, ideally OSSC oriented, not just recipes to follow .

EDIT: I know that my monitor is a big variable in this as predicting what it will and what it won't stretch is not easy .