To Manuel: openMSX debugger | MSX Resource Center

Ascended (19685)

08-05-2017, 22:02

I'm not sure why it's not working. You shouldn't need an updated binary. The latest openMSX debugger binary should work fine. Is there perhaps some firewall issue? (The connection goes via TCP/IP, internally.)

By andrear1979

Expert (98)

08-05-2017, 22:28

Hi PingPong, I have:
- Win10
- openMSX 0.13.0 64bit
- openMSX debugger 32bit 0.10.0-246-g33957cc

and I confirm that debugger connection to openMSX is working for me, right now. The only relevant difference is that I don't use Catapult. I believe that Manuel's suggestion about firewall/antivirus is the most probable cause, else I'd try starting openMSX standalone. I guess 50% of the openMSXers played with the "-stdio" option at some time , maybe it's still enabled in some obscure config file around your filesystem... Hope it helps, cheers!

By Manuel

Ascended (19685)

08-05-2017, 22:37

The debugger doesn't use -stdio, though... and it's not something you can enable in a config file.

By PingPong

Enlighted (4156)

08-05-2017, 23:04

Manuel wrote:

I'm not sure why it's not working. You shouldn't need an updated binary. The latest openMSX debugger binary should work fine. Is there perhaps some firewall issue? (The connection goes via TCP/IP, internally.)

umh noissues with previous binary. Can you poijt me on which port does openmsx open to estabilish a connection with openmsx debugger? Do i need to do a netstat to find the port or it is a fixed default portno? To be sure i will do a telnet

By Manuel

Ascended (19685)

08-05-2017, 23:49

It will connect to a port that is in a file written by openMSX. I think 9938 is the typical port openMSX will start with, see also http://openmsx.org/manual/openmsx-control.html

However try the latest openMSX development build. Perhaps it makes a difference?

You can also try this newer x64 build of the debugger: http://openmsx.fixato.net/builds/windows/x64/debugger/

By PingPong

Enlighted (4156)

09-05-2017, 01:14

Thanks manuel i will try asap.

By Fudeba

Expert (113)

12-05-2018, 01:13

Just to register the solution...
It seems openMSX uses a different algorithm that the one used on openmsx debugger to determine where to put the socket.[pid] file. As a result, it is possible that openmsx places the file in one place and the debugger will look for it somewhere else.
The solution is identify where openmsx is creating the socket file and set %TMPDIR% (the place where the debugger looks for it) to point directly there.
This is the list of possible socket file directories (as described in https://openmsx.org/manual/openmsx-control.html ):

%USERPROFILE%\Documents and Settings\\Local Settings\Temp\openmsx-default
%TMPDIR%\openmsx-default or
%TMP%\openmsx-default or
%TEMP%\openmsx-default
C:\WINDOWS\TEMP

In my case, it was just a matter of running SET TMPDIR=%TMP% before starting the debugger.

Thanks to MTH for helping me with this issue. :)

By Manuel

Ascended (19685)

14-05-2018, 22:24

Fudeba: I think I have fixed this issue in the debugger. It will now use the same method to find the temp dir as openMSX is doing to create it. No more SET TMPDIR should be necessary. Please try it out: http://openmsx.vampier.net/openMSX_Debugger_x64_20180514.zip

By Manuel

Ascended (19685)

22-05-2018, 00:28

Any news, Fudeba?

By max_iwamoto

Paladin (674)

22-05-2018, 00:55

Manuel wrote:

Fudeba: I think I have fixed this issue in the debugger. It will now use the same method to find the temp dir as openMSX is doing to create it. No more SET TMPDIR should be necessary. Please try it out: http://openmsx.vampier.net/openMSX_Debugger_x64_20180514.zip

new openMSX debugeer!!! Yahoo!!!