Amiga Assembly extension for Visual Studio Code

[Tedward]

Thanks for a great development extension environment.
I have recently updated from release 20 to release 21 and have 2 problems:

NB: I develop under WSL2 on windoze

Attempting to run a previously working Amiga binary produces a connection request error unless I set the delayEmulatorStart to some high value. it then runs for the delay time then produces the failure to connect error(?)

Debug runs on the same binary start correctly then randomly hits a segmentation fault.

[prb28]

Hi, thanks...
Didn't though someone will use WSL2 on windows to run ! ...
Someone else uses winuae with wine...

I will try it, but you may consider using winuae it works really better on windows that this old version of fs-uae I used.

The seg fault, is some kind of side effect from the exception mask, you can reduce it in the launch parameters and set 60. It may be catching some normal interruptions.
I had a discussion on this thread : https://github.com/prb28/vscode-amig...bly/issues/135, and will change it in the next release.

[Geijer]

In WSL2 you get a separate ip stack with a private IP so if you run vscode in WSL2 and WinUAE/fs-uae outside of WSL2 (or the reverse) you cannot use localhost to connect to the debug port.

[prb28]

What is the benefit to use wsl2 ?
Is it to have a better build environment (gcc, bash, etc.) ?

[prb28]

I've just published the 0.21.1.
It may fix the wrong exceptions detection.

[Geijer]

Originally Posted by prb28

What is the benefit to use wsl2 ?
Is it to have a better build environment (gcc, bash, etc.) ?

Probably. Or maybe some other linux binary dependency in the tool chain.

If you convert the WSL2 "container" to WSL1 which shares the ip stack it will work, or port forward the "debug" port from WSL2 to windows.

[Tedward]

Thanks for the prompt responses.

Release 0.21.1 has fixed the segmentation error when debugging.
Still left with the failure to connect error when attempting to simply run from vscode.
Seems connected to the delayEmulatorStart argument - if I set it to 30000 the emulation runs perfectly for 30 seconds before failing with the connection refused error.

[prb28]

Originally Posted by Tedward

Still left with the failure to connect error when attempting to simply run from vscode.
Seems connected to the delayEmulatorStart argument - if I set it to 30000 the emulation runs perfectly for 30 seconds before failing with the connection refused error.

Can you explain your configuration please?

Is vscode connected to a directory in the wsl2 with the remote plugin?
fs-uae runs inside the vm or outside? (Ref post grom Geijer)
If it runs in wsl2: what do you use to export your display to windows (which xserver implementation)?

[Tedward]

1. connected to a directory within wsl2 using the remote plugin.
2. fs-uae is started within the vm (workspace/bin/fs-uae) and is accessible when debugging.
3. xserver is vcxsrv, display identity is exported from within the bashrc script when the session is started.

[prb28]

Originally Posted by Tedward

1. connected to a directory within wsl2 using the remote plugin.
2. fs-uae is started within the vm (workspace/bin/fs-uae) and is accessible when debugging.
3. xserver is vcxsrv, display identity is exported from within the bashrc script when the session is started.

Works for me with a debian wsl2 vm.

Do you have something blocking the port ?
(If you use a centos vm you must open ports)

[Tedward]

Am using Ubuntu 20.04 lts
I don't think the issue is the port because, as I said in a previous post, the emulation runs perfectly for the emulatorStartDelay period. ie it connects to the instance of fs-uae, loads the program and runs it until that start delay period expires. It is then that I receive the connection refused message. it is almost as if the extension is attempting to run the program a second time.
It worked at release 0.20.0 but fails at release 0.21.1.
Maybe I am doing something really silly in the launch.json that upsets this latest release!

[prb28]

Originally Posted by Tedward

Maybe I am doing something really silly in the launch.json that upsets this latest release!

I don't think it's the release, but, as always with computers... maybe..
To explain what's happening:

• You launch the command in the debugger
• fs-uae starts and wait's for a connection
• If it connects -> it's rolling... and you start debugging (not what happening)
• If not : after a timeout in fs-uae the "normal" boot sequence is started and the startup-sequence script runs so you see the program starting bug the debugger is not connected
• after a timeout in vscode you have an alert that the connection is not established

I think the socket connection is not established.

[Tedward]

I have got it!

The launch.json from the original wks example had a "type" of fs-uae-run.
This didn't work so I changed it to fs-uae and it seemed to work, but it is the "type" for debugging (of course!)
I see from your most recent amendment to that example you have changed it to
uae-run.
I have made the same change to my launch.json and it now works once again.

Many thanks for your time and effort with this and keep up the good work.

[prb28]

Great !
Yes I've updated my launch config for the examples. I forgot to commit before the release... sorry, it's confusing.

[JoeJoe]

Is it possible to deactivate the termination of the "Win UAE" programme after it has finished?

[prb28]

Originally Posted by JoeJoe

Is it possible to deactivate the termination of the "Win UAE" programme after it has finished?

Remove in the startup-sequence the line:

UAEquit

[JoeJoe]

Thx, but I dont have this in my startup-sequence.

[prb28]

So you want to "disconnect" the debugger and keep winuae running.
Sorry, there is no such option, the way to do it would be to set in the launch.json option : ""startEmulator": false" and start winuae in a different command line.

[JoeJoe]

Yes, that's right. I will run "avail" after quit my programm to check memory or run it again.

[emiespo]

Originally Posted by prb28

I don't think it's the release, but, as always with computers... maybe..
To explain what's happening:

• You launch the command in the debugger
• fs-uae starts and wait's for a connection
• If it connects -> it's rolling... and you start debugging (not what happening)
• If not : after a timeout in fs-uae the "normal" boot sequence is started and the startup-sequence script runs so you see the program starting bug the debugger is not connected
• after a timeout in vscode you have an alert that the connection is not established

Hi, let me say that the Amiga Assembly extension for VSC is really great, and express my gratitude.

Following up on this example I have a question: is it possible to launch the debugger as if the exec were launched via CLI? While debugging I can't open a library that is not in ROM (asyncio), and that is stopping me from being able to properly debug.