Which asm/debugger is recommended

[sparhawk]

I had a A1000 back in the 90' and did a lot of assembly back then. However, I forgot many details, and now I'm starting almost from scratch. Well, I still do know a fair bot of the M68k, but I don't really remember much of the toolchain. I was using DevPac and even found my old disk (2.0). Now I have an A1000 again (KS 1.3) and I wonder if there is a good recommendation for a decent debugger. I gave MonAm a try, but I wondered if there is is something more modern now available.


I compiled bebbo's repository (https://github.com/bebbo/amiga-gcc) with MSYS2 and using that as my toolchain on Windows. In the repository there is vasm included, and I wanted to know if this is a good assembler to work with. From what I read so far, I think it can create object files which can be used together with gcc code as well, is that right?
I don't want to code everything in pure assembler, so I want something that I can use in conjunction with gcc.

[phx]

In the repository there is vasm included, and I wanted to know if this is a good assembler to work with. From what I read so far, I think it can create object files which can be used together with gcc code as well, is that right?

I won't give you any recommendations, but I am quite sure that it works. You only have to select the correct object file format for this gcc-port's linker.

[pipper]

Gcc and vasm cooperate nicely. Find examples here: GitHub.com/mheyer32/ADoom and github.com/mheyer32/DoomAttack

[sparhawk]

Thanks! I'll take a look at these links.

[sparhawk]

For the debugger I will stick to MonAm. I remember that I was using DevPack back then and liked it quite much. I even found now a manual (german) https://www.retrozone.ch/docs/amiga/HiSoftDevpac.pdf, because when I ran MonAm a few days ago, I was completely lost and didn't remember most of the commands.
Since I want to develop cross platform anyway it looks that vasm is a good choice.

[phx]

MonAm is a good choice, when debugging under AmigaOS. IIRC it also supports symbols. For OS2.0+ I prefer BDebug from the (now free) Barfly assembler package.

To debug software which takes over the system, the internal UAE-debugger is quite helpful. It is not as powerful as MonAm or BDebug, but you can debug every situation, even without an OS and with a switched-off display.

[mcgeezer]

I use MonAm with vasm too, it is very effective.

For deep bugs i debug with winuae.

Geezer

[Thomas Richter]

Originally Posted by phx

MonAm is a good choice, when debugging under AmigaOS. IIRC it also supports symbols. For OS2.0+ I prefer BDebug from the (now free) Barfly assembler package.

To debug software which takes over the system, the internal UAE-debugger is quite helpful. It is not as powerful as MonAm or BDebug, but you can debug every situation, even without an OS and with a switched-off display.

Quite similar preferences here. DevPac and MonAm are working nicely, and typically my first choice. If, however, you need to debug not-so-system friendly software, or the Os itself, then COP as a debugger has been proven considerably helpful for Os 3.1.4. development - it was just almost entirely as Os debugger. The UAE debugger is only a last resort, sadly....

[sparhawk]

What is lacking with UAE? I figured that an internal debugger from an emulator should be really helpful. I haven't done much with it yet, but from reading the manual I find the commands not really intuitive though.

[mcgeezer]

Originally Posted by sparhawk

What is lacking with UAE? I figured that an internal debugger from an emulator should be really helpful. I haven't done much with it yet, but from reading the manual I find the commands not really intuitive though.

It takes some getting used to the Winuae debugger.

However, it has features that make debugging some things simple.

For example, difficult corruption bugs are easy to find, you just set a memory watch for the whole area of memory where you are getting the corruption and it will break... it will even break if it's a blitter operation causing the corruption.

Really saved my bacon loads.

[Thomas Richter]

Originally Posted by sparhawk

What is lacking with UAE? I figured that an internal debugger from an emulator should be really helpful. I haven't done much with it yet, but from reading the manual I find the commands not really intuitive though.

Many, many things. Expression evaluation. Setting registers. Reading labels from a file with debug information. Capturing shell commands and new tasks. Stack traceback. System information (loaded libraries, resources, devices, resident-tags etc...), a suitable line editor with a history.

[Toni Wilen]

Actually it does almost all you listed but your "UAE" is probably something else. Anyway, it wasn't meant for that kind of purpose. (EDIT: = There are much better options for debugging system friendly programs)

[Antiriad_UK]

i did my last little project using a windows editor and compiling in devpac/asmone just to get back into it. I was following along photon’s video tutorials and it was a nice quick reminder rather than trying to remember 68k AND learn a new environment at the same time. It was hell to trouble shoot though (system killer demo).

Then I tried vasm and looked into some debugging options. You have to set breakpoints on memory areas like mcgeezer says in WinUAE. A little fiddly but powerful.

However I’d recommend using the visual studio code extension (another post in this forum). Which is all vasm based and uses a modified version of fsuae to work. You can set breakpoints directly in the source editor and launch your code and it will stop at breakpoint and then single step through code (even for system killer demos). Even if you don’t end up using the debugging features it’s a neat m68k syntax highlighter..

The way I use it currently:
- the “build” features are disabled. I build and run using a batch/make file and launch a self contained Amiga 500 session in WinUAE to quickly test in warp mode. Build and launch is only a few seconds. I’ve got a Lemon toolchain style build environment setup for this which I’ve updated to include latest tools/vasm. So 90% of the time I’m just using the extension as a highlighter. I can use the built in WinUAE debugger for finding obvious deadlocks.

- for bugs that I can’t easily find I then use the vs code extension to launch the same executable above which the runs a custom fsuae session and you can single step through code and see it in the source editor.

It’s a little bit tricky to setup but the author has created a test bundle that pretty much works straightaway. The only thing I’d say is that to enjoy working in this way you need to code in a modular way. That is no single file that includes hundreds of other files as it can confuse the debugger. But I’d say that’s a bad way to code these days anyway. Xref/def is your friend