Amiga Assembly extension for Visual Studio Code

[prb28]

Originally Posted by hooverphonique

Btw, I think there's a rogue "emulator" line in launch.json line 9.

Yep, useless.

Originally Posted by hooverphonique

I made a couple of pull requests for some fixes to gencop.s btw

Thanks !

[Hannibal]

I finally got around to try this, and it is very impressive, thank you for doing all this work.
I ran into one issue - not sure if this is just me: using the sample workspace, I can place/remove breakpoints before launching, I can step over and into just fine. However once I hit the first breakpoint, I can’t place or remove any breakpoints - if I do, the emulation in fs-uae will hang. This is on Windows 10.

[prb28]

Originally Posted by Hannibal

I finally got around to try this, and it is very impressive, thank you for doing all this work.

Thanks.

Originally Posted by Hannibal

I can’t place or remove any breakpoints - if I do, the emulation in fs-uae will hang. This is on Windows 10.

Maybe something new in windows 10 or vscode...
I'll try it later this weekend.

[prb28]

Originally Posted by Hannibal

I ran into one issue - not sure if this is just me: using the sample workspace, I can place/remove breakpoints before launching, I can step over and into just fine. However once I hit the first breakpoint, I can’t place or remove any breakpoints - if I do, the emulation in fs-uae will hang. This is on Windows 10.

Same behavior on my windows 10.
I've added an issue to github: https://github.com/prb28/vscode-amig...mbly/issues/96



Thanks for reporting... now it's time for debugging

[Hannibal]

Yay, it is not just a bug on my machine :-)

Now for me to figure out how I can configure my code to work with it

[Antiriad_UK]

I don't know if something has changed on 0.18 but my breakpoints are no longer working. If I download the example workspace and build/run within VSCode then it works ok. But if I compile outside of VSCode and then debug it stops on entry fine (and can single step). But any breakpoints I've set are ignored and if I hover over them in vscode it says "Debug information not resolved retrieved"

This is on Win10.

Edit: Here's an example, just create a batch file in the root of your example gencop workspace and run it to compile. Then run the debug from vscode and see if it stops and and/or gives the debug not resolved message above.

set ObjDir=Build
set OutDir=fs-uae\hd0

set BuildParam=-m68000 -Fhunk -linedebug
set LinkParam=-bamigahunk -Bstatic

bin\vasmm68k_mot.exe %BuildParam% -o %ObjDir%\gencop.o gencop.s
bin\vlink.exe %LinkParam% -o %OutDir%\gencop %ObjDir%\gencop.o

Edit: If I download the 0.17 example bundle/bin files and roll vscode back to 0.17 the above works. Hmm. Maybe something changed in file path/debug info code and it's no longer able to resolve paths?

[prb28]

Originally Posted by Antiriad_UK

I don't know if something has changed on 0.18 but my breakpoints are no longer working.

Maybe the integration of the new version of vasm is in cause...
Thanks for the bat, I'll try it as soon as I can add a new breakpoint with the extension !

Originally Posted by Antiriad_UK

If I download the 0.17 example bundle/bin files and roll vscode back to 0.17 the above works. Hmm. Maybe something changed in file path/debug info code and it's no longer able to resolve paths?

Going back to 0.17 is a good solution (sorry about that).
There is the new vasm/vlink and a resolution of the upper case files in debug that can mess with the breakpoint resolution, and maybe the last version of vscode has some new behavior.

Yes there is something with the breakpoints in 0.18 on windows (works on osx my dev platform). I'm still digging...

[prb28]

@Antiriad_UK and @Hannibal

Could you please try this fix ?

https://github.com/prb28/vscode-amig...indows_x64.zip

It was a bug in my fs-uae modification in release mode. The -O2 optimization of GCC added some strange behavior on my poorly coded C code.

Sorry for the trouble.

[prb28]

Originally Posted by Antiriad_UK

Maybe something changed in file path/debug info code and it's no longer able to resolve paths?

This is not fixed... it's not the same bug, I've added a github issue : https://github.com/prb28/vscode-amig...mbly/issues/97

[Antiriad_UK]

Yeah just tested, it was the same. Sorry!

[prb28]

Originally Posted by Antiriad_UK

Yeah just tested, it was the same. Sorry!

Not a solution... but a workaround, add to your launch.json configuration :

"sourceFileMap": {
    "C:": "c:"
}

As you can see my path to the upper case debug files has some flows...
I'll fix that in next release.

[prb28]

0.18.1 is out with new binaries for windows and osx.

@Antiriad_UK: you issue should be fixed now!
Thanks for testing!

[Antiriad_UK]

Originally Posted by prb28

0.18.1 is out with new binaries for windows and osx.

@Antiriad_UK: you issue should be fixed now!
Thanks for testing!

Thanks. I'll try tomorrow morning and let you know.

[Spec-Chum]

Originally Posted by prb28

0.18.1 is out with new binaries for windows and osx.

Will these help with https://github.com/prb28/vscode-amiga-gcc-example as well?

Be cool to have a debugging IDE for bebbo's GCC.

[prb28]

Originally Posted by Spec-Chum

Will these help with https://github.com/prb28/vscode-amiga-gcc-example as well?

Be cool to have a debugging IDE for bebbo's GCC.

I've just tried it and it seems to work, my explanations are really too sparse.


It uses another way to build and debug. It's the C/C++ extension that does the most part of the work and gdbserver is connected to a gdb instance in your host system.



I can try to help you to make it work (pm me if you want).

[Hannibal]

I tried 0.18.1, but I still saw the same problem. Is there anything else I have to do other than let VS.Code install the update, and then restarting VS.Code? Do I need to restart my PC? clean and recompile? download a new example repo?

[prb28]

Originally Posted by Hannibal

I tried 0.18.1, but I still saw the same problem.

Yes you need to get the new bin directory: https://github.com/prb28/vscode-amig...indows_x64.zip


For you bug the fix in the fs-uae binary executable.

[Hannibal]

after updating the bin files it works perfectly, thank you for fixing it so quickly

[hooverphonique]

I have noticed 2 issues in 0.18 (windows 10) with the debug configuration using the example workspace:
1) The output binary (fs-uae\hd0\gencop) is not updated when pressing start, so it fires up an old version - when using the run configuration it's ok.
2) When starting, the emulator runs "twice" before returning to the ide (i.e. after clicking lmb to exit gencop, it reboots and runs gencop, and I have to click lbm again). Maybe it's related to 1)?.

I will try 0.18.1 and see if it helps.

Edit: I still have these 2 issues with 0.18.1 of the extension and the binaries. I've added debug output and fs-uae log.

[prb28]

Originally Posted by hooverphonique

1) The output binary (fs-uae\hd0\gencop) is not updated when pressing start, so it fires up an old version - when using the run configuration it's ok.

This is due to the launch.json configuration, please modify the debug configuration :

"buildWorkspace":true

I certainly modified it by mistake. I'll fix that.

Originally Posted by hooverphonique

2) When starting, the emulator runs "twice" before returning to the ide (i.e. after clicking lmb to exit gencop, it reboots and runs gencop, and I have to click lbm again). Maybe it's related to 1)?

This is due to the difference between the debug and release launch.
In Run mode there is no injection so the binary is launched by the Startup-Sequence.In the fs-uae Debug mode the binary is injected in fs-uae at initialization before the Startup-Sequence started. So when it's done the normal amiga emulation start with a startup-sequence and re-runs the gencop binary.
If you don't want it in debug, remove the gencop line in Startup-Sequence file and keep UAEquit call (to have a gentle exit).