Switchres should use correct monitor type and alter between NTSC and PAL properly

[cyberluke]

I have identified the issue in SwitchRes, including RetroArch dependency SwitchRes and recorded Youtube video.

Here I present the cause as well as solution!

But further development will be probably necessary to provide a better user experience and configuration properties.

https://www.youtube.com/watch?v=Xv5u-JPKDS0

In a nutshell: generic_15 and arcade_15 are now the same, which does not make any sense.

arcade_15 has different frequency range than regular NTSC/PAL

generic_15 should encapsulate regular NTSC/PAL frequencies, which it currently doesn't.

Acceptance criteria: generic_15 profile will use 15.625000KHz 50.000000Hz for PAL resolutions and 15.73KHz 59.94Hz for NTSC

Initialy I started my bug hunt here: https://github.com/libretro/RetroArch/issues/14441

[cyberluke]

We have a starting point, screen is refreshed and fresh to go Antonio :-)

[antonioginer]

Nice.

Now, set Lock Vfreq to yes.

Go back to Edit modeline menu, and test these V total values: 624, 625, 626

[cyberluke]

623 - shaking 30% 624 - shaking 70% 625 - no shaking, but of course you still see redrawing of vertical lines - probably because of interlaced resolution or some kind of rounding error - I was thinking I would fix this in software by adjusting each odd frame by Y+1. The vertical refresh rate is 49.991Hz. I would like to see 50.000Hz for a peace of my mind :-D …but I know it is aproximation as you said 626 - shaking 70% 627 - shaking 70%

[antonioginer]

Ok. What if you go below 623? E.g. 621, 622?

[cyberluke]

I tried to go down to 613. Some of them shake a lot, some of them shake less. But none of them gives same results as 625. With 625 lines, it has currently the best properties.

[antonioginer]

Good.

Next test. Back to the starting point. Now we're going to check whether it's Vfreq dependent or not.

Edit Modeline-> set Vtotal to 625 Unlock Vfreq

Start increasing the dotclock, and go testing values. Increase it a lot too until you reach 52 or 53 Hz and test.

See if the variation of vfreq, while keeping v total constant, has an effect on flicker.

[cyberluke]

Of course with non-interlaced resolutions you can play these tricks and it will be ok. But I guess for interlaced resolution you want to have total number of lines by the spec. Also this is a regular professional broadcast monitor calibrated for that, it is not arcade monitor.

ok, will do, thank you Antonio

[cyberluke]

So adjusting dotclock moves V Hz as well as H kHz

Regarding the vertical: 52hz - it goes out of sync completely 51.79hz - image gets skewed at the top, probably needs some calibration adjustment inside TV - yes adjusting a value of deflection circuit provides a solution (Deflection HFV Control in TV menu)

I went down to 48hz and it was ok.

In the extreme cases, adjusting Deflection HFV Control helped. But V total lines needs to be 625. When changing V total lines to anything else than 625, even adjusting deflection parameters on TV will not help. That was the first thing I always tried.

So I would say it is not Vfreq dependant.

[antonioginer]

So, despite going out of sync on extreme cases, and other geometry distorsions, the flicker didn't change?

[cyberluke]

Correct, did not change.

[antonioginer]

Ok, thanks for doing these tests.

So, it looks like, as you said, your monitor requires exact 625 vtotal to handle interlace correctly. Keep in mind that this is a feature of this monitor. Other monitors or consumer TVs are perfectly happy with random vtotal values.

Now, the problem is SR has no method for setting a fixed vtotal. In fact, vtotal is a free field that is used in its computations to match the target refresh.

So, the only way to set a fixed vtotal is through the pal/ntsc presets, that are extremely limited and useless in practice. But since the purpose of this is only addressing the issue with interlaced modes, we can make a combination of pal and ntsc, as you already did, but only for interlaced modes, and use generic_15 for progressive modes. It would look like this:

        crt_range0 15625-15750, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 1, 1, 192, 288, 0, 0
        crt_range1 15625.00-15625.00, 50.00-50.00, 1.500, 4.700, 5.800, 0.064, 0.160, 1.056, 1, 1, 0, 0, 448, 576
        crt_range2 15734.26-15734.26, 59.94-59.94, 1.500, 4.700, 4.700, 0.191, 0.191, 0.953, 1, 1, 0, 0, 448, 480

[cyberluke]

Ok, thank you very much Antonio.

I just got JVC TM-A10E-K 10'' (PAL only, 50Hz) and Sony PVM 14M2 today. So I will retest on these.

