Support for Linux-side Interfaces [Feature Request]
Support for Linux-side Interfaces [Feature Request]
I would like Main_MiSTer to support linux-side interfaces or launchers [1]. I had some working code [2] but I would be happy if a better solution pops out. This is mainly a Feature Request, however I will discuss my prototype implementation for concreteness. I will suppose that no change to the core framework can be done.
Moreover I highlight that the requested feature is just for SUPPORTING external interfaces: the main MiSTer distribution should continue to work without any linux-side interface, but it should just provide us with some way to experiment with such interfaces.
As far a I understand to this goal we need:
1) A way to switch back and forth between current MiSTer menu and an external app.
2) A way to force a core to load a Rom.
My prototype handles such points adding commands to the /deb/MiSTer_cmd. These commands enable the following flow:
- slave_enable 1 - to let the mister switch to the linux-side interface application
- The application, during its execution, can send the following sequence of commands to /dev/MiSTer_cmd, to force to load a core AND a rom.
- load_core /path/to/core - to load the core (already implemented in the main repository)
- scan_mask_add /path/to/rom - from now on, a fixed list of paths will be returned when a core asks to navigate the filesystem; the list contains /path/to/rom only (other paths can be added if needed)
- select_a_rom - to force the core to select a rom in the list
- scan_clear - to clear the scan_mask_add list, returning to the standard filesystem navigation
- slave_enable 0 - to let the mister switch back to the standard visualization
Few notes:
- The select_a_rom command works sending to the core a synthetized sequence of user input that let it navigate the menu and select the last rom file. This is done with a temporary sub-process communicating itself with /dev/MiSTer_cmd
- The slave_enable 0/1 will send SIGSTOP and SIGCONT to the linux-side interface, as well as toggling vt on/off. This means that when the vt is not shown, there is no overhead in linux side.
- If no one of the new commands are sent to MiSTer_cmd, the main app just works as before: no new process are spawned, same filesystem navigation ability, etc.
- The command to use as a linux-side interface, for now, is hardcoded in the new cmd_io.c file. A proper entry in the mister.ini is advisable.
- A keybind for quickly do a "slave_enable 1" can be easily added to menu.cpp, so the MiSTer will normally run the standard interface, then pressing e.g. F8 the linux-side interface will pop-up. This is not meant to be in the main MiSTer distribution so it is out of the example patch [2].
I have a question too, about a minimal proof-of-concept I use for the tests. It loads a toy graphical launcher based on quick-and-dirty framebuffer drawing. In developing this I had a problem: Main_MiSTer will completely reset its process image on a load_core command (with an execv call). This means that it can not (easily) know the status of the linux-side interface (running, stopped, etc). I worked-around just quitting the linux-side interface at each swap, so the Main_MiSTer will correctly restart it the next time. For my small proof-of-concept this is not a problem since it starts very quickly, but for a real interfaces could be an issue.
Since this image-resetting is quite wierd I would ask: Is it really needed? Can just the relevant state be resetted without reloading the process image? I can try to develop this by my self, I am just asking for some hint on its feasibility.
[1] Porting complex gui (e.g. EmulationStation) is probably not possible due to the limited resource of the HPS. But simpler launcher or textual ui should be feasible, simplifying the MiSTer administration and core/rom launching.
[2] forked of an OLD version at https://github.com/pocomane/Main_MiSTer; compact view of the changes at
https://github.com/pocomane/Main_MiSTer ... ane:master
Moreover I highlight that the requested feature is just for SUPPORTING external interfaces: the main MiSTer distribution should continue to work without any linux-side interface, but it should just provide us with some way to experiment with such interfaces.
As far a I understand to this goal we need:
1) A way to switch back and forth between current MiSTer menu and an external app.
2) A way to force a core to load a Rom.
My prototype handles such points adding commands to the /deb/MiSTer_cmd. These commands enable the following flow:
- slave_enable 1 - to let the mister switch to the linux-side interface application
- The application, during its execution, can send the following sequence of commands to /dev/MiSTer_cmd, to force to load a core AND a rom.
- load_core /path/to/core - to load the core (already implemented in the main repository)
- scan_mask_add /path/to/rom - from now on, a fixed list of paths will be returned when a core asks to navigate the filesystem; the list contains /path/to/rom only (other paths can be added if needed)
- select_a_rom - to force the core to select a rom in the list
- scan_clear - to clear the scan_mask_add list, returning to the standard filesystem navigation
- slave_enable 0 - to let the mister switch back to the standard visualization
Few notes:
- The select_a_rom command works sending to the core a synthetized sequence of user input that let it navigate the menu and select the last rom file. This is done with a temporary sub-process communicating itself with /dev/MiSTer_cmd
- The slave_enable 0/1 will send SIGSTOP and SIGCONT to the linux-side interface, as well as toggling vt on/off. This means that when the vt is not shown, there is no overhead in linux side.
- If no one of the new commands are sent to MiSTer_cmd, the main app just works as before: no new process are spawned, same filesystem navigation ability, etc.
- The command to use as a linux-side interface, for now, is hardcoded in the new cmd_io.c file. A proper entry in the mister.ini is advisable.
- A keybind for quickly do a "slave_enable 1" can be easily added to menu.cpp, so the MiSTer will normally run the standard interface, then pressing e.g. F8 the linux-side interface will pop-up. This is not meant to be in the main MiSTer distribution so it is out of the example patch [2].
I have a question too, about a minimal proof-of-concept I use for the tests. It loads a toy graphical launcher based on quick-and-dirty framebuffer drawing. In developing this I had a problem: Main_MiSTer will completely reset its process image on a load_core command (with an execv call). This means that it can not (easily) know the status of the linux-side interface (running, stopped, etc). I worked-around just quitting the linux-side interface at each swap, so the Main_MiSTer will correctly restart it the next time. For my small proof-of-concept this is not a problem since it starts very quickly, but for a real interfaces could be an issue.
Since this image-resetting is quite wierd I would ask: Is it really needed? Can just the relevant state be resetted without reloading the process image? I can try to develop this by my self, I am just asking for some hint on its feasibility.
[1] Porting complex gui (e.g. EmulationStation) is probably not possible due to the limited resource of the HPS. But simpler launcher or textual ui should be feasible, simplifying the MiSTer administration and core/rom launching.
[2] forked of an OLD version at https://github.com/pocomane/Main_MiSTer; compact view of the changes at
https://github.com/pocomane/Main_MiSTer ... ane:master
- Sorgelig
- Site Admin
- Posts: 890
- Joined: Thu May 21, 2020 9:49 pm
- Has thanked: 2 times
- Been thanked: 214 times
Re: Support for Linux-side Interfaces [Feature Request]
MiSTer's Linux is tuned to be embedded Linux. Main purpose is to service the cores. It's not supposed to be a full featured GUI. Main MiSTer function is to play the emulated systems, not launchers.
More Linux part popping out -more Linux problems it will bring. You want a full featured Linux with different launchers - use RPi. You really don't need MiSTer. Believe me, you are wasting the time on MiSTer. You don't need it as you don't understand what MiSTer is about.
More Linux part popping out -more Linux problems it will bring. You want a full featured Linux with different launchers - use RPi. You really don't need MiSTer. Believe me, you are wasting the time on MiSTer. You don't need it as you don't understand what MiSTer is about.
Re: Support for Linux-side Interfaces [Feature Request]
I just believe that the MiSTer can archieve its goals without giving up the
convenience of a launcher or other linux-side administration interfaces. However,
I take note that this kind of features are not of interest. So, sorry for the noise,
and thank you for the MiSTer.
convenience of a launcher or other linux-side administration interfaces. However,
I take note that this kind of features are not of interest. So, sorry for the noise,
and thank you for the MiSTer.
Re: Support for Linux-side Interfaces [Feature Request]
The linux side is already running a terminal with SSH. This should require minimal code changes and almost no extra overhead. This proposal is not adding a fully featured GUI. The UI and OSD will be untouched!Sorgelig wrote: ↑Tue Jun 16, 2020 9:27 am MiSTer's Linux is tuned to be embedded Linux. Main purpose is to service the cores. It's not supposed to be a full featured GUI. Main MiSTer function is to play the emulated systems, not launchers.
More Linux part popping out -more Linux problems it will bring. You want a full featured Linux with different launchers - use RPi. You really don't need MiSTer. Believe me, you are wasting the time on MiSTer. You don't need it as you don't understand what MiSTer is about.
I think OP is maybe complicating the feature request in your eyes. Users simply want the ability to launch roms via command line. That's it. This is trivial, there's no valid reason NOT to add this functionality.
Sorgelig, will you reconsider adding this simple and trivial feature? I know you won't use it, but many users WILL. It will not add any bloat. No GUI, no changes to OSD. PLEASE!
Re: Support for Linux-side Interfaces [Feature Request]
Loading a rom from the command line should already work with my patch (practically it is the core of the patch). A script should just write the following lines to /dev/MiSTer_cmd:
- scan_mask_add /path/to/rom
- select_a_rom
- scan_clear
This still uses the "Input emulation" and "Fake filesystem" methods (and as I said, I would be happy if someone suggested a better way).
- scan_mask_add /path/to/rom
- select_a_rom
- scan_clear
This still uses the "Input emulation" and "Fake filesystem" methods (and as I said, I would be happy if someone suggested a better way).
Re: Support for Linux-side Interfaces [Feature Request]
Okay, good to know.pocomane wrote: ↑Sat Jul 11, 2020 4:24 pm Loading a rom from the command line should already work with my patch (practically it is the core of the patch). A script should just write the following lines to /dev/MiSTer_cmd:
- scan_mask_add /path/to/rom
- select_a_rom
- scan_clear
This still uses the "Input emulation" and "Fake filesystem" methods (and as I said, I would be happy if someone suggested a better way).
I would like the ability to load a custom rom on the very latest version of Main_MiSTer. I like the simple way you achieved this here, but this can no longer work due to refactoring of code. Maybe I will dig into the code to find an equivalent way. Otherwise, let me know if someone else already has.
Re: Support for Linux-side Interfaces [Feature Request]
The force_file command was superseeded by the scan_mask_add one (https://github.com/pocomane/Main_MiSTer ... 4cc380b301), that seemed more polished to me. In both you have to select a rom from the menu (manually o by means of "Emulated inputs"). in the former any rom you select is overridden by the chosen one, in the latter you just see the chosen one in the menu.
Why do you prefer the first one? If there is some advantage that I missed, I can bring it back (without removing the new one).
PS. I do not know if this discussion is ok for the forum since it is mainly about a fork. if anyone is bothered by it, we can move to somewhere else.
Re: Support for Linux-side Interfaces [Feature Request]
I see, you have updated your fork now. I will check it out! Thanks. Great work!pocomane wrote: ↑Mon Jul 13, 2020 6:32 amThe force_file command was superseeded by the scan_mask_add one (https://github.com/pocomane/Main_MiSTer ... 4cc380b301), that seemed more polished to me. In both you have to select a rom from the menu (manually o by means of "Emulated inputs"). in the former any rom you select is overridden by the chosen one, in the latter you just see the chosen one in the menu.
Why do you prefer the first one? If there is some advantage that I missed, I can bring it back (without removing the new one).
PS. I do not know if this discussion is ok for the forum since it is mainly about a fork. if anyone is bothered by it, we can move to somewhere else.
The only reason I might prefer the first one is because it's an easier sell to the devs that have final say as to what code will be accepted in a pull request. Sorg seems to be adamant about minimalism, i.e. less code changes the better. And all I need is the ability to launch a rom from the command line. But personally, I do like where you're going with these changes.
My goal is to write a front end cross platform app that acts as a remote, allowing users to scroll through box art and launch any game. The app will then send the appropriate command to launch the user specified game via SSH to the MiSTer. This front end will not run on the DE10-Nano itself, so it's a win win. OSD stays the same, no system resources are used. People can use their spare RPi or phones as a remote for the MiSTer. Or a tablet setup in your game room!
This is great, thanks! In one form or another, the ability to launch a rom from commandline needs to be added to the real Main_MiSTer, please Sorg!
Re: Support for Linux-side Interfaces [Feature Request]
Would a possible work-around be to use the existing bootrom functionality?
You could:
1) Copy the rom you want to boot to bootrom (for NES core: `boot1.rom = NES Cart file. Can be used with boot0.rom (BIOS) in place`)
2) Start appropriate core
You could:
1) Copy the rom you want to boot to bootrom (for NES core: `boot1.rom = NES Cart file. Can be used with boot0.rom (BIOS) in place`)
2) Start appropriate core
Re: Support for Linux-side Interfaces [Feature Request]
As Sorgelig pointed out (https://github.com/MiSTer-devel/Main_Mi ... -612410931), this does not work for all the cores. In any case, at least a command to change the boot rom path could be added. So we can avoid the file copy.
Re: Support for Linux-side Interfaces [Feature Request]
Digging into https://github.com/nilp0inter/MiSTer_WebMenu I found it is using a system similar to the one described in this thread. But it leverages mount points and a "Fake" /dev/input file instead of modifying MiSTer_Main app.
It should be possible to create a standalone command line launcher using this method.
It should be possible to create a standalone command line launcher using this method.
- copperkiddx
- Posts: 3
- Joined: Mon Jan 24, 2022 3:14 pm
- Has thanked: 1 time
Re: Support for Linux-side Interfaces [Feature Request]
Has there been any updates on this? I am also looking for a way to load roms via the command line and what you guys are talking about here sounds amazing! All I wanted was to write a script that would load a random NES rom but the idea of a remote app is even better!
-
- Top Contributor
- Posts: 606
- Joined: Fri Jan 22, 2021 4:36 pm
- Has thanked: 77 times
- Been thanked: 302 times
Re: Support for Linux-side Interfaces [Feature Request]
Are you thinking of something like an API that you could operate from a phone or some such, like a "remote" for the MiSTer's functionality that it already exposes through the OSD?
- Mr. Encyclopedia
- Posts: 111
- Joined: Thu Aug 05, 2021 1:52 am
- Has thanked: 50 times
- Been thanked: 47 times
- Contact:
Re: Support for Linux-side Interfaces [Feature Request]
Does the inclusion of MGL files improve this process? Can a MGL file be passed to MiSTer via command line or MiSTer_cmd to start a specific core with a specific rom?pocomane wrote: ↑Sat Jul 11, 2020 4:24 pm Loading a rom from the command line should already work with my patch (practically it is the core of the patch). A script should just write the following lines to /dev/MiSTer_cmd:
- scan_mask_add /path/to/rom
- select_a_rom
- scan_clear
This still uses the "Input emulation" and "Fake filesystem" methods (and as I said, I would be happy if someone suggested a better way).
- amstan
- Posts: 56
- Joined: Sat Feb 12, 2022 8:08 am
- Location: Mountain View, California
- Has thanked: 5 times
- Been thanked: 26 times
- Contact:
Re: Support for Linux-side Interfaces [Feature Request]
This is a neat idea, but I assume it's a little bit clunky if you have to inject virtual keyboard input commands. Unfortunatelly without Sorgelig's support I don't see a better way.
Honestly even some command line arguments to Main_MiSTer (to choose the core and rom) would go far here.
Honestly even some command line arguments to Main_MiSTer (to choose the core and rom) would go far here.
- Mr. Encyclopedia
- Posts: 111
- Joined: Thu Aug 05, 2021 1:52 am
- Has thanked: 50 times
- Been thanked: 47 times
- Contact:
Re: Support for Linux-side Interfaces [Feature Request]
Command line arguments to Main_MiSTer to choose the core and rom is exactly what MGL supplies, more or less. If you have the appropriate MGL file you could go to the shell and type
and MiSTer will immediately load that MGL file, which will in turn load the core and rom. It's pretty easy to see how this could be used in a script to either pick from a random selection of MGL files or generate an MGL file on the fly for a randomly chosen rom and pass it to MiSTer_cmd.
Code: Select all
echo "load_core /media/fat/mygame.mgl" > /dev/MiSTer_cmd
-
- Posts: 11
- Joined: Tue Sep 22, 2020 7:09 am
- Has thanked: 2 times
- Been thanked: 2 times
Re: Support for Linux-side Interfaces [Feature Request]
I'm working on a script witch would also greatly benifit from a command to directly load roms.
The MGL workaround should work just fine for now, but it's sad that Sorgelig is seemingly set on keeping the MiSTer as hard to use as possible.
The MGL workaround should work just fine for now, but it's sad that Sorgelig is seemingly set on keeping the MiSTer as hard to use as possible.
- Mr. Encyclopedia
- Posts: 111
- Joined: Thu Aug 05, 2021 1:52 am
- Has thanked: 50 times
- Been thanked: 47 times
- Contact:
Re: Support for Linux-side Interfaces [Feature Request]
In Sorg's defense, he's not keeping it as hard to use as possible, he's just completely uninterested in making any significant changes to the current OSD interface. MGL seems like an fine compromise, it gives developers a way to make a Linux script or GUI that can launch cores and roms without affecting the OSD interface.