Scaler

[JamesF]

@profd

Code: Select all

video_mode=2560,48,32,80,1440,3,5,33,241699

That's from Nvidia custom resolution, CVT reduced blank.

[Grabulosaure]

@profd

Code: Select all

video_mode=2560,48,32,80,1440,3,5,33,241699

That's from Nvidia custom resolution, CVT reduced blank.

The hardware, both the FPGA and HDMI encoder, can barely reach 200MHz (which is far better than expected, and beyond the datasheet specs.). Mister software enforces 200MHz as max. freq.

Independently from that, there is a limit on horizontal resolution, around 2040 pixels (not exactly 2048, because prefetching, rubber elasticity, lunisolar precession, ...). To go beyond that, the cores must be recompiled with .OHRES(4096) as a parameter to the scaler (without that, it shows a clipped image).

[Sorgelig]

the cores must be recompiled with .OHRES(4096) as a parameter to the scaler (without that, it shows a clipped image).

This will double the BRAM usage by scaler which is too much. And since frequencies beyond 200MHz are unreal for ADV7513 (165MHz max from datasheet), there is no point to compile with 4096.

[Sorgelig]

Currently there are no cores which can output native resolution higher than 1280x720. So there is no point to set output resolution to 2K or 4K.
It's enough to set 1/4 resolution of your TV, so for 2560x1440 TV it's enough to set 1280x720 and let the TV to do integer 2x scale. So no artifacts will be added by such scale (if you will set appropriate video type in TV settings).
The same for 4K 3840x2160 TV you can use 1920x1080 resolution with 2x integer scale by TV.

[bitfan2011]

Currently there are no cores which can output native resolution higher than 1280x720. So there is no point to set output resolution to 2K or 4K.
It's enough to set 1/4 resolution of your TV, so for 2560x1440 TV it's enough to set 1280x720 and let the TV to do integer 2x scale. So no artifacts will be added by such scale (if you will set appropriate video type in TV settings).
The same for 4K 3840x2160 TV you can use 1920x1080 resolution with 2x integer scale by TV.

Yeah, I changed the.ini to 1280x1024 for use with my 1600x1200 displays. 1:1 mode looks super clean, so I can always do aspect scaling via the display to fill the screen. 5x scaling can look great IMO, but too sharp for some people when using scanlines. I guess they like a tiny amount of blur.

[Newsdee]

Implementing filters on an emulator to post-process dithering

Do you have any link ? I don't quite understand.
A design limitation is that horizontal and vertical interpolations are separate, it's two vectors, not a matrix.

I dug a bit deeper and it's the gdapt and mdapt shaders found in Retroarch. Here is a writeup about them: https://forums.libretro.com/t/mdapt-gda ... -06-14/375

[Grabulosaure]

I dug a bit deeper and it's the gdapt and mdapt shaders found in Retroarch. Here is a writeup about them: https://forums.libretro.com/t/mdapt-gda ... -06-14/375

Looks nice.

If it keeps the original resolution, it could be rather implemented as something upstream from the scaler, like the HQ2x effects, and added only on cores where it is useful. Using it upstream allows to limit buffer sizes to the source resolution and run at lower frequency than the scaler.
Seems doable.

[paulbnl]

Mostly the low latency vsync_adjust=2 has been working well but sometimes there is tearing in the middle of the screen. Usually after a few minutes or sometimes from the start.

Also a lot of times the scaler will just output a single color screen (mostly black) and I have to reboot the system to make it work again. The menu still works when that happens.

[JamesF]

Are you sure vsync_adjust=2 is working now with all cores?
I think you need the special cores by Grabulosaure to activate the low latency mode, the official cores do not support low latency mode yet, afaik.
If I understood Grabulosaure correctly, the current implementation is triple buffered hence 1-3 frames of lag.

edit:
I can't find any information on what the vsync_adjust=2 mode does, maybe the PLL discussion earlier in this thread is somehow related.
If I understood correctly this mode will align the sync signals from the core and scaler, thus removing tearing from the visible region while working with a single buffer.

@ Grabulosaure, Sorgelig
Can you please clarify what the vsync_adjust=2 mode actually does?

[paulbnl]

