Debug your MSX with VSCode | MSX Resource Center (Page 6/7)

Par S0urceror

Master (210)

30-07-2020, 22:06

Briqunullus wrote:

It works great! All I need now is a real project.

Good to hear. Finding a project is the fun part!

Par wouter_

Hero (525)

31-07-2020, 17:50

S0urceror wrote:

On Windows not only the socket mechanism is different but somehow it was decided it was a good idea to add enterprise level security as well. This complicated the interface with OpenMSX somewhat.

Yeah, that's unfortunate.

On most operating systems we use 'UNIX domain sockets' for the communication between openMSX and external programs. Unfortunately, 15 years ago when we initially added this feature, this mechanism was not yet(*) available in windows. The mechanism that comes closest are regular (local) TCP sockets. However, unlike UNIX domain sockets, these allow connections from any local user (so not just the user that's running the openMSX process). It's possible to send arbitrary Tcl commands over the connection with openMSX, so also stuff like exec del important.doc. Therefor we decided to add this extra layer of security.

(*) Apparently recent versions of windows may now also support UNIX domain sockets. Though this still seems too new to already start depending on it in openMSX :(

Par S0urceror

Master (210)

03-08-2020, 10:02

Quote:

Therefor we decided to add this extra layer of security.

Agree extra security is necessary. Another option is using TCP/IP on all platforms with platform neutral security. Something that is portable across platforms. To make OpenMsX clients code similar.

For now no issue because I have it working on Windows (at the expense of having binary bindings with Windows DLLs in otherwise platform neutral Typescript code).

Par h0ffman

Rookie (23)

27-10-2020, 13:03

sorry if this is a more vs code related question but I'm hoping someone can help. I've got the debugging setup and working but it requires me to launch openmsx before debugging. The problem is that I'm developing a cartridge and openmsx has a file lock on my binary so I have to keep closing and re-opening openmsx before building / debugging.

Is there a way to configure the launcher to automatically start the emulator and close it when you stop debugging?

Par S0urceror

Master (210)

28-10-2020, 07:45

Can you use the commandsAfterLaunch attribute to let openmsx eject and reinsert the cartridge? You can use any command that works in the openmsx console.

Par h0ffman

Rookie (23)

28-10-2020, 16:09

Thanks @S0urceror, i'll give that a try.

Par ToriHino

Paladin (858)

30-01-2021, 11:46

Grauw wrote:

I tried it and it’s connecting and generally working (macOS btw).

However when I try to set a breakpoint I get this error in the debug console:

Unverified breakpoint:{"verified":false,"line":71,"column":0,"source":{"name":"Player.asm","path":"/Users/grauw/Development/gngplay/src/Player.asm","sourceReference":0}}

Any idea what that could be about? I used the filter for Glass.

I also get this same problem, running under Windows with Sjasm Plus, even with a very simple program. Was there already a solution for this?

Par ToriHino

Paladin (858)

30-01-2021, 17:07

Moving INCLUDE to the end of the file main file (or at least after the breakpoint(?)) solves the problem. Breakpoints are working fine now.

Par fpracek

Resident (51)

21-09-2021, 20:02

I receive this error running the project: 'remoteType': Remote type "openmsx" does not exist. Allowed are zrpc, cspect, zxnext, zsim.
With zsim in luncher.json the project runs, but no iteraction with openmsx exists.

Par S0urceror

Master (210)

21-09-2021, 21:32

Did you install the OpenMSX compatible version of Dezog via the command line? Not the version of Dezog that you can find in the official extensions list. That version only support ZX Spectrum emulators and the Next.