openMSX Remote control from DOS/Batch

ページ 1/2
| 2

By ericb59

Paragon (1124)

ericb59 さんの画像

16-12-2022, 11:00

Hello,
I need help to set up the possibility to command openMSX remotely from a Dos/Batch script.
It is written in the documentation that we must use a "named pipe". I am not familiar with this concept under DOS. Can anyone give me a concrete example of how to do this?
(openMSX.exe -control pipe)

From the Shell under MacOs I succeeded by doing this, but I can't manage to do the same thing under dos.

Shell example that I want to port to DOS

  lli="${OPENMSX_APP_PATH}${OPENMSX_APP} -control stdio -machine ${MSX_MACHINE} -script ${MSX_MACHINE_SCRIPT_PATH}${openMSX_Script}  ${CARTRIDGE_SLOT_A}"

 (
      echo ""
      echo "filepool add -path /WorkingFolder/openMSX/share/systemroms -types system_rom"
      echo "set power on"
      echo "set renderer SDL" 
       echo ""
       ) | ${lli}
ログイン/登録して投稿

By Manuel

Ascended (19677)

Manuel さんの画像

17-12-2022, 00:16

Something like this? https://stackoverflow.com/questions/3670039/is-it-possible-t...

The openMSX Catapult application uses named pipes under Windows to control the openMSX instance it starts. But that's a C++ application...

By ericb59

Paragon (1124)

ericb59 さんの画像

17-12-2022, 03:39

Thank you manuel, but it's not more clear for me with your link. oO

But that's okay, after 2 days of researching to make something working with a "named pipe", I found out that controlling with STDIO works fine with windows. Question
A slight modification of my script is therefore sufficient.

The documentation here http://openmsx.org/manual/openmsx-control.html
misled me into thinking that only the "-control pipe" option worked on windows.
maybe it's not clear in the manual, or it's just me ?

By Manuel

Ascended (19677)

Manuel さんの画像

17-12-2022, 10:31

There is probably a reason why the manual suggests named pipes on windows... But as this was developed like 17 years ago, it may not be a good reason anymore... Without a Windows expert, we can't tell. But I'm glad it's working for you now!

By aoineko

Paragon (1134)

aoineko さんの画像

17-12-2022, 11:21

I don't understand why you use such a complicated notation instead of just using the command parameter in your OpenMSX command line?

Unless I'm missing something, you could have the same thing by adding to your command line:
-command "filepool add -path /WorkingFolder/openMSX/share/systemroms -types system_rom" -command "set power on" -command "set renderer SDL"

BTW, this is off topic, but I don't think it's a good idea to override the user's configuration by forcing software renderer.

By Manuel

Ascended (19677)

Manuel さんの画像

17-12-2022, 11:43

Good point, if you don't need to change stuff after starting, you don't need the pipes at all.

By ericb59

Paragon (1124)

ericb59 さんの画像

17-12-2022, 14:33

aoineko wrote:

I don't understand why you use such a complicated notation instead of just using the command parameter in your OpenMSX command line?

Unless I'm missing something ...

Yep... you are missing something. Wink
You will see...

By ericb59

Paragon (1124)

ericb59 さんの画像

17-12-2022, 15:42

or Maybe I was wrong... LOL!

By ducasp

Paladin (712)

ducasp さんの画像

17-12-2022, 15:46

aoineko wrote:

I don't understand why you use such a complicated notation instead of just using the command parameter in your OpenMSX command line?

Unless I'm missing something, you could have the same thing by adding to your command line:
-command "filepool add -path /WorkingFolder/openMSX/share/systemroms -types system_rom" -command "set power on" -command "set renderer SDL"

BTW, this is off topic, but I don't think it's a good idea to override the user's configuration by forcing software renderer.

Pipes or similar software communication interfaces allow you to control it at any time, that is how the debugger works with it, and how the official front end does, so it can command it on the fly, not only at start-up. It also is quite nice that allows anyone to create a powerful debugger, i.e. You could have a GUI C software like visual studio controlling breakpoints, etc... Not that anyone did that, but it is a cool feature that might sound like a bazooka trying to kill a fly if all you care is start up configuration and nothing else

By aoineko

Paragon (1134)

aoineko さんの画像

17-12-2022, 16:38

I know but in Eric's case, if it's just to launch OpenMSX via a command line, I don't see the point of not doing it synchronously.
I don't see any case where it would be useful, from the emulator launch script, to send data after the launch.
But maybe Eric sees a useful case.

By Manuel

Ascended (19677)

Manuel さんの画像

17-12-2022, 22:08

Note that the renderer and power setting are only relevant for the pipe/stdio use.

Can't remember how to set the renderer back to the user's choice though (which may not be default).

ページ 1/2
| 2