Using/Reading/Understanding Stella Debugger (Tips)

[KevKelley]

I am attempting to try and understand the Stella Debugger a bit more.  While I use the overlay on the play screen to observe if any scan line issues occur, I am trying to get a better understanding at what exactly I am looking at.  Before I would flip through the frames but I would usually just notice when the scan line occurs and see if I can make an educated guess as to what went wrong based on what was going on each time I saw the scanline counter turn red.

 

In this instance, I was playing around with Litterbug when I noticed later on in my testing that the scanlines jumped for a second.  I added a breakpoint in the debugger and from there I tried to narrow down why it happened.  

 

From what I noticed, the scanlines would jump to 263 and they only seemed to happen late in the game, when the fire button was pressed, and on a certain screen.

 

So what I was wondering was that should I be looking at more in the debugger?  I wanted to try to make sure I am using it correctly or effectively.  Am I missing something that would make debugging easier?  I look at the other parts of the debugger but to my untrained eye I feel like I am kind of just making guesses looking at all the blinking colors!

 

Here is a little video of me messing around with the debugger and game in question to get any hints/tips/tricks.

 

[Fort Apocalypse]

While I don't know how to use the Stella debugger, I notice the score is a little over 1000. Perhaps a change in the score caused a few more cycles than would've been best for proper display?

 

I'm not one to give advice since I keep flipping screens...

[Fort Apocalypse]

Maybe the bottom half is this part of includes/std_overscan.asm:

overscanloop
     lda INTIM ;wait for sync
     bmi overscanloop
doneoverscan

     ;do VSYNC

     ifconst interlaced
         CPX #4
         BNE oddframevsync
     endif

     lda #2
     sta WSYNC
     sta VSYNC
     STA WSYNC
     STA WSYNC
     lsr
     STA WSYNC

And the Lffdd I think may be a line you could see in your (basic filename).lst file if you search for ffdd.

So, it starts to wait for sync via lda INTIM (wait for sync), but it only does it once in the debug output. I assume maybe it immediately realizes it needs to sync, so it doesn't need to wait anymore, which maybe could possibly mean whatever is happening before the overscan is taking too many or just enough cycles, and based on what you're saying, maybe too many cycles by the time it hit the overscan just after line ffdd?

I don't know, though.

Edited June 15, 2022 by Fort Apocalypse

[KevKelley]

10 hours ago, Fort Apocalypse said:

While I don't know how to use the Stella debugger, I notice the score is a little over 1000. Perhaps a change in the score caused a few more cycles than would've been best for proper display?

 

I'm not one to give advice since I keep flipping screens...

I think I fixed the issue. I tried to check and see at the break what exactly was being done. Since it only occurred when the fire button was pressed I checked what code involved that. I had several "if joy0fire" lines but I also had a line that defined a bit if the button is pressed or not so I changed all the other lines to just check a bit and from what I can tell I hadn't had a scan line issue.

 

I was just kind of wondering tips or tricks in reading the debugger. I understand some of the information, but didn't know if I should be looking at more or if what I was looking at was kind of what to do.

[KevKelley]

3 minutes ago, Fort Apocalypse said:

Maybe the bottom half is this part of includes/std_overscan.asm:

overscanloop
     lda INTIM ;wait for sync
     bmi overscanloop
doneoverscan

     ;do VSYNC

     ifconst interlaced
         CPX #4
         BNE oddframevsync
     endif

     lda #2
     sta WSYNC
     sta VSYNC
     STA WSYNC
     STA WSYNC
     lsr
     STA WSYNC

And the Lffdd I think may be a line you could see in your (basic filename).lst file if you search for ffdd.

So, it starts to wait for sync, but since it doesn't show repetition, I assume maybe it immediately realizes it needs to sync, which would mean whatever is happening before the overscan is taking too many or just enough cycles, and based on what you're saying, maybe too many cycles by the time it hit ffdd?

