Debugging my dodgy asm!

Hey guys,

I've been lurking on this board for a while now trying to learn 64k ASM and so far enjoying the challenge! :-D

I'm using WinUAE (sorry hardwareophiles!) and assembling using the WinUAE Demo Toolchain (vasmm68k)

I'm basically after a bit of advice generally about how to debug code.

I was wondering if there is a way to trace out debug information to a console whilst my program is running?

Also what's the best tool to use to step through code? I've tried using WinUAE's built in debugger but I'm unsure how to hone in on my code. I guess I should google how to add break points but I'm unsure what address my code would start from as isn't the memory assigned dynamically?

Any help, tips or tricks would be most appreciated and apologies if this has been answered somewhere else already (I'll have another blast at searching through the forum)



Cheers,
Jim

P.S should I be using an action reply type of rom?

[WayneK]

Well probably the fastest/easiest way to solve your problem is...stick a "mousewait" before the bits that are troubling you, this way you can run your program, be confident it's waiting for a LMB press (maybe set the background colour to RED for stop, to be sure), open the WinUAE debugger and you'll see your mousewait loop, with the problematic code following it and you can then set your breakpoints accordingly ("f <address>" in the debugger).

.mousewait
btst #6,$bfe001
bne.s .mousewait
<code giving you problems>

There are a million better ways (probably more!), but this should get you started at least

Move.l #palm, $F4CE ; Groan

I should have thought of that haha

Cheers Wayne! (And quite a speedy response too)

From there I'll know where my code is in memory and should be able to poke about using WinUAE.

Legend

[Leffmann]

Another good way is to insert bogus instructions like "move.l A0, A0" in your code and telling the WinUAE debugger to break on this OP-code. This way it works like a real breakpoint, with no effect on registers or condition codes, and you get to see the complete machine state in the exact instant the breakpoint is reached.

[Photon]

Hypnoshock, take advantage of the forum structure to let frequents find new threads and give help quicker. (I found this via Today's Posts.) I moved it to the asm forum for you.

Top tip: You can subscribe to this or any forum if you want to follow it via your inbox.

I use the Asm-One debugger with an option to not turn off 2 of the interrupts when I code demos.

Originally Posted by Leffmann

Another good way is to insert bogus instructions like "move.l A0, A0" in your code and telling the WinUAE debugger to break on this OP-code.....

Nice tip Leffmann, I didn't even know the WinUAE debugger could do that! I'm going to try that right now.

I recognise your avatar so it's nice to finally get to say hi to someone whose posts I must have learnt from recently.

When I get a bit better at ASM I'll have a proper look through your Quartex cracktro remake. It would probably be a bit wasted on me at the moment as I have only just learnt how to set up copper lists but still completely clueless on setting up playfields and using the blitter.

@Photon, Thanks for moving my post into this part of the forum. I think I've now found my home away from home ;-D

I'll have to give that ASM-One debugger a look at some point... I've got a real 1200 gathering dust so it'll be nice when I get a bit better at this to migrate my coding efforts to a real Amiga. For now it's easier to use the tool chain alongside the internet.