+Stephen Posted December 6, 2021 Share Posted December 6, 2021 I've finally started a VBXE project in straight ASM. I am using MADS via Eclipse + WUDSN. I'm having two problems preventing me from debugging. I am emulating my 1088XLD machine. It is using U1MB for SDX and CF card access. Because of this, I can't drop an XEX file on the emulator, it won't load. So I had been using a mounted ATR file and using the disk explorer to put my xex file. The problem is, this does not allow me to debug. So the 2nd thing I tried was not using the profile with SDX. This allows me to launch the emulator (single instance) and pass the .lab and .lst files. Voila - debugging works. But my code does not because I need a DOS present to use the Load macro. Summary of what I need is: Emulator with Sparta DOS X loaded (can't figure out why yet, but the example code I started with does not work under MyDos, but I want this as an SDX app anyhow) Ability to drop the xex with .lab and .lst files so I can debug (file is not loading data into VBXE RAM) I hope this makes sense - I can post videos or my source code if additional info is needed. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 6, 2021 Share Posted December 6, 2021 Perhaps this illustrates why I open the LST file in Notepad and just run everything (via a virtual folder on D2:) as if launching it on real hardware, before breaking into the debugger or hitting previously set breakpoints. If there's a better way, I'd like to hear about it as well. Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted December 6, 2021 Share Posted December 6, 2021 33 minutes ago, Stephen said: Ability to drop the xex with .lab and .lst files so I can debug If the debugger is open when you do this, those should be loaded. Otherwise, maybe play with the settings here: Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 6, 2021 Author Share Posted December 6, 2021 37 minutes ago, flashjazzcat said: Perhaps this illustrates why I open the LST file in Notepad and just run everything (via a virtual folder on D2:) as if launching it on real hardware, before breaking into the debugger or hitting previously set breakpoints. If there's a better way, I'd like to hear about it as well. Can you get virtual folders working with SDX? That's my biggest issue here. From within SDX, I cannot see what would be a virtual folder when I run APE. I need the working folder on my PC to be seen simply as drive 2 under SDX. Maybe if that works, then simply loading the xex file will let the source level breakpoints to fire. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 6, 2021 Share Posted December 6, 2021 (edited) 7 minutes ago, Stephen said: Can you get virtual folders working with SDX? Yeah - no problem at all: I just clicked on the right arrow for that slot, and in the fly-out menu, selected 'Mount folder as virtual DOS 2 disk'. It's read only, but it shows up as drive B: in SDX just like the same folder simultaneously appears as B: on a real machine at the other end of RespeQt/SIO2PC. This way, I run the same XEX hot off the assembler in the same way on the emulated machine and the real machine. Because 100 per cent of the things I work on tend to require some manual launching in the emulator, I don't start instances of the emulator automatically from WUDSN. It's not the most efficient method, but it works. Edited December 6, 2021 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 6, 2021 Author Share Posted December 6, 2021 OK - I've got the virtual folder working, thanks, this will be a HUGE time saver. However, I still cannot get source level debugging to work any other way than dropping the XEX on the emulator. This does not work when I am setup running SDX. I guess I will need to manually set breakpoints in the Altirra debugger? Not what I am looking for, but better than nothing if it has to be done this way. Quote Link to comment Share on other sites More sharing options...
phaeron Posted December 7, 2021 Share Posted December 7, 2021 7 hours ago, Stephen said: OK - I've got the virtual folder working, thanks, this will be a HUGE time saver. However, I still cannot get source level debugging to work any other way than dropping the XEX on the emulator. This does not work when I am setup running SDX. I guess I will need to manually set breakpoints in the Altirra debugger? Not what I am looking for, but better than nothing if it has to be done this way. You will want to use a SpartaDOS virtual mount under SDX. It's more flexible than the DOS 2 mount and in some cases much faster, due to SDX being slow at reading executables off of DOS 2 formatted disks. The main problem here is the emulator not having visibility to program loads. If you are loading an actual SpartaDOS executable then you are mostly out of luck, as neither the assemblers nor the SpartaDOS runtime expose enough info about relocation for the debugger to match symbols. But if you are using standard DOS 2 executables, there are more options. The first thing you can do is manually load symbols using the .loadsym command -- either specifying a path, or just using ? to bring up the file dialog. From there you can select the .lab and .lst files. The .reload command tells the debugger to reload the symbol files. .unloadsym unloads previously loaded symbols. The second method you can use is to trigger the executable load from the emulator after SpartaDOS has booted. To do this, change the program load mode in Configure System > Boot to Deferred, uncheck the Unload on boot image checkboxes, then use the attached program to trigger the program load. It's an updated version of the utility on the Additions disk, which had gotten out of sync (it wasn't updated for an SIO ID change that I made for the 65C816 OS). This works by issuing an SIO call to device $7D to tell the emulator that it's time to trigger the executable load. loadexe.xex 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 7, 2021 Author Share Posted December 7, 2021 Thanks for all the help everyone. I was able to get things working enough to diagnose a "CIOV Error 150" by stepping through code and viewing memory. For some odd reason, the string being pointed to by ICBAL, ICBAH was not terminating properly causing the Path not found error. The example I started with did not have anything after the string declaration but I found adding anything afterwards in my code fixed the issue. Simple for many I am sure - but have to start somewhere Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 7, 2021 Author Share Posted December 7, 2021 More progress. Figured out how to load data into VBXE RAM. If I gain traction with this, I'll move my post to the blog section. Again - thanks for all the suggestions / help. 4 Quote Link to comment Share on other sites More sharing options...
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.