I don't know, though.

Yeah. I still don't know assembly but I am trying to find of get a grasp on it or at least what to look for. 

[+SpiceWare]

Have you seen the Stella Debugger documentation page? I've run across a number of people who don't know it exists..

 

In this topic I show how to use the debugger to analyze VSYNC

 

@tschak909 posted a couple videos about using the debugger in this topic starting at reply 86, though the 2nd one is now private for some reason. I added some comments/clarifications about the debugger in reply 91. 

 

 

 

 

[Fort Apocalypse]

I think lda = load accumulator A. Basically just reading a value from something that follows it.

 

includes/vcs.h

has:
   

; RIOT MEMORY MAP

SWCHA       ds 1    ; $280      Port A data register for joysticks:
                    ;            Bits 4-7 for player 1.  Bits 0-3 for player 2.

SWACNT      ds 1    ; $281      Port A data direction register (DDR)
SWCHB       ds 1    ; $282        Port B data (console switches)
SWBCNT      ds 1    ; $283      Port B DDR
INTIM       ds 1    ; $284        Timer output

so:

lda INTIM

seems to be loading from the timer.

 

bmi = branch if minus. It is like a conditional "goto" that will goto the tag specified if the previous value it was fed was negative. I'm guessing the returned timer value is negative (or false?) when it needs to wait, and otherwise is positive, in which case it wouldn't branch (goto) and proceeds with the next lda and then the WSYNC.

 

sta - transfers a value from the accumulator into RAM.

 

back in includes/vcs.h it has:

VSYNC       ds 1    ; $00   0000 00x0   Vertical Sync Set-Clear
...
WSYNC        ds 1    ; $02   ---- ----   Wait for Horizontal Blank

As to why it waits for horizontal blank then does a vertical sync set-clear and then waits twice, idk.

[Fort Apocalypse]

Found this also: https://stella-emu.github.io/docs/debugger.html

 

Edit: Oops: sorry I got beat to it.

Edited June 15, 2022 by Fort Apocalypse

[+SpiceWare]

23 minutes ago, Fort Apocalypse said:

And the Lffdd I think may be a line you could see in your (basic filename).lst file if you search for ffdd.

 

Lffdd = auto-generated label for address $FFDD.

 

If Stella can't find a symbol file for the program you're debugging, it will auto-generate labels for addresses that are directly referenced by parts of the code.  You don't want any address to be hardcoded in case you save the disassembly and make changes to it, resulting in code and/or data shifting location in memory.

[KevKelley]

9 minutes ago, SpiceWare said:

Have you seen the Stella Debugger documentation page? I've run across a number of people who don't know it exists..

 

In this topic I show how to use the debugger to analyze VSYNC

 

@tschak909 posted a couple videos about using the debugger in this topic starting at reply 86, though the 2nd one is now private for some reason. I added some comments/clarifications about the debugger in reply 91. 

 

 

 

 

I'll have to watch/read more about it. I have read the documentation page with some understanding. I find myself looking at it more and more to try and learn and understand using it and since Litterbug was a kind of simple endeavor I thought it would be perfect to learn with. 

 

I kind of just look to see what happens when the break occurs and then I was going into the code to see what I was doing. Like in this instance it only happened later in the game and only when I pressed the fire button on a playfield pixel to be filled in. So I kind of went from there but was just curious if I am utilizing it correctly or if I should go deeper, like looking at the assembly and learning more of that. 

[alex_79]

15 minutes ago, SpiceWare said:

Have you seen the Stella Debugger documentation page? I've run across a number of people who don't know it exists..

Note that you can open the documentation from within the Stella Debugger itself, by pressing "F1". This will open the web browser, and will also position on the relevant section depending on what is currently selected (e.g. click on the TIA tab and then hit "F1")

[+SpiceWare]

6 minutes ago, alex_79 said:

Note that you can open the documentation from within the Stella Debugger itself, by pressing "F1".

 

