Do switchres monitor presets always display game content in some form?

[nix999]

I have a question about switchres presets such as pal ntsc and arcade_15.

Give that a game has a 'Working' status in MAME is it correct to expect GroovyMAME to show at least some output on screen when launched with a preset.
Using for example
./groovymame inthunt -monitor pal
or
./groovymame inthunt -monitor ntsc
or
...

I have Sony Trinitron PAL SCART television set that is used with a custom build Arch.
I tried to find information about the capabilities of the TV and slightly modified the arcade_15 settings found on
https://gitlab.com/groovyarcade/support/-/wikis/3-Post-Installation-and-Maintenance/3.5-Monitor-Definitions#built-in-monitor-definitions
to fit as much as possible and that range is in mame.ini and the monitor is set to custom.
I set the dotclock_min to 6.0 and tested some games like wboy, toki, sf2, cabal and they all center nicely and run absolutely fine.

Then I found out that my TV cannot display some content even though a valid mode gets calculated. It displays rolling content from top to bottom.
This is the case for mk, mk2, mk3 mk4 and likely others.

Next I made a bash script that reads the names from ./problematic_games.txt and if it is in there I get the refresh rate from the given game's xml and if it is lower then 55hz I launch it with
-monitor pal
and if it is above I launch it with
-monitor ntsc.

The idea is that I use the slightly modified arcade_15 preset to make as much games as possible run native - if I can call it that - and force the exceptions to pal or ntsc the TV can display.

All was fine at that point until ...

What I did not expect is to find games that loose sync on all presets.

From the looks of it they are all NeoGeo games such as In The Hunt and Puzzle Bobble. I tested other games and for one game the TV showed the blue information screen but it also lost sync after.

I do not understand what I am doing wrong.
Any hints about a correct approach please?

Thank you.

[Zebidee]

I've found that many TVs do OK at close to both 60hz or 50hz, but lose sync at close to ~55hz.

This being the case, the default generic_15 and arcade_15 default presets are insufficient as they cover a large range from 49.50hz to 65.00hz, without blocking out the middle frequencies. This means they can generate modes at ~55hz that the TV cannot display.

My solution was to create a custom monitor preset that includes multiple ranges, for both "NTSC" and "PAL". That way you can specify the valid frequencies for each. It looks something like this

monitor "ChinaTV1", "China TV - 50/60 Hz", "4:3"
        crt_range0 15625.00-15750, 49.50-55.00, 1.500, 4.700, 5.800, 0.191, 0.191, 1.056, 0, 0, 192, 288, 448, 576
        crt_range1 15625.00-15750, 55.01-62.00, 2.000, 4.700, 6.200, 0.256, 0.191, 1.200, 0, 0, 192, 248, 448, 480

The above example is what I use with my "China" TV. The switchres driver chooses the most appropriate crt_range based on the maximum number of permitted lines allowed. Each range has a max progressive lines specified, which I've bolded above.

For example: if you chose to launch MK2, which wants 254p, switchres checks the lowest range (crt_range1, "NTSC") first. This allows max 248 progressive lines, or 248p, not enough. So it moves onto the next range (crt_range0, "PAL"), which allows up to 288p, and uses a 256p video mode generated from that range.

You might have noticed that, in the above example, I didn't actually block out any frequencies around 55hz - that is because my "China" TVs are fine with handling 55hz. So why do I even use the split ranges? Because the TVs default to different screen geometries based around "NTSC" and "PAL" signals, and automatically change depending the signal received! By modifying the crt_ranges to align with this, the front/backporch values can be further tweaked to ensure a better "screen fit" for the video modes.

If you wanted to limit video modes to just those close to 50hz and 60hz, and block out most frequencies in-between, you might use a preset like this:

