MiSTer FPGA Forum

I understand that these are pretty much identical in hardware, but one of them is a regular console (SMS) and the other is a handheld (GG).
Splitting these into seprate cores would give users the benefit of being able to set proper settings for the respective systems for filters and other settings as right now you are forced to choose one over the other.
Also I feel that mister should have a _Handheld category for the handheld systems just as it does for _Arcade, _Console and _Computers.

I agree!
Handhelds is the by far less used "systems" for me.

SwedishGojira wrote: ↑Tue Jan 05, 2021 1:10 pm Also I feel that mister should have a _Handheld category for the handheld systems just as it does for _Arcade, _Console and _Computers.

You can organise the categories on your MiSTer the way you want, if you want a handheld category you can make a folder on your SD card and copy the rbf files you want to this folder.

Totally agree. The GG and SMS needs to be separated into their own core.

Cores are identified in config by a string... I wonder if we could just copy/paste the .rbf and change that string internally.
Then there is no need to split cores - just that small tweak whenever we need to upgrade versions.

Edit: that didn't work... so the other possibility is to use an alternate fork of the core (such as the LLAPI version).
Then - you can just use one or the other core for SMS and GG.

Maybe have two configurations like minimig core.

Totally agree. They are independent systems.
Even MegaCD is a separated core from Genesis....

I don't know guys. I think things are fine as they are. I don't think it's necessary to separate cores since it would waste development time.

Why not separate SG-1000 from the ColecoVision core or Famicom Disk System from the NES core or Game Boy Color from the Game Boy core or TurboGrafx-CD and SuperGrafx from the TurboGrafx-16 core. You could go on and on. I think things are fine as they are.

