Gazoo Posted February 8, 2015 Share Posted February 8, 2015 I posted this in a different thread, but no one responded, so I'll try it in a thread of it's own. Something that would be nice to have is some sort of tutorial on using a debugger. I've never been able to figure out how they work after numerous attempts over the years. I've always relied on seeing the results of the code I've written to determine where an error might be, then going back to look at the code where the program went astray and altering it until I got the results I was looking for. I know some of you guys here know how to use a debugger, so how about a tutorial? Gazoo Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted February 8, 2015 Share Posted February 8, 2015 (edited) Dunno if a general tutorial on a debugger would make a lot of sense. To use a debugger you have to get used to its actual implementation (e.g. using classic99's debugger or MG explorer). Nothing really magical about a debugger. Nonetheless all implementations basically concentrate on the below: Possible to single-step through code (=run a single instruction at a time) or run up to a previously set breakpoint Looking at (or changing) register values Looking at (or changing) memory locations The rest basically are just more advanced variants based on the above concepts: Break at a specific breakpoint only if a certain condition is met (e.g. register value equals XYZ) Watch variables Trace code as it runs Use of symbol table to see label/variable names instead of memory addresses Map source code lines to assembly instructions ... Probably forgot to mention some stuff, but I'm sure others will chime in EDIT: Having said all the above, I really appreciate classic99's debugger, it's a lifesaver! I would not have been able to write/debug my assembly code without it. So thank you Tursi Edited February 8, 2015 by retroclouds 2 Quote Link to comment Share on other sites More sharing options...
Willsy Posted February 8, 2015 Share Posted February 8, 2015 Indeed. TurboForth would not have been written without it! Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted February 8, 2015 Share Posted February 8, 2015 Unless of course you mean how to use a debugger on real hardware Don't know if anybody these days does that, but I still do on occasion, primarily for hardware projects where the code cannot be tested under emulation. My favorite remains Super Bug II. User friendly it is not, but it does work quite well once you get used to its commands. I could create a short YouTube video on it if there is a demand. Quote Link to comment Share on other sites More sharing options...
Gazoo Posted February 8, 2015 Author Share Posted February 8, 2015 Unless of course you mean how to use a debugger on real hardware Don't know if anybody these days does that, but I still do on occasion, primarily for hardware projects where the code cannot be tested under emulation. My favorite remains Super Bug II. User friendly it is not, but it does work quite well once you get used to its commands. I could create a short YouTube video on it if there is a demand. Any sort of help would be appreciated. Classic99 or MESS implementation would be fine. About the only thing I've managed to figure out is how to get a memory dump in Classic99, which isn't always a whole lot of help. Thanks, Gazoo Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 8, 2015 Share Posted February 8, 2015 The most important thing to know about the Classic99 debugger is that you must activate Scroll Lock on you keyboard before any breakpoints will work. 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted February 8, 2015 Share Posted February 8, 2015 The most important thing to know about the Classic99 debugger is that you must activate Scroll Lock on you keyboard before any breakpoints will work. Ohhhhhh.... Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted February 8, 2015 Share Posted February 8, 2015 The most important thing to know about the Classic99 debugger is that you must activate Scroll Lock on you keyboard before any breakpoints will work. Yeah, why is that? Somehow I always need a bit to recall that. Especially if I haven't used the Debugger for a while :-) Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted February 9, 2015 Share Posted February 9, 2015 Indeed. TurboForth would not have been written without it! Same here with fbForth 1.0 and 2.0—especially, 2.0. The mapping to ALC (“disasm” mode) was particularly helpful for probing the parts written in ALC. Troubleshooting high-level Forth has another layer of difficulty with the Forth address interpreter thrown into the mix; but, the Classic99 debugger was still invaluable—just a slower process than with pure ALC. ...lee Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 9, 2015 Share Posted February 9, 2015 Yeah, why is that? Somehow I always need a bit to recall that. Especially if I haven't used the Debugger for a while :-) Legacy code, originally scroll lock enabled/disabled debug functionality, before the debug dialog was well-formed. I liked the behavior so I kept it. (It also changes the FCTN keys from ALT+number to emulator/debugger commands.) I talked about changing it at some point to using the presence of the debug dialog instead, but never did it. Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 9, 2015 Share Posted February 9, 2015 Gazoo, while it's not a debugger tutorial per sae, if you browse my Youtube page there are a couple of relevant videos - one showing how to use the debugger to hack Alpiner, and another just showing Classic99 tricks in general (read the description and you can skip to the debugger parts). Maybe that will help. https://www.youtube.com/user/tursilion/videos?sort=dd&view=0&shelf_id=2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted February 9, 2015 Share Posted February 9, 2015 Legacy code, originally scroll lock enabled/disabled debug functionality, before the debug dialog was well-formed. I liked the behavior so I kept it. (It also changes the FCTN keys from ALT+number to emulator/debugger commands.) I talked about changing it at some point to using the presence of the debug dialog instead, but never did it. Actually, I see the utility of it. While I was debugging my sound test cartridge I needed to debug the sound player and sprite motion which are both IRQ-based. (Is that a proper term in 9900-land?) Anyway, having a breaking point in the ISR meant the program stopped every interrupt which was way too often for what I was trying to watch. Being able to turn break-points on and off at whim is very useful, especially with a single keystroke. 1 Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 16, 2015 Share Posted February 16, 2015 Is there a way to see the VDP ram and registers in M.E.S.S. in addition to the CPU?I read something about that in the release notes. I also highly vote for debugging tutorials. Will come up with something if nobody wants to start off. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 16, 2015 Share Posted February 16, 2015 (edited) Hi Klaus, You can see VDP RAM when you open a memory viewer window (Ctrl-m) and select the video memory in the drop-down list. BTW, I'm currently on vacation in Austria (Bad Hofgastein), that is, I'm away from my PC, so I cannot be more precise. Edited February 16, 2015 by mizapf 1 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.