monitor "NTSC/PAL only", "PAL/NTSC 50/60hz only", "4:3"
        crt_range0 15600-15900, 49.50-50.00, 2.000, 4.700, 4.700, 0.064, 0.192, 1.056, 0, 0, 192, 288, 448, 576
        crt_range1 15600-15900, 59.50-61.00, 2.000, 4.700, 5.800, 0.064, 0.192, 0.898, 0, 0, 192, 248, 448, 480

You could even specify PAL for only 50hz exactly, and NTSC for only 59.94hz exactly, if you really wanted to.

The horizontal frequencies specified are less important. I usually just use the same for each crt_range, covering the total for both.

I guess you could specify a preset with three separate sets of crt_range values, hone in on those 55hz modes, but I don't see a compelling reason to do so with TVs - especially given they seem to usually default to "NTSC" or "PAL" modes of operation.

I don't know how Calamity thinks about this, or if this is what was intended - I "improvised" this approach based on existing implementations for dual-sync monitors. Looking at it a certain way, TVs that work for both 50hz and 60hz ARE dual-sync, auto-switching monitors. I don't know if this will work the same for you, but is what I've found works for me. Feel free to tinker, try playing around with it to see what works for you.

** Disclaimer: I use Win7+CRT_emulator+GM, not Retroarch, but I think all the same theory applies.

For further queries, maybe attach a log file.

[Calamity]

Yes, the method explained by Zebidee is how this is supposed to be handled.

Give that a game has a 'Working' status in MAME is it correct to expect GroovyMAME to show at least some output on screen when launched with a preset.

Yes, GroovyMAME will always show some output on the screen. If you have a certain game that goes out of sync, try to find the reason. If you have dotclock issues, 8.0 is a reasonable minimum (rather than 6.0). Note that the lower end of admitted dotclocks may have gaps (i.e. 5.5 may work, 5.6 not, etc.) until you find a number that works fine from there on.

[nix999]

Ok. Thank you for the detailed responses. I'll tinker a bit more and report back. I'll attach a log file if I can't sort it out. It might take some days. Probably next weekend.
One thing I do see is that my system never generates 2560x... modes. It is always much lower though 2560 is in mame.ini super_resolution it's called if I'm not mistaking.
I do not understand why it behaves that way but I'll document it and report back.
I also started from a fresh ini created with ./groovymame -cc.
The dotclock 6.0 is what made Cabal work.
I'm not using RetroArch. It's a bash shell with groovymame 0.280 and some scripts around it.

[nix999]

I got a whole lot further but I'm still not there.

I increased dotclock to 8.0

These two ranges make every game I started thus far run ~100%
crt_range0                15600-15800, 49.50-50.20, 2.000, 4.700, 5.800, 0.064, 0.192, 1.056, 0, 0, 192, 288, 448, 576
crt_range1                15600-15800, 59.30-60.50, 2.000, 4.700, 5.800, 0.064, 0.192, 0.898, 0, 0, 192, 248, 448, 480

The issue I have is that in general the screen is off to the left and too wide.
I can use the slider controls
CRT H size between 0.70 and 0.65
CRT H shift between -2 and -7
Seem to do the trick.
This means I need to adapt every game manually.

I already tried putting them in default.cg but they get stripped it seems. I might need to create a wrapper script to pre-create the cfg files.
I'll look into that a bit further.

But ideally the two ranges should be adjusted to cope with the issue I just described.
I do not succeed unfortunately.

The 2nd issue I have I cannot solve using the slider controls as there is no CRT V size in the slider menu.
If I use MAME's own Screen Vert Stretch combined with MAME's own Screen Vert Position or CRT V shift I get artifacts.
For In The Hunt for example in the bottom to top scrolling monster demo I see the background being re-drawn in a choppy way.

What really happens is that the Top op the screen is correct but the bottom section falls off.
I see for example the top letters in some demo scene perfectly positioned but the bottom score is 75% visible.

Ideally the two ranges should be adjusted to also cope with the issue I just described.
I do not succeed either unfortunately.

If I have to adapt every game for issue 1 so be it. I'd rather avoid to but it is manageable I of course would like to solve it in general.
But the 2nd one is worse ...