I would not be surprised if this issue occurs on more TVs. For example I tried to survive this for a year and was thinking that this is happening because interlaced resolution is like that by default.

It would be great if these three ranges could be a part of some new profile for NTSC+PAL professional TVs such as Sony PVM.

Now I need to focus on a code somewhere else, but I will retest everything once more, probably during the weekend.

[cyberluke]

I just briefly check Amstrad CPC emulator boot and it looks better. Beware that there is additional issue that applies to SwitchRes in general:

This mode 768x272@50.006985 always switched into 576i. Just as of now, using three ranges above in Switchres.ini results in 704x288@50.006985.

Now I verified: changed to generic_15 instead of custom in switchres.ini and I get this: Switchres: normal (768x272@50.006985)->(704x576@50.006985)

I would say this is definitely another bug that will apply to all users.

The stretching happens in both configurations: 288p has this stretching [INFO] [CRT]: Resolution is stretched. Fractal scaling @ X:0.916667 Y:1.058824 576i has this stretching: [INFO] [CRT]: Resolution is stretched. Fractal scaling @ X:0.916667 Y:2.117647

The algorithm should favor the first stretching case Y~=1 is better than Y~=2

[antonioginer]

Make sure you have restored modeline auto in switchres.ini.

Once you do that, if things keep behaving strange for 768x272, please post a full log.

[cyberluke]

Yes, of course I have restored modeline to auto and this is happening always. In fact this is the reason why I discovered 576i mismatch - because the emulators keep switching to it quite often in some cases. I will post full log tomorrow.

[cyberluke]

Hi Antonio, I'm sharing a full debug log. When using generic_15 profile, with default switchres.ini configuration, it will choose incorrect priority modeline. It will choose 576i while it should select 288p.

It will select correct 288p only if: 1) if I disable interlaced resolution in switchres.ini 2) if I use custom profile for NTSC/PAL we tested above

It happens only for some emulators. For example ZX Spectrum (Fuse) is OK. While Amstrad CPC is not ok and this log contains that one:

invalid_modeline_priority.txt

[cyberluke]

Tested using latest stable Retroarch 1.19.1 (released two weeks ago), this configuration works the best for me:

monitor.ini

monitor "sony", "Sony PVM NTSC/PAL", "4:3"
        crt_range0 15625-15750, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 1, 1, 192, 288, 0, 0
        crt_range1 15625.00-15625.00, 50.00-50.00, 1.500, 4.700, 5.800, 0.064, 0.160, 1.056, 0, 0, 192, 288, 448, 576
        crt_range2 15734.26-15734.26, 59.94-59.94, 1.500, 4.700, 4.700, 0.191, 0.191, 0.953, 0, 0, 192, 240, 448, 480

user_modes.ini

## Desktop ##

 640 x 480 @ 59.94 desktop

## Family Computer - Nintendo Entertainment System ##

 256 x 240 @ 60.098000 famicom

## Mark III - Master System ##

 248 x 192 @ 60.000000 mastersys
 256 x 192 @ 60.000000 mastersys

## PC Engine - Turbo Grafx ##

 336 x 224 @ 60.000000 pcengine
 544 x 242 @ 59.922743 pcengine

## Mega Drive - Genesis ##

 256 x 224 @ 60.000000 megadrive
 320 x 224 @ 60.000000 megadrive

## Super Famicom - SNES ##

 256 x 224 @ 60.098475 superfam
 256 x 239 @ 50.000000 superfam
 512 x 478 @ 25.000000 superfam
 512 x 448 @ 30.000000 superfam

## PC-8800 ##

 640 x 200 @ 60.000000 pc88

## PC-9800 ##

 640 x 400 @ 59.94 pc98

## Sharp X-68000 ##

 256 x 240 @ 55.450000 x68000
 256 x 256 @ 55.450000 x68000
 512 x 480 @ 55.450000 x68000
 512 x 512 @ 55.450000 x68000
 768 x 512 @ 55.450000 x68000

## Amiga ##

 320 x 256 @ 50.000000 amiga

## Game Boy Advance ##

 240 x 160 @ 59.730000 gba

## Aux. ##

 240 x 200 @ 59.730000 aux
 256 x 244 @ 60.000000 aux
 256 x 240 @ 60.098475 aux
 320 x 240 @ 54.140000 aux
 320 x 244 @ 59.410646 aux
 384 x 240 @ 59.629403 aux

Everything works out of the box and no individual core configuration needed. Amstrad CPC has interlaced PAL mode, NES has NTSC mode, Amiga works as well, etc.