It will certainly return where in the executable it was called from, whether it's an interrupt or a normal call. But as to how you will match the executable to the source code, I have no idea.

Well, it would return the currently executing address.  Perhaps Quigibo could shed some light on this, but I believe that each command really calls a subroutine in the code, and has a certain length, and I could interpret the code for size until I reached the currently executing line.

Hello,
I'm working on a debugging library that will make it much easier to debug Axe code.  It works as an interrupt, and when you hold down Y= and Graph, it will break (which means that it will stop executing your program and temporarily execute its own code instead, not that it crashes your calc ).  You can browse a menu of available options and things to do while you are in the breakpoint.  So far, the following is implemented:
-Logging
   -You can maintain a log that saves to a program file, and view it from the debugger or from TIOS
-Variable Editing
   -While debugging, you can break and view/edit the variables
-Hex Editor
   -You can view RAM and ROM, and modify RAM
Planned:
-Code View
   -An interactive view that will let you navigate the code and do some sweet stuff, like Visual Studio

Wow that's great. It reminds me a bit the RPG Maker 2003 debug mode. No more need to manually add Text(0,0,varname):Pause 3000 in our programs to check a variable value, rigth?

Wouldn't viewing code be hard to implement, though? I mean, how would you convert binary back to Axe code?

This sound awesome! Good luck, Sir, but remember someone could have deleted the source

Yeah, I'm having second thoughts about finding the current code, but I may make it easier on the programmer to browse their source, like having them scroll by label.

And two parts of the code could very well say the same thing (despite subroutines being available). Scrolling by label is a good idea.

Also, one thing that would be really useful: something like Mirage's Instant Break, where it resets the stack to its original condition, then breaks. That way, if you suddenly find a freeze point, you can at least get out of it.

EDIT: A few tweaks and this could be used for a pure ASM debugger...

I meant the ON+CLEAR/ON+MODE interrupts when you run a prgm from Mirage. Mirage calls them Interrupt Taskers: http://www.detachedsolutions.com/mirageos/manual/hkeyopts.php.

EDIT: I can see the potential of this as an ASM debugger: basically, Calcsys in-prgm

Deep Thought, that's more or less the idea - calcsys in-program.  DJ, search could be easily implemented.

This sounds like a really cool project. Good luck on it