Can someone assist in adapting the two ranges I posted please or give me some hints how that's supposed to work.

Thank you.

EDIT: Perhaps this is helpfull:

inthunt.cfg

        <sliders>
            <slider desc="CRT H size" value="700" />
            <slider desc="CRT H shift" value="-2" />
        </sliders>

generated mode with these settings:
./groovymame inthunt
Switchres/SDL2: Detected SDL version 2.33.0
Switchres: Calculating best video mode for 320x240@60.012478 orientation: normal
Switchres: Modeline "640x240_60 15.603244KHz 60.012478Hz" 12.404579 640 665 723 795 240 242 245 260   -hsync -vsync
Switchres: Calculating best video mode for 320x240@60.012478 orientation: normal
Switchres: Modeline "640x240_60 15.603244KHz 60.012478Hz" 13.262757 640 680 742 850 240 242 245 260   -hsync -vsync

So the first Modeline is a result from range_1 it seems and the 2nd one seems to be a recalculation based on the <sliders></sliders> tag
So the 2nd Modeline effectively solves problem1 - by hand - but not problem2
 

[Zebidee]

You have "overscan". Almost every TV as this issue. When people watch TV they don't like seeing black, unfilled parts of the screen. So TVs are designed to make the picture a little larger. Sucks for gaming. Arcade monitors have pots so you can tweak the size to suit the game, TVs have little of that. The exact options available depend on your TV. Best place to start looking is in the TV's service mode.

For the TV - Every TV is different, but generally you can find service menu controls to vary vertical height & position, and horizontal position. Horizontal width control is sometimes possible, but probably not. You may have some other geometry controls for stuff like pincushioning.

These two ranges make every game I started thus far run ~100%
crt_range0                15600-15800, 49.50-50.20, 2.000, 4.700, 5.800, 0.064, 0.192, 1.056, 0, 0, 192, 288, 448, 576
crt_range1                15600-15800, 59.30-60.50, 2.000, 4.700, 5.800, 0.064, 0.192, 0.898, 0, 0, 192, 248, 448, 480

For PC - You can trim back some of the horizontal width & position by modifying the front and back porch settings, which I've bolded above. You may find that different settings optimal for "NTSC" vs "PAL". You don't really get any control over vertical size with CRT_emulator.

Given all these limitations, I often dive right in and change the TV's width capacitor!  This is a large polypropylene capacitor near the flyback, HOT (horizontal output transistor) and yoke coils connector (visible in background of photo below). Obviously TVs vary, but it is usually a value like 384, 474, 564, usually rated for high voltage, typically 400v or higher. Substituting a slightly larger value brings the picture in a little.

In the example photo below, from an RGB mod of a JVC TV I did earlier this year, I swapped a 474 400v for a 684 630v, and this brought the picture in by around 1.5cm. For more detail, see my writeup of the JVC TV mod. I have probably also discussed it in earlier TV mods, if you want to look through them.





In terms of capacitor codes, pay attention to the "XX4" format - the number is capacity in nanofarads (nF) and "4" means number of zeros. So a 564 means 560,000 nF. Point is to stay close to that level, use a capacitor of similar but different value. For example, if you have a 474 cap, don't replace with a 473, but a 684 is probably fine. It is OK to sub in a capacitor with a higher voltage rating, but don't go lower than the original.

Also, be sure to use the same kind of capacitor (polypropylene in this case). You can buy kits of these capacitors (range of various values) from Aliexpress and similar. I recall walking the street in Bangkok's electronics district to see an old woman, with no teeth and a big smile, presenting a trestle table covered with these capacitors in bags of various values. Like she was selling bananas. Anyway...

Hacking your TV is obviously "risky" and taking it to the next level - not for everyone. However, I have done this particular hack around a dozen times and all is good. I don't know of a better way to reduce the built-in overscan in many TVs. Just don't blame me if something goes wrong!