Long bootup when having modelines for many cores

[thehughhefner]

Hi, When I am adding custom modelines in the ini file for the CPS core, I have to do that for all games in the specific core. So instead of writing cps1 I have to write modelines for all of the games in that CPS1 and CPS2 core. The consequence of this is that when booting up MiSTer, it will take quite some time for it to boot properly and it will do so when booting other cores as well. Is this because of the MRA structure and is there a workaround or another solution to this issue?

[sorgelig]

I don't know what "modelines" are. But abusing ini with many options may lead to such behavior.

[blackjer]

Im using modelines in my ini file to specify custom resolution values for every cps1.5 and cps2 core and my mister boots quickly. When i launch a game that uses one of those cores it takes my TV a couple seconds to sync but that is expected.

On Thu, Mar 25, 2021 at 5:10 PM Alexey Melnikov @.***> wrote:

I don't know what "modelines" are. But abusing ini with many options may lead to such behavior.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MiSTer-devel/Main_MiSTer/issues/367#issuecomment-807492756, or unsubscribe https://github.com/notifications/unsubscribe-auth/AETADRKXQ5UPX4AYJSMMCBLTFORC7ANCNFSM4Z2DFJDQ .

[sorgelig]

cps core may include HV-Integer option like i've added to console/computer cores. If this is what you really want to achieve. Otherwise i don't see why you need to set a custom resolution for each game.

[boogermann]

@sorgelig I think he is referring to the side effect of theuser_io_name_override. Because it will override the Core default name and use the setname specified on the MRA. The priority to read the groups inside the ini file is [setname] then [MiSTer]. So in order for someone to use custom video modes, on a game basis it require the person to set a group key for each setname, for example

[MiSTer]
[1944]
[1944j]
[1944u]

It will simply ignore [jtcps2] because it doesn't know about it anymore. I fixed this by simply holding a copy of the core unique id. https://github.com/MiSTer-devel/Main_MiSTer/blob/master/user_io.cpp#L318 to this

    char *p = user_io_get_confstr(0);
    if(p && p[0]) { (core_uid, p); }
    if(override_name[0]) {
        strcpy(core_name, override_name);
    } else if(p && p[0]) {
        strcpy(core_name, p);
    }

and a getter method to retrieve the code_uid. So instead of the priority being [setname]->[mister], it will go [setname]->[corename]->[mister], setname override core configuration and core configuration override mister configuration.

[MiSTer]
video_mode=1
...
[jtcps2]
video_mode=1536,48,32,80,1120,3,10,19,117228 ; (5x)
vsync_adjust=1
[1944] ; will use the video mode from jtcps2
vsync_adjust=2 
[1944j]
vscale_mode=0 ; will use this video only for this setname
vsync_adjust=0

This way only require the user to set a specific keys to a single game while they can have a "general" configurations that will work with all other games of that core.

[thehughhefner]

Hi, Yes, pretty much what boogermann is writing. Right now I have to write "modelines" for all games in the CPS1 and CPS2 library, which means more than 3000 lines of code, or even more. It will certainly be a big problem once we get other multi-game arcade cores.

[atrac17]

Thank the maker.

[sorgelig]

if CPS games require so many tweaks then probably core needs some changes to minimize these tweaks.

[sorgelig]

once we get other multi-game arcade cores.

There are many such MiSTer arcade cores.

[thehughhefner]

Correct, and also for those cores I have to set custom modes to each game. Take for example the Sega System 1 core. I have to specify modelines for all of the games in that core.

[sorgelig]

That's all i could do. You simply misuse the ini.

[atrac17]

Commit works for it's intended purpose. There is nothing wrong with the CPS cores. The intent is to use custom video modes without 310 different <setname> to identify the video_mode=. This is just an example for CPS2.

[Chocobobobo]

CPS cores are not in Sorg's repository, this is what's wrong with them.

[boogermann]

if CPS games require so many tweaks then probably core needs some changes to minimize these tweaks.

@sorgelig the issue was more of a limitation of the implementation and not necessary a misusage. There was no way for the user to circle around the issue.

Basically the issue is/was: (using the sega system 1 as example)

1. io_init detects the xml
2. runs arcade override name function ( the core_name changed from [A.SEGASYS1] to `[flicky]`
(continue initialization)
3. parse configuration (here MiSTer doesn't know about the `A.SEGASYS1` anymore )
4. look for [flicky] on the ini file.
5. fallback to [mister]
(continue)

it just needed a "4a" step in place

4a. look for [A.SEGASYS1]

It might not be a common issue for people just using the predefined resolution under [mister], but @atrac17 custom video modes will trigger it. And what causes the performance issue is the large number of groups inside the ini (only necessary because there was no other way around and very repetitive) combined with the output of the printf to the terminal.

We implemented the solutions in different ways, so I'm not sure how your changes will ripple across the other subsystems, specially on the mapping names and config file names. It was OK before, it just needed an option for the config parser that if [setname] is not there look inside the [core_id], otherwise just use [mister].

[atrac17]

@sorgelig this commit works for it's intended purpose and does not cause issues. I have already tested it. Thank you for implementing.

[sorgelig]

It supports:

[arcade] - all arcades
[core_name] - name provided by core.
[setname] - name provided by MRA.

Also new commit supports additional core names (including all above) in section:

[some_core]
+core_1
+core_2

So if group of cores share the same settings then can enumerate these cores in common section.

[sorgelig]

should be solved already