Never knew that.

 

hmm, apparently doesn't work on Mac. The other Fn keys do work for changing TV type, difficulty switches, etc.

[alex_79]

It works here (linux). Maybe try resetting the input mappings? Sometimes I had to do that after updating Stella to a new version, as the mappings got corrupted.

[alex_79]

Nevermind: it's "Shift-Cmd + ?" for Mac!

https://stella-emu.github.io/docs/index.html#Hotkeys

Edited June 15, 2022 by alex_79

[+SpiceWare]

37 minutes ago, alex_79 said:

Nevermind: it's "Shift-Cmd + ?" for Mac!

https://stella-emu.github.io/docs/index.html#Hotkeys

 

Hmm, that just opens the Help menu:

 

 

If I type "debugger"

 

 

and click Stella Debugger it brings it up, but always to Features so it's not context sensitive.

 

[alex_79]

Maybe it's supposed to work differently on Mac (but I don't see this mentioned in the manual), else it's a bug.

Here is the default mapping on my linux PC:

 

[+Karl G]

It might be easier to give debugger advice if you asked specific questions as to what you are trying to do with it.

 

From a bB programmer perspective, the debugger is a bit more challenging because you are seeing the assembly language version of your program. A couple of quick things to get you started:

 

• If you want to know when a variable is read from or written to, you can enter "trap <varname>". This will cause the debugger to come up right after the variable read/write has occurred. Entering "trap <varname>" a second time will get rid of the trap.
  • Similarly, you can use "trapread <varname>" and "trapwrite <varname>" if you only want to catch when the variable is read from, or written to, respectively
• You can use "print *<varname>" to show the current value of a variable. The "*" before the variable name is needed here or else you will instead get the memory location of the variable instead of the contents.
• If you want the game to stop executing at a certain point in your code and bring up the debugger, you can use "break .<label_name>" with the name of any label you have in your game. Note that for labels in bB code (as opposed to something using inline assembly) you must precede the label name with a ".". Once you have reached that point in the code, you can examine the values of your variables with "print" above, etc. Typing "break .<label_name>" a second time will clear that breakpoint.

 

Let me know if you have any more questions on usage from a bB perspective.

[KevKelley]

Thanks! I will have to try doing this more! I guess my goal wasn't as specific but was trying to understand how to use the information in the debugger a little more so than what I was doing, which was essentially just using it until the game breaks and then seeing what happened preceding the event and then looking at the code. 

[ultima]

Hi I'm having a look at some debugger disassembly and have a question ...

 

here is the bB code:
   missile1x=0: missile1y=0: AUDV0=0: AUDV1=0: COLUBK=0
   pfscore1=%00000000
   pfscore2=%00000000
   score=000000
 player0:
 %00000000
end
 player1:
 %00000000
end

 

the current asm looks like this

lda #0

sta ram_83

sta ram_88

sta AUDV0

sta AUDV1

sta COLUBK

lda #0

sta ram_F2

lda #0

sta ram_F3

lda #0

sta ram_95

lda #0

sta ram_94

lda #0

sta ram_93

 

It seems wasteful to lda #0   6 times . So I wanted to remove the bB code and I wanted to change it to this:

 

 asm
 LDA #0
 STA ram_83
 STA ram_88
 STA AUDV0
 STA AUDV1
 STA COLUBK
 STA ram_F2
 STA ram_F3
 STA ram_95
 STA ram_94
 STA ram_93
end

 

But it seems I can't use the ram values as they show in disassembly am I missing something?

 

**edit seems this did the trick and also saved about 34 bytes it also produced the asm as I hoped for.

 asm
 LDA #0
 STA $83
 STA $88
 STA AUDV0
 STA AUDV1
 STA COLUBK
 STA $F2
 STA $F3
 STA $95
 STA $94
 STA $93
end
 

 

Edited June 22, 2022 by ultima