search

marqs85 / ossc

Open Source Scan Converter
http://junkerhq.net/xrgb/index.php/OSSC
GNU General Public License v3.0
470 stars 63 forks source link

Feature Request: Add a custom line2x mode for 640x400 where horizontal sampling is done at 1.6666 times the normal (800) sample rate and no horizontal line multiplication is done #59

Open Darry77 opened 4 years ago

Darry77 commented 4 years ago

I had an idea about an alternative way of doing things that might work on my display and likely others to get proper 4:3 aspect ratio (my monitor and others stretch 640x400 and 1280x800) without using line3x and overlocking the HDMI TX .

What about a custom line2x mode where horizontal sampling is done at 1.6666 times the normal (800) sample rate and no horizontal line multiplication is done ? That would give 1066x800 active pixels, which is 4:3 and be well below 162MHz H. Samplerate : 1332 (1332.5) H. Synclength : 33 H. backporch : 211 H. Active : 1066 V. Synclength : 2 V. Backporch : 34 V. Active : 400 I tried it with line3x mode, which obviously does not give the right aspect, because of the 3x vertical multiplication, but I do get a picture . Although I do get a thin vertical line of a slightly darker shade by the left edge of the image . This may just be my monitor (Acer VW257) reacting to the 1066x1200 I am feeding it for testing .

I tried simulating the resolution and timings using PowerStrip and the Geforce FX 5900, but the damn thing's drivers always override monitor scaling for me, so I can't really test directly sending 1066x800 to the monitor .

If I set these timings on the Voodoo 3 using PowerStrip, I cannot get the OSSC to sync correctly to the input in passthru. The OSSC chooses 1024x768 as the preset and even if I modify the timings to match it won't sync (garbled image). It could be that the Voodoo 3 can't actually output them correctly either . I am not too worried though, because the sampling would actually need to be done for 1332 by 449 pixels (total pixels) only, and on my line3x test I actually got a stable picture. The good news is that the OSD is displayed properly on the monitor even if input is garbled and the picture is 4:3 (monitor detects 1066x800). That means both my monitor (and hopefully others) and the HDMI TX in the OSSC can handle it .

Darry77 commented 4 years ago

Come to think of it, a fully "custom" 384p/400p mode that allows setting manually both horizontal and vertical multiplication level along with sampling would let people design the modes they want (within constraints of what OSSC can do). Concept could be applied to other modes as well.

marqs85 commented 4 years ago

Cyclone IV PLLs impose some limitations as their lock range and multiplication factor is cumbersome to control dynamically. This is much improved in the upcoming Pro model. There has been some performance improvements recently, though, which should make 1600x1200@70Hz more likely to display without issues.

Darry77 commented 4 years ago

Thank you . Are those recent improvements you mention present in the test build mentioned here ? https://github.com/marqs85/ossc/issues/47#issuecomment-639017939

marqs85 commented 4 years ago

Not yet. An official fw will be released soon which includes them.

Darry77 commented 4 years ago

Thank you for your hard work on 0.86 . Unfortunately, the optimizations are apparently not sufficient to allow my OSSC unit to display glitch-free 1600x1200@70Hz in 3x mode . Unless further optimizations are possible, I will have to wait for OSSC Pro for a more perfect solution . In the mean time, I use the OSSC in pass-through mode connected to a CYP CP-254 DVI/DVI scaler that supports 70Hz in an out and allows intermediate scaling to 1024x768@70Hz which, when fed to my monitor, maintains 4:3 aspect ratio . This temporary solution, which lacks the sharpness of OSSC 3x, will hopefully tide mo over until OSSC Pro .