MiSTer FPGA Forum

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

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

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.

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!

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!

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).

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).

Okay, good to know.

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.

Nytron wrote: ↑Sat Jul 11, 2020 6:35 pm I like the simple way you achieved this here, but this can no longer work due to refactoring of code

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.

pocomane wrote: ↑Mon Jul 13, 2020 6:32 am

Nytron wrote: ↑Sat Jul 11, 2020 6:35 pm I like the simple way you achieved this here, but this can no longer work due to refactoring of code

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.

I see, you have updated your fork now. I will check it out! Thanks. Great work!

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!

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

dentnz wrote: ↑Tue Jul 14, 2020 11:27 pm Would a possible work-around be to use the existing bootrom functionality?

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.

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.

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!

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?

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).

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?

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.

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.

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.

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.