Load core/rom from command line

[pocomane]

Right now I am trying to extract the relevant code from Main_MISTer application, but maybe there is a simpler solution: is there a way to load core and rom from the command line?

I want use such facility in a script to start a random game from my selection. However a generic cli loader may be useful in other scenarios too.

[sorgelig]

echo load_core mycore.rbf >/dev/MiSTer_cmd

[pocomane]

Thanks. I found only load_core and fb_cmd in the sources. Is there any other command? Is there a way to load a rom too?

Moreover it uses an internal directory prefix that I think it is not ideal for use in system script.

Can you confirm that I need to patch the main app for:

1. Load a rom file
2. Use full filesystem paths
   ?

[sorgelig]

1. there is no API to load rom from linux side. Core has to request the ROM. There is boot.rom which can be loaded at start, but it's not exactly the game - it's core specific. Some cores use boot.rom as BIOS or other specific ROM. So you can't fix it.
2. i'm not sure what's preventing to use the path - i will check. But from script you can switch to required path and then send load_core from there.

[sorgelig]

just checked - no problem to use paths. You have to provide full path.

[pocomane]

Ok, I tested it again and now it works, probably I made some error the first time. Sorry for the noise.

For the rom, it is not clear to me the full load sequenece: you said that the core have to request it, but the process is triggered by user actions (open menu, select load, chose the file). This actions are handled linux side, right? If this is the case, do you think it is possible to emulate the whole process? (Each core can be handled a bit differently if something is core-dependent).

[sorgelig]

In theory, it's possible.
In practice - it depends on usage scenario. For example computer cores need to be fully loaded in their GUI/CMD before they can accept any additional load. Then it also depends on file - some files are disk images requiring further command line/mouse inputs.

[pocomane]

Ok, thanks. I am experimenting a bit with input emulation. The commands I added are in

pocomane@48c970d

If you are interested, I can send you a pull request. It just adds some command that wraps user_io_kbd and user_io_digital_joystick (well... also some spi writer, just in case).

[sorgelig]

No, it's not proper use of MiSTer. It exposes proprietary interface which should stay as internal.

[pocomane]

I added a new command that override the file specified to user_io_file_tx. It seems that this is enough for core not requiring BIOS. E.g from a ssh session I can:

echo force_file /media/fat/NES/myrom.nes > /dev/MiSTer_cmd
echo load_core /media/fat/_Console/NES.rbf > /dev/MiSTer_cmd
echo force_file > /dev/MiSTer_cmd

and the NES core starts with the wanted rom. The last line is needed to turn off the override so that subsequent roms can be properly chosen from Osd menu.

The changes are very small: pocomane@c016472

My idea now is to write a new command that sends the right keys sequence to trigger a rom request. So I can load a rom with script sequence like

echo load_core /media/fat/_Console/NES.rbf > /dev/MiSTer_cmd
#
echo force_file /media/fat/NES/myrom.nes > /dev/MiSTer_cmd
echo load_first_rom > /dev/MiSTer_cmd # not implemented yet
echo force_file > /dev/MiSTer_cmd

(Probably it would also be useful to wrap all the force_file/load_first_rom/force_file sequence in a single command)

[JamalMK]

I added a new command that override the file specified to user_io_file_tx. It seems that this is enough for core not requiring BIOS. E.g from a ssh session I can:

echo force_file /media/fat/NES/myrom.nes > /dev/MiSTer_cmd
echo load_core /media/fat/_Console/NES.rbf > /dev/MiSTer_cmd
echo force_file > /dev/MiSTer_cmd

and the NES core starts with the wanted rom. The last line is needed to turn off the override so that subsequent roms can be properly chosen from Osd menu.

The changes are very small: pocomane@c016472

My idea now is to write a new command that sends the right keys sequence to trigger a rom request. So I can load a rom with script sequence like

echo load_core /media/fat/_Console/NES.rbf > /dev/MiSTer_cmd
#
echo force_file /media/fat/NES/myrom.nes > /dev/MiSTer_cmd
echo load_first_rom > /dev/MiSTer_cmd # not implemented yet
echo force_file > /dev/MiSTer_cmd

(Probably it would also be useful to wrap all the force_file/load_first_rom/force_file sequence in a single command)

Any progress on this? I see a lot of the code has changed now. There is no longer a struct cmdentry even in input.cpp

[pocomane]

I made some change to support a prototype interface I was using for tests. Most of the code was moved to the dedicated file cmd_io.c (e.g. cmdentry is there). Moreover the "Input emulation" was added and it seems to work. However I reduced my efforts on it since I discovered that the feature is not of interest: https://misterfpga.org/viewtopic.php?f=27&t=524 .

I think that in the near future I will just:

• Align my fork to the current upstream
• Add a simple "Demo" mode, to give to the fork a sort of utility

As I said, I do not know If it worth to improve it further considering that no one is interested to it.

For sake of completeness, the "Demo" mode I was thinking to is a game-oriented mode that should work in the following way. When no input is received from the user in 5 minutes (configurable from ini), a random rom and core is started. Without inputs the game should also run the in-game demo, so, practically, you have a showcase of all your games continuously running. In any moment you can take the joystick and start playing. My idea is to use such system in a always-on cabinet.

[JamalMK]

The feature is very much of interest. I just want to be able to launch a rom via SSH. That's It. I know several other users who want this functionality too.

The core MiSTer developers are threatened by this because they think this will add bloat. This is false. MiSTer is already running SSH in the background. Implementing this feature will introduce no changes to OSD, no adding of a GUI. Nothing. There's literally no reason NOT to do this. This is an incredibly important feature which would allow the MiSTer to be remotely controlled via SSH, which opens up tons of options for app development.

Please let me know @pocomane if/when you merge your code into your forked version of current upstream. And @sorgelig, please reconsider.

[redbug26]

Please, do it ;)
I'm developing for Amiga with Minimig and the availability of such a command will be a big time saving

[pocomane]

After a discussion on the MiSTer forum (https://misterfpga.org/viewtopic.php?f=27&t=524), I re-implemented it as a standalone command. Maybe you can found it useful: https://github.com/pocomane/MiSTer_Batch_Control . There is a pre-compiled version in the release page, so you can just copy it somewhere on your SD and call it from command line.

I am also planning to create/maintain a script that automatically install/update a set of external utility like that one: https://github.com/pocomane/MiSTer_misc . It should work now already, but I still do not consider it "Deploy ready" :)

[Kitrinx]

You will find that while this works on some cores, it will fail completely on many others either by design, like atari 7800, or by technical limitation, like neogeo and many computer cores. Ultimately you will be creating a fragmented user experience, which will cause users to start demanding that cores that malfunction or don't conform to this to be 'fixed'. In the end, it limits what a core author can choose to do in their core if they have to code around this kind of input. You should give consideration to this fact when moving forward.