Zach's Projects

I guess the answer is not as obvious as I was hoping. Anyway I was able to work around the problem by adding an extra line of code to the program that stores to RAM at the same time it stores to PF1. Then I just use this instruction:

 

breakif {*$f0 == $aa}

Sorry, can't help you here, as I never tried the debugger.

 

I assume

breakif { *$0E == $aa}

won't work either?

Your best bet would be to ask stephena.

Sorry, can't help you here, as I never tried the debugger.

 

I assume

breakif { *$0E == $aa}

won't work either?

Yeah, tried that.

Much of the debugger is either not implemented (yet) or broken. Just now I went through the docs a bit and a lot of the stuff in there doesn't actually work. Personally, I haven't found the breakpoints/traps/whathaveyou very helpful; might just be how I work though. Mostly if I'm looking for something in the debugger I try to pinpoint where something is going wrong and then go to that spot and then step through the code.

 

Kind of similar to using the z26 logfiles, except that I don't have to watch my computer almost meltdown trying to handle 10+ MB text files and you can see the entire contents of RAM.

In case anyone missed it, the "Stella debugger guy" responded to the problem.

 

A few comments about non-working items in the debugger.

 

1. As Zach noticed (see his bloggy), this conditional break doesn't work:

breakif *PF2==$00

 

The debugger sees what the CPU would see. Reading from PF2 doesn't return

the value you wrote to PF2 because PF2 is a write-only location... you'll

get whatever garbage value (AKA "bus noise") you'd get if your program

did "LDA $0F" (probably, you'll get $0F, since there's no TIA read-only

register at $0F).

So you wont be able to break according to the value of a write-only register. As I described earlier, you can get around this limitation by writing to RAM at the same time you write to the register.