Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: SirCmpwn on September 18, 2010, 06:47:18 pm
-
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 :P). 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
-
Sounds cool ^^ Can't wait to try it, although I might not use it regularly
-
Yeah, the whole interrupt thing is a bit of a downer, but I will probably make it so you can manually call all the features without using the interrupt.
-
What specifically will the code view look like?
-
It will basically show the program code, uneditable, and will figure out the currently executing line, take you there, and let you browse the code, check variables, etc.
-
cool project Sir! Altough I hope you don't overwork yourself with all this projects running in parallel, I have the same 'problem'.
-
:O That sounds awesome! I thought it would just indent the code of a certain program :P Can't wait to see your elegent solution to finding where in the code you are
-
Well, its mostly because it would be useful for my current projects :)
player, code counting.
-
That sounds awesome! So basically you would just include the file at the beginning of your program and it gets debugging capabilities? Sounds awesome :D Although how are you going to manage it without Interrupt capabilities?
-
That's right, all you do is include it. Also, without the interrupt turned on, you can always do sub(BP) (BP = Breakpoint) to manually break the code.
-
How on earth are you going to manage to figure out where execution is?
-
Pop hl \ push hl :)
-
Wait, wait, wait....how can you see the file's code after it's compiled? I'm confused! will this compile the code itself?
-
Well, I might have you browse to the source code, or look for a program with .NAME at the header, where NAME is the name of the executing program.
-
Pop hl \ push hl :)
Okay, and how does doing that do anything? Like what is the specific mechanism for finding where in the code you are?
-
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.
-
Yeah thats the real question i have
-
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.
-
This sounds neat! Good luck Sir. :)
-
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 :P). 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?
-
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.
Well the really hard things would be like things like this line:
5/4+(4-B)*2^16 And (7*(9+B)->B)->C+5->B
Things like 5/4, *2, ^16, and others are automatically optimized, so it might be uber hard to anticipate the compile size. Not to mention as Axe parser evolves and changes, optimizations will change and your program will be out of date.
-
This sound awesome! Good luck, Sir, but remember someone could have deleted the source :P
-
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.
Deep Thought, if the source code is gone, code view is disabled.
-
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...
-
Can you describe the Instant Break thing again?
EDIT: A few tweaks and this could be used for a pure ASM debugger...
I thought the same thing :)
-
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 (http://www.detachedsolutions.com/mirageos/manual/hkeyopts.php).
EDIT: I can see the potential of this as an ASM debugger: basically, Calcsys in-prgm :D
-
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.
Deep Thought, if the source code is gone, code view is disabled.
Scrolling by label would be nice. Might make it much easier to go to parts of code in particular.
Maybe a search function too? On Casio calcs, in the on-calc BASIC editor it's possible to search for stuff in the code.
-
Deep Thought, that's more or less the idea - calcsys in-program. DJ, search could be easily implemented.
-
If it's reasonable, maybe have the program keep a list of the labels used in the program, then allow the user to select one to jump to?
-
This sounds like a really cool project. Good luck on it :)
-
If it's reasonable, maybe have the program keep a list of the labels used in the program, then allow the user to select one to jump to?
If you look above, you will notice that is exactly what I'm doing.
-
Maybe you could request that Quigibo add a feature to Axe that allows dumping of debug info (like, a list of executable addresses corresponding to the start of each line of source code)
-
Perhaps... or maybe a hook system?
-
A hook system might be cool for those who develop developer tools. I am not sure what would be Quigibo stance on this since Axe is supposed to be game-oriented, though. Maybe he will wait for Axe 2.0 or something.
-
If you look above, you will notice that is exactly what I'm doing.
Oh, sorry. I thought it only allowed jumping by labels (i.e. it would look for the next label when you tell it to jump).