Are you sure vsync_adjust=2 is working now with all cores?
I think you need the special cores by Grabulosaure to activate the low latency mode, the official cores do not support low latency mode yet, afaik.
If I understood Grabulosaure correctly, the current implementation is triple buffered hence 1-3 frames of lag

At least NES and SNES have been updated with low latency scaler.

In MiSTer.ini it is said that vsync_adjust =2 uses a single buffer.

[cacophony]

Are you sure vsync_adjust=2 is working now with all cores?
I think you need the special cores by Grabulosaure to activate the low latency mode, the official cores do not support low latency mode yet, afaik.
If I understood Grabulosaure correctly, the current implementation is triple buffered hence 1-3 frames of lag

At least NES and SNES have been updated with low latency scaler.

In MiSTer.ini it is said that vsync_adjust =2 uses a single buffer.

I don't think it's actually working yet with vsync_adjust =2 and the release cores based on my testing and conversations with Grabulosaure.

These were the instructions that I got from Grabulosaure on 12/26:

"I have posted on temlib.org/pub/mister/ascal a version of SNES which blinks LEDs when buttons are pressed. The low lag mode has issues with the default settings with 148.5MHz clock, if you need 1920x1080@60Hz, use instead something like "video_mode=1920,48,32,80,1080,123,6,26,154130" . Select NTSC, no triple buffer, no vsync_adjust."

I did confirm that it seemed to work with that special LED build after following those instructions.

[JamesF]

paulbnl is right,, if you look at the update changlog thread you will see "Update the Scaler" where Sorgelig added pll_hdmi_adj.vhd file which is responsible for the low latency mode according to two pages discussion on this thread about PLL.
You can find this file in /sys/ directory in each core source code so you know which one has this feature.
So far Snes, Nes, Genesis, Turbografx16, Amiga, C64 definitely have been updated with low latency mode.

I should say low latency mode works quite nice aside from the occasional bugs paulbnl already mentioned.

[Grabulosaure]

vsync_adjust=2 is experimental.
The version of hdmi_pll_adj (which tweaks the PLL frequency continually to align signals) currently in use was only really tested on Genesis/Megadrive (outputting the syncros on the SDRAM bus, and checking with a scope...). It doesn't work well with some frequency settings, has very slow convergence. And it is very difficult to know if it really works without an oscilloscope, or two CRTs connected to HDMI and analog out and a fast camera, ...

I will post an updated version of hdmi_pll_adj with the fixes to the scaler (line on the right, 30Hz interleaved video).
It will hopefully work better.
[Maybe one of the 8 LEDs on the DE10 could be used as a visual indication of synchro. state]

[paulbnl]

I don't think it's actually working yet with vsync_adjust =2 and the release cores based on my testing and conversations with Grabulosaure.

These were the instructions that I got from Grabulosaure on 12/26:

"I have posted on temlib.org/pub/mister/ascal a version of SNES which blinks LEDs when buttons are pressed. The low lag mode has issues with the default settings with 148.5MHz clock, if you need 1920x1080@60Hz, use instead something like "video_mode=1920,48,32,80,1080,123,6,26,154130" . Select NTSC, no triple buffer, no vsync_adjust."

I did confirm that it seemed to work with that special LED build after following those instructions.

I think what you are talking about is a separate low latency mode.

I have made photos with the HDMI vsync_adjust=2 output to a LCD monitor and a CRT connected to the VGA output and the latency varies between 0 and 1 frames max.

[cacophony]

I don't think it's actually working yet with vsync_adjust =2 and the release cores based on my testing and conversations with Grabulosaure.

These were the instructions that I got from Grabulosaure on 12/26:

"I have posted on temlib.org/pub/mister/ascal a version of SNES which blinks LEDs when buttons are pressed. The low lag mode has issues with the default settings with 148.5MHz clock, if you need 1920x1080@60Hz, use instead something like "video_mode=1920,48,32,80,1080,123,6,26,154130" . Select NTSC, no triple buffer, no vsync_adjust."

I did confirm that it seemed to work with that special LED build after following those instructions.

I think what you are talking about is a separate low latency mode.

I have made photos with the HDMI vsync_adjust=2 output to a LCD monitor and a CRT connected to the VGA output and the latency varies between 0 and 1 frames max.

