Since I've been using DOSBox for development a lot lately , I've created an updated patch that adds a few more debugger commands and some fixes.

• The Debugger window can no longer be resized on Windows 10, which would mess up the formatting. The window can no longer be maximized either since it's a static size.
• When closing the debugger, DOSBox will exit with a status code 0, which works better if run from a batch file.
• New debugger commands:
  • DA: Will disassemble n bytes from segment:offset to a text file (defaulting to DISASM.TXT)
  • BPSAVE: Will save the current breakpoint list to BPLIST.TXT
  • EXEC: Will execute debugger commands from the specified file (comments can be made using a semicolon ";")
• An autoexec file can be specified with autoexec= in the debug section of dosbox.conf. Just like the command file above, comments can be made using a semicolon.

The attached dosbox.exe is built against SVN 4454.

Just an idea I had - for capturing interrupt 31h (simulate real-mode breakpoint), it would be useful to extend BPINT to trigger not only on AH/AL but also on BL - since this is where the real-mode interrupt number is stored, when 31h is called.

I'm looking for a forum for DosBox-X debugging. Is this an appropriate forum for this topic?

I am having issues with DB-X 0.84.0 crashing when ever I start the debugger. When I start an app with

> debug myapp.exe
- g

And press ALT-Pause DB-X immediately crashes.

I am using the Ubuntu 20.04 flatpak version and I have started DB-X from a terminal window.

I did manage to make it work once but have no idea what I did differently on that occasion. On that occasion it worked very well.

Is there anyone familiar with DB-X debugging that has any insight?

EDIT:

I think I just answered my own question. In the configuration editor I changed the CPU core option from Auto to Normal and the debugger in now working!

siddhartha wrote on 2021-05-11, 17:39:

Since I've been using DOSBox for development a lot lately , I've created an updated patch that adds a few more debugger commands […]
Show full quote

Since I've been using DOSBox for development a lot lately , I've created an updated patch that adds a few more debugger commands and some fixes.

• The Debugger window can no longer be resized on Windows 10, which would mess up the formatting. The window can no longer be maximized either since it's a static size.
• When closing the debugger, DOSBox will exit with a status code 0, which works better if run from a batch file.
• New debugger commands:
  • DA: Will disassemble n bytes from segment:offset to a text file (defaulting to DISASM.TXT)
  • BPSAVE: Will save the current breakpoint list to BPLIST.TXT
  • EXEC: Will execute debugger commands from the specified file (comments can be made using a semicolon ";")
• An autoexec file can be specified with autoexec= in the debug section of dosbox.conf. Just like the command file above, comments can be made using a semicolon.

The attached dosbox.exe is built against SVN 4454.

So, thanks to this patch, I was able to set up a mostly working toolchain where breakpoints I set in Visual Studio Code get sent over to DOSBOX for stepping though. At least for some assembly stuff I'm doing. Takes the dbg files out of NASM, the map file out of ALINK, the line numbers of breakpoints in Visual Studio Code, filters them all through a pretty hacky javascript app, and so long as the breakpoint is at a label, tells DOSBOX to break there.

It's pretty janky, but it mostly works. The solution I cooked up is pretty specific to my toolchain, but I don't mind sharing it if anyone thinks it'd be useful.

I did code and debug all Mod Master XT using DOSBOX and none of these debug feature.
A shame it was not better documented....
i still code the PicoMEM BIOS using TD, not dosbox debug.

Qbix wrote on 2004-12-04, 09:07:

if you have experience with debugging you can try the DOSBox debugger It can be downloaded from: DOSBox debugger EXE 0.74-3 DOSB […]
Show full quote

if you have experience with debugging you can try the DOSBox debugger
It can be downloaded from:
DOSBox debugger EXE 0.74-3
DOSBox debugger EXE 0.74-2
DOSBox debugger EXE 0.74
For information on how to use it:
Guide to debugger

I have a question about DOSBox Debugger. How do I make it respond to INT3 (machine instruction 0xCC) or INT 3 (machine instruction 0xCD,0x03)? I want to use INT3 as breakpoints in my code to guaranty that the debugger will stop in the piece of code that I need to stop it in to debug that piece of code. I seem to have two choices right now, due to the debugger's seeming inability to respond to INT3 or INT 3. I can either go into my code in the debugger, push the down arrow until I'm at the piece of code I want, and then press F9 to set a break point (and then press F5 to run to the breakpoint), or keep pressing F11 quickly to execute the code one instruction at a time until I'm at the piece of code I want to debug, and debug it from there. There's one problem. I get lost in the code so easily when I don't have labels in the code like I do in the assembly source code. One piece of code looks like any other piece in the debugger, so it's very easy for me to accidentally go past the point in the code I want to debug by pressing F11 too many times, or by accidentally setting a break point in the wrong location.

The solution is to allow INT3 or INT 3 break points to cause the debugger's execution of the code to stop. That way I can set a break point in my assembly source code with INT3 or INT 3, and be certain that DOSBox Debugger will stop at that piece of code for further debugging. So please enable INT3 and INT 3 break points in your next release of DOSBox Debugger. If this is already possible and I'm just unaware of it, please tell me how to enable this feature. Is this behavior configurable in the DOSBox.conf file for the debugger?

videogamer555 wrote on 2023-02-21, 05:03:

