Debugging using Altirra

[+Cafeman]

All very helpful, thanks guys. 

 

All I needed to do in this  case was figure out how much memory was free in BANK1 which gets swapped into $8000-$9FFF during VBI for the sounds/music engine. SO I needed to break while the code in Bank1 was executing, and then check memory;  else, I'd be examining another Bank in $8000-$9FFF.  Not sure if there was an easier/more logical way to accomplish this. 

 

So I found out for the first time that I'm only using from $8000-$8A90 in bank1, so I calculate I have over 5400 free bytes left which is far more than I'll need to add a few new ditties and sounds to Adventure II XE. 

[phaeron]

Ah, yeah, you don't need to do that. Just view $04'4000 or similar in the debugger console or memory window, or in earlier versions, use the linear form x:$14000 (.bank will show the linear address for the current bank).

 

In the debugger, $0000-FFFF always gives you the CPU's current view. Many places accept an extended or global address, which then lets you override this to access specific memory layers. $xx'yyyy is the global address form for directly accessing extended memory at $yyyy for PORTB bank $xx. You can also access RAM under the OS ROM or extended memory window with r:$xxxx and access the OS ROM regardless of PORTB state with rom:$xxxx, where $xxxx is the CPU address where the RAM or ROM would be if visible.

 

[+Stephen]

2 hours ago, phaeron said:

Ah, yeah, you don't need to do that. Just view $04'4000 or similar in the debugger console or memory window, or in earlier versions, use the linear form x:$14000 (.bank will show the linear address for the current bank).

 

In the debugger, $0000-FFFF always gives you the CPU's current view. Many places accept an extended or global address, which then lets you override this to access specific memory layers. $xx'yyyy is the global address form for directly accessing extended memory at $yyyy for PORTB bank $xx. You can also access RAM under the OS ROM or extended memory window with r:$xxxx and access the OS ROM regardless of PORTB state with rom:$xxxx, where $xxxx is the CPU address where the RAM or ROM would be if visible.

 

Does that style of addressing also work for seeing VBXE RAM (such as the XDL)?

[phaeron]

1 hour ago, Stephen said:

Does that style of addressing also work for seeing VBXE RAM (such as the XDL)?

Yes, v:$xxxxx will get you $xxxxx in VBXE RAM by linear addressing.

 

[Heaven/TQA]

All the VBXE demos I have written were not possible without Altirra debugging features for VBXE... 

 

btw. As C64debugger got a nice forward/backwards time line.... any chances?

[Mclaneinc]

There is a certain person here who not only does very entertaining videos but also has the knowledge who I i'd love to see doing a beginners guide to debugging in Altirra and maybe an advanced version for people with more than my IQ

 

So what you say @flashjazzcat?

 

As an as and when idea for a cold rainy day....Maybe...

Edited December 30, 2019 by Mclaneinc

[flashjazzcat]

9 minutes ago, Mclaneinc said:

So what you say @flashjazzcat?

 

As an as and when idea for a cold rainy day....Maybe...

Since we have nothing but cold rainy days for at least fifty per cent of the year here in the UK, you'd think I would have already done this twenty times over, but sadly it doesn't always work out that way.

 

But it's a good idea, and the suggestion is well received. The only thing I worry about is that I can't keep up with all the usability improvements Avery keeps sneaking into the debugger, so it's possible that my methodologies aren't necessarily the most efficient. I didn't even know about the addressing of different layers in the memory windows as just explained by Avery; I knew and had experience of inspecting high 65C816 RAM, but I did not know one could explore PORTB RAM, Shadow RAM, etc, so conveniently. I think the only thing more useful than a beginner's debugging video by yours truly would be a debugging video by Avery himself, but in the absence of the latter I'll add it to the to do list.

Edited December 30, 2019 by flashjazzcat
typo

[Mclaneinc]

Thanks FJC, I don't expect you to update it etc, just a nice old basic video, how to display mem, how to change mem, how to set breakpoints and the like, pure simple as stuff. Sure I'd love Avery to do a video but I know he's a mega busy guy and does not seem to like the lime light which is fine. Btw, not saying you are not busy but you do have a way with vids and got the brain matter to do these things

 

I think your presentation style would smash it, there's always room for irony, wit and sarcasm along with good old fashioned info....Oh don't forget the elevator music

 