Maybe things have changed but on 12/26 when I did some tests with a 240fps camera I was getting an additional lag of 2 frames with vsync_adjust=2 compared to the instructions I quoted above. Perhaps I should retest with latest software.

[JamesF]

@cacophony
If you look at the changelog you'll see that most cores (including Genesis) have been updated with pll_hdmi_adj.vhd on Dec 31, so vsync_adjust=2 didn't do anything on the Genesis core back in Dec 26.
Also, as Grabulosaure said, the convergence (synchronization) time is slow on other cores besides Genesis, but he's working on it, hence the experimental label.

[cacophony]

@cacophony
If you look at the changelog you'll see that most cores (including Genesis) have been updated with pll_hdmi_adj.vhd on Dec 31, so vsync_adjust=2 didn't do anything on the Genesis core back in Dec 26.
Also, as Grabulosaure said, the convergence (synchronization) time is slow on other cores besides Genesis, but he's working on it, hence the experimental label.

Yep, makes sense.

I don't have a good way to compare to Genesis, but I just did comparisons for NES and SNES, relative to the Nt Mini and SNT connected to the same display. I used the updater script to update everything first (including the kernel, the linux filesystem and bootloader), and did the setting as recommended in the config file (vsync_adjust=2, and FWIW video_mode=8).

For NES the results were near identical in terms of lag, and for SNES the MiSTer was somewhat laggier. But as you say, this convergence issue is known and it's being worked on

[JamesF]

@Grabulosaure

I've tested your Jan 17th Ascal Genesis build.
Interlaced mode works in 60fts so that is a success, but with vsync_adjust=1 when going back from interlaced to progressive the 240p image seems to be still interlaced but with much thicker scanlines.
With vsync_adjust=2 going back from interlaced works correctly.

[JamesF]

Thank you.
In your Jan 18th build of Genesis I confirm you fixed the interlaced->progressive transition.

Also the "VDP: Fix H40 mode line length" commit will probably fix the drops between 256 and 320 horizontal modes.
You can test the drops between 320 and 256 modes in the intros of Contra: Hard Corps, and Mortal Kombat 3, using the video_info option.
Mortal Kombat 3 changes the resolution almost every screen from intro to the actual fight.

It would be great if the Genesis core would run close to its original speed of 59.92274Hz (source) instead the current 60.3Hz.

EDIT:
I also don't see tearing in 480i with vsync_adjust=2 in this test version, well done sir!

[SegaMan]

Not shure if it is the right place, sry if not!

After the last update (menu and mister) i got crap picture in mister menu (1080p).
In cores the menu is ok.

[JamesF]

del

[Sorgelig]

Why everybody post everything in this topic?!
Stop it already. This thread is for developers only. Problems with cores must be posted in respective topics!

[Sorgelig]

I see there is new ascal release but no words what has been changed/added.

[JamesF]

The current low-lag implementation in all cores didn't work.

I'll quote Grabulosaure on Discord on Jan.22nd:

I've just discovered that the low-lag mode and HDMI_PLL_ADJ isn't correctly instantiated in Sorgelig builds (SNES,NES,Genesis, Minimig,ao486, ...). There is a missing signal (lltune) : vsync_adjust=2 doesn't work, it behaves just like vsync_adjust=1

Grabulosaure fixed and updated the scaler, which seems to be working great in his test builds.
I would also like to hear from Grabulosaure about the actual changes.

I assume working operation remained the same as here:

For the low lag mode, there is frequency and phase adjustments.
Each time the input video mode is changed, that thing modifies timing to align the input and output video modes, generating a few wacky frames.
There are two options :
- Either the core tries to get signal aligned quickly, it lasts 2..3 seconds to align and a bit more time before the screen will eventually display an image (this is the current implementation).
- Or tuning is done very slowly (10...30 seconds) to allow the screen to [hopefully] never loose sync and keep displaying an image, with eventual tearing due to desynchronisation.

[Sorgelig]

I'll quote Grabulosaure on Discord on Jan.22nd:

Discussing about it on the place where i'm not present is so wise, yeah...

Don't know what's the problem with Grabulosaure. He doesn't want to communicate with me, and instead do this on places where i won't see.