How does debugging in Altirra work?

[Tyrop]

I'm trying to animate some sprites in assembly langauge (in Gr. 8 ) and I am getting some sections of my sprites disappearing depending on where they are on the screen. I just downloaded Altirra and it is truly amazing. Is there any documentation on how to use it for debugging? I don't know what the difference is between using F11 and F10. What is the line that goes across the screen when you step? Is that a simulated electon beam that shows where the beam is in relation to the instruction being executed in the disassembly window? Is it possible to watch sections of memory change while stepping through the disassembly? For that matter, is it possible to keep an eye on the values of certain byte or word variables while single stepping?

Edited November 24, 2010 by Tyrop

[Rybags]

Line = simulated electron beam.

 

AFAIK the RAM Window only updates when you tell it to, ie click on the value part, press ENTER.

 

Grab the test 1.8 Altirra if you don't already have it, it's improved in many areas.

 

Another nice trick is Breakpoints - you can use a read breakpoint on an address that otherwise would never be touched to trigger one, e.g. BIT $D7FF.

 

Then there's the Trace, but you can get a huge amount of data there fairly quickly.

 

But you can use the Trace cleverly in conjunction with Breakpoints. Have the first breakpoint just before your sprite code.

Then start the trace with another Breakpoint set to trigger at the end of your sprite code.

The nice thing about trace is that it includes the active scanline position, plus lets you expand/collapse subroutine and interrupt calls.

 

But, if you are doing softsprites and they're getting tearing, then it's probably a sure thing that your code is updating them while being displayed.

 

It's good practice to do such tasks sychronised with a specific part of the screen. Sometimes starting update in VBlank is fine.

 

But if you have quite a bit to update or are getting tearing, then it might be an idea to actually just have a DLI just before the last display portion of the screen, and commence the update there.

 

The DLI doesn't necessarily have to perform the sprite updates (or the VBI for that matter). You could just use it to set a flag which the main loop monitors and knows when it's safe to do an update.

Edited November 25, 2010 by Rybags

[phaeron]

Step Into (F11) and Step Over (F10) differ in how they deal with subroutines and interrupts. Step Into always executes one instruction, and will step into a subroutine invoked by JSR or an interrupt routine. Step Over, however, will skip the subroutine/interrupt. If you step into an unwanted subroutine you can back out with Step Out (Shift+F11).

 

The History window, which I presume is what Rybags means by trace, is indeed the recommended way to debug. You need a recent test version in order to get subroutine collapsing and effective address display. This is the current latest test release:

 

http://www.virtualdub.org/beta/Altirra-1.8-test29.zip

http://www.virtualdub.org/beta/Altirra-1.8-test29-src.7z

 

The memory window actually should be updating every time you step, but it's possible I broke something. I've been working on reducing spurious updates as they tend to cause the disassembly window to hop.

 

Currently, the only on-screen ways to watch variables are the memory window, or by the wb/ww/wc/wl commands (which only update once a frame). I'd like to put in a Watch window like Visual Studio's, but I need to add support for debugger expressions first.

 

If you aren't doing so already, make sure you are generating listing and labels files for your executable. With MADS, these are the -t and -l options. Doing this will enable symbol display and source level debugging.

[Tyrop]

Thanks for advice Rybags, I think you are right about the timing. I did have a "wait for next VBI" before I drew, but there must be an issue with it.

 

If you aren't doing so already, make sure you are generating listing and labels files for your executable. With MADS, these are the -t and -l options. Doing this will enable symbol display and source level debugging.

 

I took the suggestion from other posts and I am using Eclipse with the WUDSN plug-in and ATASM. I am using the -v (prints assembly trace) and -s (prints symbol table) command line options but for some reason, ATASM is not creating either file. If I can figure out how to get ATASM to create the assmbly trace and symbol table, 1) will the formats work with Altirra, and 2) how do I get them into Altirra?

[Rybags]

I think they just get sent to CON:

 

Unsure if you can direct stuff to seperate files but at the least, you might be able to setup Eclipse to capture the CON: output.

 

Still using AtAsm with EditPlus here... works nicely but I think it's getting near time to go Eclipse + MADS.

 

ed - actually if you can't capture output you could probably use pipe to chuck it into a file.

Edited November 25, 2010 by Rybags

[Tyrop]

If I want to use ATASM, how do I get the listing and label files into Altirra?

 

BTW, following phaeron's suggestion, I assembled the example program on the WUDSN website using MADS and I used the -t -l options. THe result was 2 files in the same folder as the example.xex file: example.lab and example.lst. Using ALtirra, I simply opened the example.xex file, and when I went into the disassembly window, I saw the labels. I saw the labels even though I did not do anything to separately load a label or listing file (which I think you are supposed to do using the .loadsym command from the console). Does this mean that ALtirra automatically looks for the listing and label files when you open the xex file? This leads me back to ask, how do I do this with ATASM? (I'd rather use ATASM over MADS at least for now).

 

