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: libretro/RetroArch#14441

[antonioginer]

Hi cyberluke,

arcade_15 and generic_15 are not the same. arcade_15 has a wider horizontal frequency range. These presets are needed for arcade systems. Most arcade systems had non-standard refresh rates.

Your custom preset is perfectly fine for emulating consoles, though.

Interlaced modes are problematic to make look fine on some screens. I don't think it's a matter of having an exact 50 Hz match (in fact you don't have it in either of your examples, because the pixel clock shown is just an approximation of the final value the hardware actually produces).

The problem probably has to do with vertical fields parity. Some monitors are sensitive to some combinations of even/odd fields. It also depends on the gpu hardware, as we're finding lately.

From your post in RA's repo, you have:

This looks BAD:
Modeline “704x576_50i 15.677190KHz 50.006985Hz” 14.344628 704 733 800 915 576 583 589 627 interlace -hsync -vsync
This looks OK:
Modeline “704x576_50i 15.625000KHz 50.000000Hz” 13.531250 704 724 788 866 576 582 587 625 interlace -hsync -vsync

I notice that in the first case, you have an odd vbegin field. In the second case, vbegin is even. So, I'd try this: change the first modeline to make vbegin even, and force SR to use it to see if that's the problem:

Edit switchres.ini, and change the line modeline auto to: modeline “704x576_50i 15.677190KHz 50.006985Hz” 14.344628 704 733 800 915 576 584 589 627 interlace -hsync -vsync

[cyberluke]

I understand the difference between generic_15 and arcade_15, but generic_15 is currently not for NTSC+PAL TV such as Sony PVM.

I am not emulating consoles. I am emulating Amstrad CPC, ZX Spectrum, Nintendo, Super Nintendo and PS1. With that in mind, my fix above resolves the issue.

I have experimented with all switchres.ini configuration, including combinations. Total work spent of 40 hours. Including the odd fix for AMD GPU (interlace_force_even 1). I'm using CRT EmuDriver, so you probably know that I have AMD GPU as well as Windows 10.

The modeline you say look bad is generated by your library!
704x576_50i 15.677190KHz 50.006985Hz

I did not create it!

This happens when using your generic_15 preset as I pointed out. So that preset is not good, not correct. It generates out of spec PAL interlaced resolution. Therefore that is probably what this bug should be mainly about.

So you want me now to change back to generic_15 preset and add modeline “704x576_50i 15.677190KHz 50.006985Hz” 14.344628 704 733 800 915 576 584 589 627 interlace -hsync -vsync to switchres.ini and it will use that when generating modelines on the fly?

[cyberluke]

Also if you watch my whole video, the conclusion was that it is also helpful to set interlace 0 in switchres.ini as for Amstrad CPC it will choose 288p instead of 576i when rounding from 272p. Therefore providing much better result out of the box. Interlaced should be enabled only for game consoles (mostly PS2 and similar) that produce 480i output. Yes, it will print warning about stretching, but that is like 0.976 and the result look same as interlaced with jumping flickery vertical line, but without the flickering.

[cyberluke]

This is very interesting! I don't think it's a matter of having an exact 50 Hz match (in fact you don't have it in either of your examples, because the pixel clock shown is just an approximation of the final value the hardware actually produces). - I found some modelines generators online, but only for 31kHz. Is there some tool?

Or can you share modeline that would be exact 50 Hz match as well, so I can compare it with the findings here?

I tried to use ArcadeOSD as well, but changing values will only adjust V Size and H Size. It never changes the actual refresh rate when choosing Test in the menu. I believe it might be some additional bug. Therefore I had to always play with switchres.ini and do full application start and exit.

[cyberluke]

BTW interlace_force_even 1 only inverts the lines of the text that are 'jumping'

[antonioginer]

Cyberluke,

Please I beg you to follow my instructions above, to see if we can get some useful information to improve SR.

I know the modelines were created by SR. I'm just trying to understand why some values look good in your monitor while some do not.

Please keep in mind this is NOT a bug. Those modelines look perfect on other CRTs. But we could try to circunvent the issue if we understood the reason why some monitors (or combinations of gpu+monitor) don't play well with interlaced modes.

Or can you share modeline that would be exact 50 Hz match as well, so I can compare it with the findings here?

You can't get 50 Hz exactly due to limitations in the accuracy of real world pixel clocks. But don't focus on that. Monitors don't care about those tiny deviations.

[cyberluke]

Ok, I will use generic_15 in switchres.ini and change the modeline from auto to the specific one you supplied.

Sidenote:
I don't agree those modelines look perfect on other CRTs. I have Sony PVM 20L2, tried also 20M2 last year (different calibration menu, same issues). Today I will have 14M2 and also some JVC semi-professional TV. So I will verify that. So far all CRTs show same symptoms. I would only agree that it would look perfect on arcade CRTs. So my assumption is based on this product as a whole product line, not only one specific device with different calibration.

Sidenote 2:
Here is a video of calibration of that TV. Here is interesting part about deflection. You see when the menu text becomes distorted. I have already resolved that. But it is needed to tweak it sometimes, when the resolution will change. Inside TV there is some center knob (he shows it in 20 seconds) - that could also help a little in some cases.
https://youtu.be/o-MquBghtDg?t=354

[cyberluke]

First it did not switch to that modeline.

I had to disable modeline generation otherwise it would say that no suitable modeline found and will not even switch it.

# Enable on-the-fly generation of video modes
	modeline_generation       0

Now it switches, but it still have issues:

[libretro-cap32]: Got size: 768 x 272 (s4 rs417792).
[INFO] [CRT]: Requested Resolution: 768x272@50.006985
[INFO] [CRT]: Current running core cap32
[INFO] sr_refresh_display: no refresh required
[INFO] set_desktop_mode: \\.\DISPLAY2 (352x576@51) flags(2)
[INFO] sr_switch_to_mode: successfully switched to 352x576@51.108589
[INFO] [CRT]: Resolution is stretched. Fractal scaling @ X:0.458333 Y:2.117647
[INFO] [CRT]: Setting Aspect Ratio: 0.611111
[INFO] [CRT]: Setting Video Screen Size to: 352x576
[INFO] [Video]: Setting refresh rate to: 51.109 Hz.

The refresh rate is different and it does not print what modeline it wants to use.

Can you be more specific how to force that particular modeline with that particular refresh rate?

[cyberluke]

Ok, another bug:

This has to be set to auto:

crt_range0                auto
crt_range1                auto

Even comment says it will be applied only when monitor=custom. It is applied even when monitor=generic_15.

Now it is not flickering, but the vertical refresh rate seems to be calculated on its own (probably should not matter as you say):

[INFO] [CRT]: Requested Resolution: 768x272@50.006985
[INFO] [CRT]: Current running core cap32
[INFO] Switchres: Modeline "704x576_50i 15.677000KHz 50.006380Hz" 14.344628 704 733 800 915 576 584 589 627 interlace  -hsync -vsync
[INFO] sr_refresh_display: no refresh required
[INFO] set_desktop_mode: \\.\DISPLAY2 (704x576@50) flags(2)
[ERROR] ChangeDisplaySettingsExA error(fffffffe)
[ERROR] sr_switch_to_mode: error switching to mode
[INFO] [CRT]: SR failed to switch mode[INFO] [CRT]: Resolution is stretched. Fractal scaling @ X:0.916667 Y:2.117647
[INFO] [CRT]: Setting Aspect Ratio: 1.222222
[INFO] [CRT]: Setting Video Screen Size to: 704x576
[INFO] [Video]: Setting refresh rate to: 50.006 Hz.
[INFO] [Video]: Frame delay reset to 1.

But there is some error and resolution is stretched, so it looks much worse than any other case. Also TV reports it is in 480/60i mode, while it should be in 576/50i mode - that's why I don't see it flickering.

Screenshot from iPad below:

[cyberluke]

[cyberluke]

Basically I cannot force any modeline, same error here with previously OK settings:

monitor                  generic_15
	crt_range0                auto
	crt_range1                auto
modeline                  modeline "704x576_50i 15.625000KHz 50.000000Hz" 13.531250 704 724 788 866 576 582 587 625 interlace -hsync -vsync
refresh_dont_care         1
modeline_generation       1
interlace                 1
sync_refresh_tolerance    1.00

LOG output

[INFO] Switchres: Modeline "704x576_50i 15.625000KHz 50.000000Hz" 13.531250 704 724 788 866 576 582 587 625 interlace  -hsync -vsync
[INFO] sr_refresh_display: no refresh required
[INFO] set_desktop_mode: \\.\DISPLAY2 (704x576@50) flags(2)
[ERROR] ChangeDisplaySettingsExA error(fffffffe)
[ERROR] sr_switch_to_mode: error switching to mode

[antonioginer]

You wrote:
modeline modeline "704x576_50i 15.625000KHz 50.000000Hz" 13.531250 704 724 788 866 576 582 587 625 interlace -hsync -vsync

Instead, you have to write:
modeline "704x576_50i 15.625000KHz 50.000000Hz" 13.531250 704 724 788 866 576 582 587 625 interlace -hsync -vsync

[antonioginer]

Obviously, the interlace option in switchres.ini must be enabled.

Even comment says it will be applied only when monitor=custom. It is applied even when monitor=generic_15.

No.

[cyberluke]

Ah, my mistake! :-)

Settings 1:
modeline "704x576_50i 15.625000KHz 50.000000Hz" 13.531250 704 724 788 866 576 582 587 625 interlace -hsync -vsync
LOG:

[INFO] [CRT]: Requested Resolution: 768x272@50.006985
[INFO] [CRT]: Current running core cap32
[ERROR] Switchres: could not find a video mode that meets your specs
[INFO] sr_switch_to_mode: switching not required

Settings 2:
modeline "704x576_50i 15.677190KHz 50.006985Hz" 14.344628 704 733 800 915 576 584 589 627 interlace -hsync -vsync

LOG:

[INFO] [CRT]: Current running core cap32
[INFO] Switchres: Modeline "704x576_50i 15.677000KHz 50.006380Hz" 14.344628 704 733 800 915 576 584 589 627 interlace  -hsync -vsync
[INFO] sr_refresh_display: no refresh required
[INFO] set_desktop_mode: \\.\DISPLAY2 (704x576@50) flags(2)
[ERROR] ChangeDisplaySettingsExA error(fffffffe)
[ERROR] sr_switch_to_mode: error switching to mode
[INFO] [CRT]: SR failed to switch mode[INFO] [CRT]: Resolution is stretched. Fractal scaling @ X:0.916667 Y:2.117647
[INFO] [CRT]: Setting Aspect Ratio: 1.222222
[INFO] [CRT]: Setting Video Screen Size to: 704x576
[INFO] [Video]: Setting refresh rate to: 50.006 Hz.
[INFO] [Video]: Frame delay reset to 1.

Same result, in the end.

[cyberluke]

[cyberluke]

# Enable on-the-fly generation of video modes
	modeline_generation       1

# Allow interlaced modes (existing or generated)
	interlace                 1

[cyberluke]

In those cases, I often open VMMaker, delete all existing modelines. Create my custom modelist.txt - change that one specific timing for that specific resolution. Export modelist.txt to the driver. Disable modeline generation in switchres.ini => then it might use it, but will probably throw the same error.

[antonioginer]

It should be setting the modeline in switchres.ini.

Could you post the full log, using this modeline "704x576_50i 15.677190KHz 50.006985Hz" 14.344628 704 733 800 915 576 584 589 627 interlace -hsync -vsync

[cyberluke]

Full log - first is boot to RetroArch menu. Second is running Amstrad CPC emulator hence two times switching to modeline.
full_log_1.txt

Switchres.ini (renamed to txt for uploading here)
switchres.txt

[cyberluke]

Attaching DEBUG logs (switchres.ini verbosity=3). Sometimes it crash, sometimes it hangs up, but mostly it works.
full_log_2_verbosity_3.txt

[antonioginer]

Thanks, I can see where the problem is. RA's SR version is old, there was a bug in the modeline to crt_range function. That's now been fixed in SR, but not in RA yet.

You're getting:
Switchres(v2.002) display[0]: monitor[generic_15] generation[on] SwitchRes: user modeline "704x576_50i 15.677000KHz 50.006380Hz" 14.344628 704 733 800 915 576 584 589 627 interlace -hsync -vsync Switchres: Monitor range 0.00-0.00,0.00-0.00,2.022,4.671,8.017,0.510,0.319,2.424,0,0,0,0,576,576
You should be getting:
Switchres: display[0] options: monitor[generic_15] generation[on] SwitchRes: user modeline "704x576_50i 15.625000KHz 50.000000Hz" 13.531250 704 724 788 866 576 582 587 625 interlace -hsync -vsync Switchres: Monitor range 15562.50-15687.50,49.80-50.20,1.478,4.730,5.764,0.192,0.160,1.216,0,0,0,0,576,576

[antonioginer]

So, forget about SR/RA by now.

Please user Arcade OSD by now.

Select this text modeline "704x576_50i 15.677000KHz 50.006380Hz" 14.344628 704 733 800 915 576 584 589 627 interlace -hsync -vsync

Press CTRL+C

Launch Arcade OSD, and select Get mode from clipboard.

[cyberluke]

1. This modeline does not seem to be a solution, the original PAL works better.
2. ArcadeOSD version is 2.0 beta 15 (should be latest, downloaded from Calamity’s forum thread)

adjusting V retrace end does not have any visible impact - the issue is the dotclock 14.344626 - that is out of spec for PAL, 15.625kHZ. That is for arcade crt maybe.

changing dot clock somewhere around 14.20mhz equals to 15.570khz and that is better. But it is still not exactly PAL spec 15.625khz. I cannot get to it.

[cyberluke]

this gives better results

[cyberluke]

But I need to tweak it, it still does not match exactly to PAL specification, which seems to be very important for interlaced modes.

[antonioginer]

This modeline is not the one I asked you to test. Did you use the Get mode from clipboard option?

[cyberluke]

Yes, I did, but it did nothing. ArcadeOSD is buggy as well. I'm going to clone RetroArch repo, replace their old SwitchRes source files, download MingW compiler and dependencies and recompile everything myself. That will be faster. I have experience only with Java, Python, Visual Studio (C++ and .NET and Windows kernel driver compilation), so I don't have mingw currently installed.

[antonioginer]

Could you please help me to find the root of this problem?
Can you please follow my instructions with Arcade OSD?

[cyberluke]

Ok, I'm recording video right now....

[antonioginer]

Get mode from clipboard didn't work because the existing mode label in the system is 704x576@51. We have to match our modeline label with that, so the modeline is loaded in that "slot". Copy this text with CTRL+C:

modeline "704x576@51i 15.677000KHz 50.006380Hz" 14.344628 704 733 800 915 576 584 589 627 interlace -hsync -vsync

Then use Get mode from clipboard in Arcade OSD

[antonioginer]

Ok perfect.

Now, with that modeline set, do you still have the same problem?

[cyberluke]

Yes, I have. I'm trying to tweak V retrace Start and V reatrace End values as you said.

For reference, this is the original PAL modeline that is ok:
"704x576_50 15.62KHz 50.00Hz" 13.62 704 728 792 872 576 582 587 625 interlace +hsync +vsync

The biggest difference is adjusting the dotclock from 14.34 to 13.62. That solves the flickering. The retrace stuff does not seem to make any visible change.

[cyberluke]

Ah, got it! I had to change V total from 627 to 625 and it is better now. PAL must have 625 lines.

[cyberluke]

V retrace start and end can be 584 and 589 or 582 and 587. That does not matter. 583 and 590 does not matter as well. The only thing that matters is to have total number of lines 625.

[antonioginer]

Ok

I need you to set the original modeline: "704x576@51i 15.677000KHz 50.006380Hz" 14.344628 704 733 800 915 576 584 589 627 interlace -hsync -vsync

And when you have it on the screen, send me a message back saying: Antonio, I have it on the screen, tell me what to do.

This is my last attempt :)

[cyberluke]

Ok ok! :-)

I was expecting Generic_15 will generate 525 lines for NTSC and 625 lines for PAL as it is mentioned here in dropdown menu. But it generates 523 for NTSC and 617 for PAL

[antonioginer]

PAL and NTSC are broadcast standards. They are meaningless for us.

It's only due to a (theoretical) limitation in your monitor's hardware/firmware that deviations might matter.

The generic_15 preset doesn't follow any standard, it just tries to meet the limits defined in the preset.

[cyberluke]

Antonio, I have it on the screen, please tell me what to doooo

[antonioginer]

Ok.

First experiment: go back to Vertical Geometry, and try moving de picture up and down, one line by one line.

Expected result (based on your previous comments): no change in flicker.

Let me know when you finish.

[cyberluke]

Yes, Antonie, that’s right. Changing V center in Vertical geometry menu by one step in range +5 and -5 produce same results.

[cyberluke]

but it was possible to get a working combination if V total equals to 625

[antonioginer]

Ok, please go back to starting point, and let me know.

[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.