The solution is to allow INT3 or INT 3 break points to cause the debugger's execution of the code to stop.

INT 3 only causes the debugger to halt execution because debuggers hook that interrupt, and put INT 3 in the code when you set a breakpoint. DOSBox debugger is not a traditional debugger however, it doesn't run in the same environment as the code, it's more like a hypervisor. So when you put a breakpoint in the code, DOSBox debugger does not use INT 3 to make the code halt at that location. Also, even with traditional debuggers that actually run alongside the code, putting INT 3 in your code is not guaranteed to work, as the debugger will expect the INT 3 is put there by itself, and if its not, will probably ignore it.

Unfortunately, it's along time ago I used the DOSBox debugger (I've always found it extremely cumbersome), so I can't advise you on how to do what you want.

Maybe BPINT can be used.

jal wrote on 2023-02-27, 10:25:

Also, even with traditional debuggers that actually run alongside the code, putting INT 3 in your code is not guaranteed to work, as the debugger will expect the INT 3 is put there by itself, and if its not, will probably ignore it.

I think I used to insert INT 3 or INT3 instructions into programs I debugged with Turbo Debugger and I don't think it ignored them. Or perhaps you could say it did ignore them because it just executed its interrupt handler like normal and returned control to the debugger, whereas if it had resumed executing my program, that would have meant that it made an explicit choice to do so.

I could certainly be remembering incorrectly though, and it doesn't really change the fact that DOSBox is in a different position as you say.

Still, it would be nice if one could optionally ask DOSBox to break on INT 3/INT3. As a workaround, I suppose one could edit memory to put an IRET instruction or something (I forget what you need to put at the end of an interrupt handler) somewhere, point the interrupt 3 vector at that instruction, and then set a DOSBox breakpoint on the instruction?

How to find data reading code with the dosbox debugger?

i've got a 16bit real mode DOS game that loads some level data always at the same position (4A9B:4CC) and i try to find out what part of the code is using the data to decompress

im building dosbox from source with heavy-debug mode and im able to log access to this memory area in the dosbox source code by adding some address compare code the the host_readb function
i though printing SegValue(cs):ip at read will get me to the using code but using breakpoints on these printed cs:ip combinations don't get triggered or showing the disassembly at these positions with 'c' don't show sensfull code

any tips how i can find out what part of the code reads the data on a never changing position? or any tool that i can use inside dosbox or maybe a real DOS?

Maybe someone will have some tips about how to achieve that with the DOSBox debugger, but another alternative might be to try running DOS under Bochs, then use Bochs's debugger which has read and write watch points - from https://bochs.sourceforge.io/cgi-bin/topper.p … user/index.html:

8.1.3. Memory WatchPoints […]
Show full quote

8.1.3. Memory WatchPoints

watch read addr Insert a read watch point at physical address addr
watch r addr Insert a read watch point at physical address addr

watch write addr Insert a write watch point at physical address addr
watch w addr Insert a write watch point at physical address addr
...
watch stop Stop simulation when a watchpoint is encountered (default)
watch continue Do not stop simulation when a watchpoint is encountered

thanks for the bochs link

im currently get it more or less working with dosbox source changes - needed to use the different load segments for with/without dosbox debugger

llm wrote on 2023-03-15, 12:20:

needed to use the different load segments for with/without dosbox debugger

The debugger causes changes to the memory layout for the programs running inside the emulated environment? If so that seems a bit wrong, and also something that would unfortunately be useful to someone wanted to write a copy protection scheme or something that prevented someone using the debugger.

doshea wrote on 2023-03-16, 07:45:

The debugger causes changes to the memory layout for the programs running inside the emulated environment?

Only when the DEBUG.COM launcher on the Z: drive is used, because it is a parent process that allocates memory blocks ahead of the launched child process. You can start debugging at the entry point of a program run directly at the prompt by using BPINT 21 to break on the INT 21/4B function that executes programs as an alternative to using the launcher, and that way there is no change in how memory is allocated.

Great, thanks, that makes sense!

Hi,
Just a simple question:
Is there a way to display FPU stack registers during a debug session?

Just wanted to drop a quick thank you for the precompiled debug versions, along with a nice debugger. Perhaps more notes on how to build from source would be great, like which versions of SDL you're using, what version of VS, etc. Again, much appreciated.

Hi,

I want to debug an old DOS BIOS and I wanted to know how can I do that from DosBox. Is there a way to load my own BIOS and have DosBox debugging it step by step?

Thanks!

pablofg wrote on 2023-03-26, 19:33:

Is there a way to load my own BIOS

I'm pretty sure the answer to that question is no. From a quick search online, it sounds like dosbox-x might support that. My vague understanding however is that a motherboard BIOS is often very dependent on the hardware in a way that most normal software isn't, probably because it can be - it comes with the motherboard so they can just update it if they update an I/O chip on the board, rather than needing to make it handle a range of chips - so you probably need to find an emulator which emulates something close to the hardware that your BIOS is designed for. Emulators like PCem, 86Box and MAME seem to have some level of emulation for lots of different hardware devices, but I don't know what their debuggers are like.

DOSBox emulates only the hardware that games use directly, otherwise it emulates at the BIOS level, so I guess you could say it's partly a high-level emulation. In any case, a real PC BIOS needs pretty much all of the hardware to be emulated, so loading one in DOSBox won't really work.