Asmusr Posted October 20, 2015 Share Posted October 20, 2015 Has anyone thought of using some of the unused opcodes for debugger output instructions? For instance, you could have an instruction PRINT R0 that you insert in the program which would print the current value of R0 to the debugger's console. This would only work on a combination of an assembler and an emulator that understood the new instructions, of course. I assume a real TI would ignore illegal instructions if you left them in (wasting some clock cycles), but usually you would remove them first by setting a switch in the assembler. The instruction set could include instructions for printing registers/PC/ST/CPU/VDP/GROM memory, strings, VDP registers, statuses, etc. The point is that in many cases this would be faster and easier than traditional debugging using single stepping and breakpoints because the debugger output would be resistant to program changes that shifts the memory addresses around. Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 21, 2015 Share Posted October 21, 2015 It was done in Win994A - there's a set of opcodes that were repurposed. I've declined to do so in Classic99. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 21, 2015 Author Share Posted October 21, 2015 It was done in Win994A - there's a set of opcodes that were repurposed. I've declined to do so in Classic99. I think those were for implementing an imaginary improved machine with a stack pointer etc. I'm talking about instructions to assist in debugging with no side effect on the program. Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 21, 2015 Share Posted October 21, 2015 I've previously put the forward the idea of a HALT instruction that would stop the emulator and open the debugger, but it's not high on Tursi's list of priorities, which I can understand. I think I suggested other instructions, too (all related to debugging) but I can't remember them now! 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 21, 2015 Share Posted October 21, 2015 As for the MAME/MESS debugger, you can set breakpoints or watchpoints (monitoring access to memory locations), so I don't really miss such a command, actually. Also, a particular debugger command takes up memory space and thus shifts the next commands, so it may have some unwanted effect. 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted October 21, 2015 Share Posted October 21, 2015 (edited) ... you can set breakpoints or watchpoints (monitoring access to memory locations), so I don't really miss such a command, actually. Yes, that's right. I use breakpoint R12=BEEF all the time. LI R12,>BEEF is then inserted, moved around *), activated and deactivated (using a comment directive). *) As a consequence of altering other code, or of course by moving the instruction(s) (LI R12,>BEEF) itself. Edit: And if you accidentally leave the instruction(s) in a release, it won't do much harm. Well, all things being relative, I only use R12 for 9901, and set it prior to i/o. Edited October 21, 2015 by sometimes99er 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 21, 2015 Author Share Posted October 21, 2015 I've previously put the forward the idea of a HALT instruction that would stop the emulator and open the debugger, but it's not high on Tursi's list of priorities, which I can understand. I think I suggested other instructions, too (all related to debugging) but I can't remember them now! Cool idea. I think I will implement that in JS99er. 1 Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 21, 2015 Share Posted October 21, 2015 Back when I first starting messing with TI software again, I instrumented ti99sim with a 'debug print device'. Basically, I added a bunch of registers to the VDP to which I could send a printf style string and a bunch of variables. The emulator would then format and print that string to the console. Originally, I had the TI do the formatting, but that was just stupidly slow. Something like that would be great for those of us programming in higher level languages. Another thing I looked at but never got around to was adding support for resolving gcc symbols to js99er. When compiling a program with gcc, you can have it output a file that contains the memory locations of all symbols (variables, constants & functions). The idea would be that you could load this file and have a tab where you could monitor all variables in real time. I started doing this, but once you have things like structures and arrays in your programs it's not very straightforward to do the 'decoding' of memory contents. 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 22, 2015 Share Posted October 22, 2015 (edited) Cool idea. I think I will implement that in JS99er. Yeah. Once an op-code has been selected, it can be done with a data statement for assemblers that don't know about specific specialist debugging instructions. HALT EQU $9999 ... ... some code ... ... DATA HALT ... ... ... In Classic99 there is a "halt on undefined opcode" option, so one can just insert a nonsense op-code into the code and it has the same effect. Edited October 22, 2015 by Willsy Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.