I've always found Altirra's debugger a little intimidating, I'm more Omnimon and I know Avery's idea is to have it do as much as any programmer / dev needs but old gits like me (and i think we have a few on here) could do with a gentle introduction...

 

Anyway, thanks for liking the idea...Glad you spotted my devious use of the cold rainy day notion, I expected no less...

Edited December 30, 2019 by Mclaneinc

[RetroCoder]

For those interested in debugging asm code in Altirra. I've created a Visual Studio code extension that lets you use ATasm to assemble your code and Altirra to run and debug it.  The extension allows you to use source level debugging with breakpoints being set in your assembler code

 

https://marketplace.visualstudio.com/items?itemName=cerebus.atasm-altirra-bridge

[+Cafeman]

On 9/10/2013 at 1:41 AM, phaeron said:

To set a breakpoint, use [bp address]. [bl] lists breakpoints, and [bc] clears breakpoints (by index, not address). The index is shown in [bl] output or when you set the breakpoint, i.e. "Breakpoint 0 set at address $A000." Use [bc *] to clear all breakpoints.

I can't figure out Breakpoints! I'm using Altirra64 v3.9.  Running a 32K 5200 ROM of my own.   I found where I'd like the run the game and stop at the LDA $20 which I found is at $6B53 in memory. It was tedious to find it, by the way.   I click Enable Debugger, and then Break (which allows me to see the disassembly code and enter comands in the Console window).  

 

1. I enter "BP $6B53" . 

 

Altirra> bp $6b53
Breakpoint 0 set at $6B53.
 

2. Now what? I have to click Enable Debugger again (turning it OFF) to get back to playing the game. But this seems to turn off the debugger completely and loses my set Breakpoint.  There is a Debug Window called "Debug Display" , but it isn't real-time and doesn't even show the sprites , just off-color background.  

 

I've used Watch Byte (wb) many times but can't figure out the BP.  In the past I used other emulators like Atari800win and even VSS-Debug to do this type of thing.  

 

Any suggestions? 

 

    6B53: A5 20             LDA $20      <== I want the game to break here, then have Altirra let me step through the code statements
    6B55: 8D 62 03          STA $0362
    6B58: A5 95             LDA $95
    6B5A: 8D 63 03          STA $0363

[phaeron]

1 hour ago, Cafeman said:

2. Now what? I have to click Enable Debugger again (turning it OFF) to get back to playing the game. But this seems to turn off the debugger completely and loses my set Breakpoint.  There is a Debug Window called "Debug Display" , but it isn't real-time and doesn't even show the sprites , just off-color background. 

Don't close the debugger, just use the g (go) command, or Debug > Run/Break to resume execution. The Debug Display window is for viewing screens that are not the current screen or that haven't been rendered yet; you can just use the regular Display window once execution resumes.

[+Cafeman]

If I hit run/break, it doesn’t return me to the game screen. I’m still looking at the console window, memory, and disassembly debugger windows. So how can I try to trigger the breakpoint which is in a routine after joystick 1 button is pressed around a certain area, if I can’t see the game or move the players ? 

 

EDIT - I didn't have a display window. I found it under View / Display.  (!)  Now I think I'm in business. 

[matosimi]

5 minutes ago, Cafeman said:

If I hit run/break, it doesn’t return me to the game screen. I’m still looking at the console window, memory, and disassembly debugger windows. So how can I try to trigger the breakpoint which is in a routine after joystick 1 button is pressed around a certain area, if I can’t see the game or move the players ? 

It seems you may have your debug window(s) overlapping the main window, just blindly based on your replies. So I suppose you just have to rearrange them the way it suits you.

For instance this is MY favorite setup:

The easiest way to add breakpoint on instruction is to right click on the respective line in the Dissassembly window and selecting Toggle Breakpoint.

F8 is to resume the execution (until next breakpoint)

F10 step over (this one jumps over JSR subroutine so it is executed in 1 step like the macroinstruction)

F11 step into (this one jumps into subroutine)

 

If you need to control the game/app, you have to click (put focus) on the main window.

 

[+Cafeman]

@matosimi   Thanks. My problem was a simple one - I didn't have the display window 'turned on' for some reason.  I found it in the View Tab / Display . Now that I have a game screen, it all makes sense. Not sure why the display wasn't on by default, maybe I accidentally turned it off one day.