kl99 Posted February 13, 2013 Share Posted February 13, 2013 Hi! What are the debugging features on the different emulators? Would you be interested in Basic programming optimized debugging features like: Extra window with Program listing of your Basic/XB program, syntax highlighted Current Instruction being executed is highlighted in the program listing Infos about how much Stack space is free, how much program space is free, how much your program occupies,... How many numeric variables, string variables, arrays are currently defined, how much memory each one occupies, value of each variable, location of variable in memory... You could even try to check the code syntax and highlight syntax errors, many things are possible. It would be an interesting challenge to see if I can add this stuff to one of the emulators for personal use, a public release would require the emulator author's permission of course. Is one emulator currently supporting such things? Klaus Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 13, 2013 Share Posted February 13, 2013 (edited) As for MESS, no, and I dare to say that it is not feasible for MESS. The problem is that Extended Basic is just a program that is executed on the platform. In the same way that the TMS9900 CPU has no idea what it is currently processing, the MESS core neither has. What you are thinking of is a view from outside, given the knowledge about the structure of data in Extended Basic. For MESS, Extended Basic or any other cartridge or program appearance is based on the fact that the ROM is present. When you unplug the emulated cartridge, nothing inside refers to Extended Basic anymore (ok, except for the cartridge board implementation). I certainly agree that such things could be quite useful, but this goes more to the direction of Extended Basic simulation (yes, we had the discussion on the Yahoo list recently about emulation/simulation). Michael P.S.: What you can do, indeed, is to follow the activities of the CPU in the debugger, and to inspect the memory, including video memory. Edited February 13, 2013 by mizapf Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted February 13, 2013 Share Posted February 13, 2013 (edited) I would already be very happy if we'd have a symbolic debugger. With V9t9, classic99 and MESS still being in development it would be cool if some kind of "standard" could be defined. You know, a standard format for a symbol table, standard way to set break-points, single-step, watch memory, etc. and all this via an API. That way a stand-alone debugger could be developed that works with all mentioned emulators. Edited February 13, 2013 by retroclouds Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 13, 2013 Share Posted February 13, 2013 (edited) OK, there's one way that seems feasible. If we had an external debugging access to the emulators, we could read the values from the memory via this external access. This would be a completely external solution, in the sense that the emulator cannot say anything to the meaning of the bytes, but the external tool must have the capability to interpret them. For example, if we know that the symbol table pointer is at 83xx, then the external tool would have to read that value from there, and then it would download the video RAM contents. This could be a function dump_contents(memory_identifier, start_address, length). Also, we could set breakpoints from outside. What we could not do is to ask the emulator to "dump the symbol table" because the emulator does not know anything about such a thing. It would be completely up to the external tool to interpret that. Such an external access would, in my view, have to be implemented as a socket to be as platform-independent as possible. Then, the external tool would open a socket connection and communicate as some kind of remote control. We would not even need a common command vocabulary for the debuggers if we had such a socket connection. It would be possible to write some kind of v9t9_adapter, classis99_adapter, mess_adapter as modules within that external tool. Michael Edited February 13, 2013 by mizapf Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 13, 2013 Share Posted February 13, 2013 Thierry Nouspikel (as always!) has created an external debugger that runs on hardware, and I installed hooks for Classic99 as well. Bug99 -- http://nouspikel.group.shef.ac.uk//ti99/bug99.htm It's a pretty nice little package. I've been looking at a GDB stub for Classic99 now that we have GCC working. No promises, but I did something similar recently on the Jaguar, and not that much code is required on the target side. Not sure how much is needed on the GDB side yet. Quote Link to comment Share on other sites More sharing options...
Willsy Posted February 14, 2013 Share Posted February 14, 2013 I would already be very happy if we'd have a symbolic debugger. With V9t9, classic99 and MESS still being in development it would be cool if some kind of "standard" could be defined. You know, a standard format for a symbol table, standard way to set break-points, single-step, watch memory, etc. and all this via an API. That way a stand-alone debugger could be developed that works with all mentioned emulators. Check out Fred Kall's TI994W - it has a symbolic debugger. It comes pre-loaded with some system address symbols, but you can also add your own IIRC - it's been a while since I used it. The debugger in TI994W is more like a machine code monitor; it has a command line that you can type commands/instructions on. Type ? for help (IIRC!) 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.