Split core into separete cores for SMS and GG

SwedishGojira
Posts: 13
Joined: Sun May 24, 2020 7:26 pm
Has thanked: 2 times
Been thanked: 3 times

Split core into separete cores for SMS and GG

Unread post by SwedishGojira »

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.
grizzly
Posts: 100
Joined: Tue Jun 16, 2020 12:22 pm
Has thanked: 8 times
Been thanked: 8 times

Re: Split core into separete cores for SMS and GG

Unread post by grizzly »

I agree!
Handhelds is the by far less used "systems" for me.
User avatar
Chris23235
Posts: 260
Joined: Sun May 24, 2020 8:45 pm
Has thanked: 2 times
Been thanked: 6 times

Re: Split core into separete cores for SMS and GG

Unread post by Chris23235 »

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.
User avatar
Indo Jimbo
Posts: 6
Joined: Sun May 24, 2020 7:02 pm
Has thanked: 3 times

Re: Split core into separete cores for SMS and GG

Unread post by Indo Jimbo »

Totally agree. The GG and SMS needs to be separated into their own core.
User avatar
Newsdee
Posts: 282
Joined: Mon May 25, 2020 1:07 am
Has thanked: 2 times
Been thanked: 18 times

Re: Split core into separete cores for SMS and GG

Unread post by Newsdee »

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.
User avatar
wark91
Posts: 84
Joined: Sun May 24, 2020 8:34 pm
Has thanked: 3 times
Been thanked: 3 times

Re: Split core into separete cores for SMS and GG

Unread post by wark91 »

Maybe have two configurations like minimig core.
naytai
Posts: 3
Joined: Mon May 25, 2020 2:36 pm

Re: Split core into separete cores for SMS and GG

Unread post by naytai »

Totally agree. They are independent systems.
Even MegaCD is a separated core from Genesis....
KremlingKuthroat19
Posts: 68
Joined: Sat Aug 22, 2020 3:08 am
Has thanked: 7 times
Been thanked: 4 times

Re: Split core into separete cores for SMS and GG

Unread post by KremlingKuthroat19 »

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.
ExCyber
Posts: 114
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 1 time
Been thanked: 14 times

Re: Split core into separete cores for SMS and GG

Unread post by ExCyber »

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).
naytai
Posts: 3
Joined: Mon May 25, 2020 2:36 pm

Re: Split core into separete cores for SMS and GG

Unread post by naytai »

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...
SwedishGojira
Posts: 13
Joined: Sun May 24, 2020 7:26 pm
Has thanked: 2 times
Been thanked: 3 times

Re: Split core into separete cores for SMS and GG

Unread post by SwedishGojira »

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?
ash2fpga
Posts: 140
Joined: Tue May 26, 2020 6:20 pm
Has thanked: 24 times
Been thanked: 11 times

Re: Split core into separete cores for SMS and GG

Unread post by ash2fpga »

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.
KremlingKuthroat19
Posts: 68
Joined: Sat Aug 22, 2020 3:08 am
Has thanked: 7 times
Been thanked: 4 times

Re: Split core into separete cores for SMS and GG

Unread post by KremlingKuthroat19 »

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.
zakk4223
Posts: 41
Joined: Sun May 24, 2020 10:55 pm
Been thanked: 5 times

Re: Split core into separete cores for SMS and GG

Unread post by zakk4223 »

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.
KremlingKuthroat19
Posts: 68
Joined: Sat Aug 22, 2020 3:08 am
Has thanked: 7 times
Been thanked: 4 times

Re: Split core into separete cores for SMS and GG

Unread post by KremlingKuthroat19 »

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.
User avatar
Newsdee
Posts: 282
Joined: Mon May 25, 2020 1:07 am
Has thanked: 2 times
Been thanked: 18 times

Re: Split core into separete cores for SMS and GG

Unread post by Newsdee »

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.
Post Reply