Altirra is an unbelievable piece of work. The fact that it shows the beam, and also traces my program even through the VBI completely floors me. I'm coming from trying to debug my program with EXDDT (Extended Dunion's Debugging Tool), on the real hardware which also amazed me because you can switch back and forth between the disassembly screen and the graphics screen and watch your program execute in slow motion. But Altirra's ability to single step in relation to the beam has got to be a dream for anyone debugging graphics.

[Rybags]

Your own labels won't appear just from loading an executable.

 

The normal OS equates for RAM-based variables should be there by default though.

[Tyrop]

Your own labels won't appear just from loading an executable.

 

The normal OS equates for RAM-based variables should be there by default though.

 

It had the system labels, but also had the labels START and LOOP:

[phaeron]

Altirra attempts to autoload foo.lst and foo.lab whenever it runs foo.obx/xex. Looks like you've got labels hooked up. You can also use these labels in debugger commands that take addresses: bp start.

 

The symbols in your executable override the included system symbols. Unfortunately, this means that some hardware registers won't decode properly once you've included labels for them, because the assembler doesn't distinguish between read-only and write-only register symbols, and thus you get goofs like STA POT0 and LDA AUDF1. I need to force the built-in hardware symbols to higher priority.

[Tyrop]

Altirra attempts to autoload foo.lst and foo.lab whenever it runs foo.obx/xex. Looks like you've got labels hooked up. You can also use these labels in debugger commands that take addresses: bp start.

 

 

Do you know if ATASM can create the lab and lst file that will work? It creates a label file but it may notbe the exact same format as the one that MADS creates. As for the .lst, I cannot get ATASM to create it even by trying to pipe to a file.

Edited November 27, 2010 by Tyrop

[phaeron]

ATasm label files (-l) will not currently work as there is no support for them. I'm working on some code to parse them.

 

ATasm doesn't seem to output a listing comparable to MADS's listing output, so it doesn't look like source-level debugging will be possible. The -v listing does output addresses and source lines, so I could implement listing-level debugging, but it doesn't have source filenames or line numbers.

[Tyrop]

Phaeron, thanks for the answer. I've been putting off learning MADS but maybe its time I learned it and converted my source code to MADS syntax so I can have source-level debugging.

[flashjazzcat]

Phaeron, thanks for the answer. I've been putting off learning MADS but maybe its time I learned it and converted my source code to MADS syntax so I can have source-level debugging.

MADS+WUDSN+Altirra = a compelling argument for doing so.

Edited November 28, 2010 by flashjazzcat

[ilmenit]

MADS+WUDSN+Altirra = a compelling argument for doing so.

 

I started to use these 3 tools to write my next program and I love the combination!

Thank you!

[Tyrop]

I know this may be covered in other threads but I could not find the answer. Is there an English translation for the MADS instructions? I got many errors assembling my code written for Atasm. For instance, how do you .include? I will also see if I can figure out how to get WUDSN to create a listing file using ATasm, and then I will try to manually convert Atasm's listing and label file to MADS's format.

[phaeron]

I posted a newer test version that supports ATasm labels:

 

http://www.atariage.com/forums/topic/168813-altirra-17-released/page__view__findpost__p__2145698

 

No direct support for ATasm listings yet, though.

 

To include another file in MADS, use the ICL directive, i.e. ICL 'file'. There are some translated docs floating around this board, I think, but I'm usually just lazy and use Google Translate on the online docs page. IIRC you'll usually also have to translate .byte and .word into DTA directives.

[flashjazzcat]

This is my latest attempt at a translation:

 

MADS Assembler - English Translation.TXT

 

.byte and .word are quite permissible in the latest versions of MADS (although this may not always have been the case).

Edited November 28, 2010 by flashjazzcat

[Tyrop]

This is my latest attempt at a translation:

 

MADS Assembler - English Translation.TXT

 

.byte and .word are quite permissible in the latest versions of MADS (although this may not always have been the case).

That is great, thank you! It looks like a real powerful assembler.

[Bryan]

Still using AtAsm with EditPlus here... works nicely but I think it's getting near time to go Eclipse + MADS.

 

I'm messing with it (Eclipse, WUDSN, MADS) right now. It seems really powerful but I'm really nervous going from a fairly simple editor like Textpad to one that has a million features I don't really understand. I'm scared I'll click something and screw it up forever.

 

Right now I'm trying to get it to launch Altirra properly.

 

EDIT: Got it working! Now I'm wondering if I can make Eclipse color the system register names (so I know when I've typed COLBAK instead of COLBK).

Edited December 1, 2010 by Bryan