My advice for those that want to separate the cores is to create a folder for the name of the system (i.e. Game Gear, and Master System underneath the SMS folder and that's sufficient enough organization for me. You can rename your core file from "SMS" to "SMS+GG" which is what I do.

KremlingKuthroat19 wrote: ↑Wed Jan 06, 2021 3:51 am I don't know guys. I think things are fine as they are. I don't think it's necessary to separate cores since it would waste development time.

Why not separate SG-1000 from the ColecoVision core or Famicom Disk System from the NES core or Game Boy Color from the Game Boy core or TurboGrafx-CD and SuperGrafx from the TurboGrafx-16 core. You could go on and on. I think things are fine as they are.

My advice for those that want to separate the cores is to create a folder for the name of the system (i.e. Game Gear, and Master System underneath the SMS folder and that's sufficient enough organization for me. You can rename your core file from "SMS" to "SMS+GG" which is what I do.

This doesn't address the main point, which is that SMS and GG share video settings despite being designed for very different screens. A similar case could actually be made for separating GB and GBC video settings (the original Game Boy screen looks and performs very differently than the GBC screen), but your other examples don't have the same issue.

That being said, separating the cores is only one possible way to address this. For example, maybe there's a reasonable way to support having a configuration in the current ROM directory override the main configuration (and maybe not, as far as I know; I'm far from understanding all of the interactions and special cases in the menu code).

ExCyber wrote: ↑Wed Jan 06, 2021 6:21 am

KremlingKuthroat19 wrote: ↑Wed Jan 06, 2021 3:51 am I don't know guys. I think things are fine as they are. I don't think it's necessary to separate cores since it would waste development time.

Why not separate SG-1000 from the ColecoVision core or Famicom Disk System from the NES core or Game Boy Color from the Game Boy core or TurboGrafx-CD and SuperGrafx from the TurboGrafx-16 core. You could go on and on. I think things are fine as they are.

My advice for those that want to separate the cores is to create a folder for the name of the system (i.e. Game Gear, and Master System underneath the SMS folder and that's sufficient enough organization for me. You can rename your core file from "SMS" to "SMS+GG" which is what I do.

This doesn't address the main point, which is that SMS and GG share video settings despite being designed for very different screens. A similar case could actually be made for separating GB and GBC video settings (the original Game Boy screen looks and performs very differently than the GBC screen), but your other examples don't have the same issue.

That being said, separating the cores is only one possible way to address this. For example, maybe there's a reasonable way to support having a configuration in the current ROM directory override the main configuration (and maybe not, as far as I know; I'm far from understanding all of the interactions and special cases in the menu code).

That's the point. The way things are, user has to change video filters everytime when switching from GG to SMS and vice versa. The same applies to GB < -- > GBC with an additional step regarding the palettes. So, not sure if it is the most straightfoward approach...

Could this possibly be accomplished in a similar way that the arcade cores load specific modes when you start an .mra file? You can set specific settings per game for arcade roms as the core reads the settings bqsed on rom name. Maybe this could ve done in a similar way to load settings for SMS and GG separately?

SwedishGojira wrote: ↑Wed Jan 06, 2021 11:21 am Could this possibly be accomplished in a similar way that the arcade cores load specific modes when you start an .mra file? You can set specific settings per game for arcade roms as the core reads the settings bqsed on rom name. Maybe this could ve done in a similar way to load settings for SMS and GG separately?

I like that idea. Perhaps if we could have a SMS.mra and a GG.mra? If we could do that, it seems like it should be able to leverage existing mister.ini handling, with an ini section for SMS specific settings, and an ini section for GG specific settings. I think that would satisfy many people. There are probably some people that would still like "per-game" settings, but if we could at least start with separate SMS and GG settings, that would be great.

Fair enough. We don't need per-game settings like Arcade cores because that's way too much overkill since all Game Gear games use the same inputs hardware, and screen settings. Just two MRA files would be sufficient. One for Game Gear games, meaning games that end in a .gg file extension and one for Master System games, meaning games that end in a .sms file extension as the method of detecting which games are compatible with which MRA file like @ash2fpga recommends.

ash2fpga wrote: ↑Wed Jan 06, 2021 3:16 pm

SwedishGojira wrote: ↑Wed Jan 06, 2021 11:21 am Could this possibly be accomplished in a similar way that the arcade cores load specific modes when you start an .mra file? You can set specific settings per game for arcade roms as the core reads the settings bqsed on rom name. Maybe this could ve done in a similar way to load settings for SMS and GG separately?

I like that idea. Perhaps if we could have a SMS.mra and a GG.mra? If we could do that, it seems like it should be able to leverage existing mister.ini handling, with an ini section for SMS specific settings, and an ini section for GG specific settings. I think that would satisfy many people. There are probably some people that would still like "per-game" settings, but if we could at least start with separate SMS and GG settings, that would be great.

The only thing stopping that from being possible now is that the MRA loading code has some baked in assumptions about where to search for cores and roms. I've always had the idea that MRA could support generic core+rom loading and modifying some global settings when loaded (like autofire etc). Unfortunately it wouldn't be something you'd be able to easily edit via the UI, so I've been unwilling to do the work because I have doubts it would get merged.
The intent would be that you could create per-game MRAs only for specific games in a core that need special settings. Unfortunately it would require users to self-edit XML files and thus is probably going to add too much tech support burden.

Maybe just changing how it searches for RBF files would be sufficient for cases like this, but then you lose the /bootrom/ support (which might be important for some cores). So you'd have to re-implement that (with extra logic to deal with 'setname'). You could use the MRA rom loading section to inject it I guess but that's another configuration rabbit hole.

zakk4223 wrote: ↑Wed Jan 06, 2021 11:12 pm The only thing stopping that from being possible now is that the MRA loading code has some baked in assumptions about where to search for cores and roms. I've always had the idea that MRA could support generic core+rom loading and modifying some global settings when loaded (like autofire etc). Unfortunately it wouldn't be something you'd be able to easily edit via the UI, so I've been unwilling to do the work because I have doubts it would get merged.
The intent would be that you could create per-game MRAs only for specific games in a core that need special settings. Unfortunately it would require users to self-edit XML files and thus is probably going to add too much tech support burden.

Maybe just changing how it searches for RBF files would be sufficient for cases like this, but then you lose the /bootrom/ support (which might be important for some cores). So you'd have to re-implement that (with extra logic to deal with 'setname'). You could use the MRA rom loading section to inject it I guess but that's another configuration rabbit hole.

That's a very interesting concept I haven't thought of. Some games require peripherals and having them autoconfigured for an MRA on a per-game basis would make the MiSTer even more plug and play. For example, Duck Hunt has an MRA file that autoloads the Zapper controller type and Mario Paint can autoload the SNES mouse and so on. Some games can auto-enable the turbo feature like Doom on GBA. Some games with multitap can autoload the multitap and so on.

I think this is a great idea. Maybe a possible workaround is that instead of getting users to edit XML files, there can be preconfigured, generic ones. Take the SNES for example. There could be a default multitap MRA. If users wanted the multitap to be enabled for Super Bomberman, then the preconfigured multitap MRA file could use the same name recognition function that the save files and cheat files use to link the saves and cheats between the games, meaning that if the MRA was named 'Super Bomberman.mra', then when you load 'Super Bomberman.smc', the multitap would already be enabled for that game. Then when you want to enable the multitap for Super Bomberman 2, you could copy and paste the MRA and rename it to 'Super Bomberman 2.mra' and it'd work right out of the box without any configuring. Then you could use this copy and paste function for all multitap games on the SNES, then create a new process for the Super Scope games and rinse and repeat.

If this is something that's feasible let me know. I think it's a great idea. It'd probably be more appropriate for MiSTer main though.

Just recompile the core changing the core string name (first item in SMS.sv in CONF_STR): The settings save according to that name,
so you can build yourself as many alternate cores as you want and save as many alternate configs against them.

This now seems to be pretty easily possible with the setname feature of .mgl files. I made a file called GameGear.mgl in my _console directory with the following contents:
And now I have GameGear as a seperate option in my console list and the ability to save different settings for it. I also had to make a games/GameGear directory and put the games in it. Also don’t forget to update main mister (I forgot and almost gave up on getting this working before remembering).

Yim wrote: ↑Sun Jul 24, 2022 8:01 am This now seems to be pretty easily possible with the setname feature of .mgl files. I made a file called GameGear.mgl in my _console directory with the following contents:

Code: Select all

<mistergamedescription>
    <rbf>_console/sms</rbf>
    <setname>GameGear</setname>
</mistergamedescription>

And now I have GameGear as a seperate option in my console list and the ability to save different settings for it. I also had to make a games/GameGear directory and put the games in it. Also don’t forget to update main mister (I forgot and almost gave up on getting this working before remembering).

This feature was added specifically for addressing this particular concern, and for 7800 core as well. YMMV, be aware if you use any features of the updater that place files it cannot be aware of any name changes you have made, and you will have to manually symlink any kinds of cheats or what have you that you may want to carry over.

Newsdee wrote: ↑Thu Jan 07, 2021 12:07 pm Just recompile the core changing the core string name (first item in SMS.sv in CONF_STR):

Code: Select all

parameter CONF_STR = {
    "SMS;;",

The settings save according to that name,
so you can build yourself as many alternate cores as you want and save as many alternate configs against them.

I would also love to have a separate GG core mainly because of the video settings, one CRT one LCD.
I only have macOS, can someone here recompile the latest SMS core to a GG core?

Yim wrote: ↑Sun Jul 24, 2022 8:01 am This now seems to be pretty easily possible with the setname feature of .mgl files. I made a file called GameGear.mgl in my _console directory with the following contents:

Code: Select all

<mistergamedescription>
    <rbf>_console/sms</rbf>
    <setname>GameGear</setname>
</mistergamedescription>

And now I have GameGear as a seperate option in my console list and the ability to save different settings for it. I also had to make a games/GameGear directory and put the games in it. Also don’t forget to update main mister (I forgot and almost gave up on getting this working before remembering).

This works great! Thanks!

neogeo81 wrote: ↑Mon Jul 25, 2022 2:04 pm I would also love to have a separate GG core mainly because of the video settings, one CRT one LCD.
I only have macOS, can someone here recompile the latest SMS core to a GG core?

This method is no longer necessary, you can just make an .mgl file (in a text editor) with a setname tag in it as described in my previous post in this thread. The mgl file will then appear as a separate entry in your consoles list and its settings will be stored separately.

Basically loading with the setname tag changes the core name without having to recompile it. This also means you’ll only have to do it once rather than needing to recompile every time the SMS core gets updated.

Kitrinx wrote: ↑Sun Jul 24, 2022 4:04 pm This feature was added specifically for addressing this particular concern, and for 7800 core as well. YMMV, be aware if you use any features of the updater that place files it cannot be aware of any name changes you have made, and you will have to manually symlink any kinds of cheats or what have you that you may want to carry over.

It'd be nice to see MGL files support a name tag as MRA files do so we can get friendlier names in the main menu.

How feasible would it be for MGL files to hide certain options from the core menu? For example, a Game Gear MGL that hides any options specific to SMS? Is that something the framework could even support?

jlancaster86 wrote: ↑Tue Jul 26, 2022 1:03 pm

Kitrinx wrote: ↑Sun Jul 24, 2022 4:04 pm This feature was added specifically for addressing this particular concern, and for 7800 core as well. YMMV, be aware if you use any features of the updater that place files it cannot be aware of any name changes you have made, and you will have to manually symlink any kinds of cheats or what have you that you may want to carry over.

It'd be nice to see MGL files support a name tag as MRA files do so we can get friendlier names in the main menu.

How feasible would it be for MGL files to hide certain options from the core menu? For example, a Game Gear MGL that hides any options specific to SMS? Is that something the framework could even support?

Doesn't the Name File not overwrite that?

Yim wrote: ↑Tue Jul 26, 2022 7:28 am

neogeo81 wrote: ↑Mon Jul 25, 2022 2:04 pm I would also love to have a separate GG core mainly because of the video settings, one CRT one LCD.
I only have macOS, can someone here recompile the latest SMS core to a GG core?

This method is no longer necessary, you can just make an .mgl file (in a text editor) with a setname tag in it as described in my previous post in this thread. The mgl file will then appear as a separate entry in your consoles list and its settings will be stored separately.

Basically loading with the setname tag changes the core name without having to recompile it. This also means you’ll only have to do it once rather than needing to recompile every time the SMS core gets updated.

Worked thanks

neogeo81 wrote: ↑Tue Jul 26, 2022 2:53 pm

jlancaster86 wrote: ↑Tue Jul 26, 2022 1:03 pm

Kitrinx wrote: ↑Sun Jul 24, 2022 4:04 pm This feature was added specifically for addressing this particular concern, and for 7800 core as well. YMMV, be aware if you use any features of the updater that place files it cannot be aware of any name changes you have made, and you will have to manually symlink any kinds of cheats or what have you that you may want to carry over.

It'd be nice to see MGL files support a name tag as MRA files do so we can get friendlier names in the main menu.

How feasible would it be for MGL files to hide certain options from the core menu? For example, a Game Gear MGL that hides any options specific to SMS? Is that something the framework could even support?

Doesn't the Name File not overwrite that?

I tried adding a friendly name entry in names.txt to go with the GameGear .mgl file above (which works fine) but it still displays in the core list as whatever is defined in the <setname> tag. I agree that a <name> tag in the .mgl file or allowing definitions for <setname> in names.txt would be a handy feature to complement this new functionality.

retrofan01 wrote: ↑Wed Jul 27, 2022 5:46 pm

neogeo81 wrote: ↑Tue Jul 26, 2022 2:53 pm

jlancaster86 wrote: ↑Tue Jul 26, 2022 1:03 pm

It'd be nice to see MGL files support a name tag as MRA files do so we can get friendlier names in the main menu.

How feasible would it be for MGL files to hide certain options from the core menu? For example, a Game Gear MGL that hides any options specific to SMS? Is that something the framework could even support?

Doesn't the Name File not overwrite that?

I tried adding a friendly name entry in names.txt to go with the GameGear .mgl file above (which works fine) but it still displays in the core list as whatever is defined in the <setname> tag. I agree that a <name> tag in the .mgl file or allowing definitions for <setname> in names.txt would be a handy feature to complement this new functionality.

names.txt doesn't work because the file is no core file

in the list it shows the name of the file itself. the setname is the internal name which also should be the games folder name.

Yeah, I’ve since changed my file’s name from “GameGear.mgl” to “Game Gear.mgl” to make it look better in the list.

Yim wrote: ↑Thu Jul 28, 2022 2:14 pm Yeah, I’ve since changed my file’s name from “GameGear.mgl” to “Game Gear.mgl” to make it look better in the list.

I did something similar. I like to have all my Nintendo/Sega/Atari/etc. systems grouped together, so I renamed the files to "Sega Game Gear" and "Sega SG-1000" as well as updating their <setname> attributes to match. I also had to make folders for my games that used the same naming convention. It's definitely not as convenient as updating the names.txt file, but at least it works.

I think another one of the issues with names.txt support, is that for anyone who uses the update_all.sh script these changes will get overwritten (correct me if I'm wrong, I'm considering taking a look through the script now to confirm). If this is true, then perhaps having a tag in the .mgl schema would be more appropriate -- with the added benefit of everything being contained and defined in the same place.

Yim wrote: ↑Sun Jul 24, 2022 8:01 am

This now seems to be pretty easily possible with the setname feature of .mgl files. I made a file called GameGear.mgl in my _console directory with the following contents:

Code: Select all

<mistergamedescription>
    <rbf>_console/sms</rbf>
    <setname>GameGear</setname>
</mistergamedescription>

And now I have GameGear as a seperate option in my console list and the ability to save different settings for it. I also had to make a games/GameGear directory and put the games in it. Also don’t forget to update main mister (I forgot and almost gave up on getting this working before remembering).

This doesn't seem to be working for me in December 2023. I entered separate sections in my mister.ini file for [GameGear] and [SMS], with different settings. But when I'm running the GameGear "core," my MiSTer is only picking up the [SMS] settings. Does anyone know what might be going wrong for me? I'm current on everything from update_all.