DOSBox debugger

[Qbix]

strip

[mbelgrano]

With windows 10 i receive impossible executed because SDL_net.dll is missing

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

[Qbix]

it is part of the normal dosbox 0.74 installation.

[VileRancour]

My attempt at compiling from latest SVN using MinGW/MSYS (Windows 7, PDCurses 3.4, --enable-debug=heavy) resulted in the same problem described in a previous post: the debugger window accepts typed input, but not extended keys (cursor control, scrolling, function keys). Nothing else seems to be amiss. Any ideas?

[ripsaw8080]

Based on the linked post, I wonder if changing both instances of "toupper(key)" to just "key" will make a difference. If so, it suggests that function is not working as expected, perhaps for some locale reason...

[VileRancour]

Based on the linked post, I wonder if changing both instances of "toupper(key)" to just "key" will make a difference. If so, it suggests that function is not working as expected, perhaps for some locale reason...

Thanks - that seems to have fixed things. Perhaps this newfangled 'MinGW Installation Manager' has somehow misconfigured the standard libraries.

[thbar]

Hi,

I'm a newcomer here but a long time DOSBox user, trying to use DOSBox to debug/disassemble a demo I wrote ~20 years ago.

What is the recommended way to use the DOSBox debugger on Mac?

Is compiling locally with the right switches the way to go (and will it work, at all?), or are there Mac-specific debugger build?

Thanks!

-- Thibaut

[Deadcode]

DOSBox's debugger was quite helpful in pinpointing and eliminating the logic differences between my Snipes port and the DOS original. However, I found a very annoying bug in it. If a breakpoint is hit, then I press F5 to resume execution and the same breakpoint was supposed to be hit again, it skips a hit and is only actually hit the next time after that. As a result, when I breakpointed the main game loop, it would only actually hit the breakpoint every second game frame. As a workaround for this I had to put two breakpoints in a row everywhere I would have just used one; then, both breakpoints would be hit, and never skipped.

I found the cause of this. The bug is fixed by completely disabling all use of "ignoreAddressOnce" in debug.cpp. Apparently this was added in svn r1075 with the log message "improved breakpoint handling in protected mode". I haven't done any testing to see if it was needed back then for general use, or just for protected mode, and if in the latest build it is still needed for protected mode, but the bug definitely needs fixing.

[wjp]

I ran into exactly the same breakpoint problem. The situation with ignoreAddressOnce was a bit more complicated with three similar ignore mechanisms (ignoreAddressOnce, ignoreOnce, skipFirstInstruction) interfering with each other, so I submitted a patch to rewrite most of that. Harekiet has now committed this as svn r3994. I hope this fixes it for you as well.

[tigrou]

Hi,
I am using a special version of DOSBOX which allow me to debug DOS executables using IDA (available here : https://github.com/wjp/idados).

I am trying to debug a game which throw me "CPU:Illegal/Unhandled opcode" errors at some point.
Is there a way to configure DOSBOX debugger to pause the debugged process once a unhandled opcode is found ?

[ripsaw8080]

A call to the INT 6 handler is generated for an invalid opcode exception, so set a breakpoint there. The BPINT command in the DOSBox debugger doesn't work for exceptions, so use INTHAND 6 to set the code window to the handler and then press F9 to set a breakpoint.

[tigrou]

Thanks a lot for your help. I have been able to set a breakpoint on the INT 6 handler.

Surprinzingly DOSBOX debugger crash before displaying game menu if I start the game (Alone In The Dark in this case) with "debug" command (so that it breaks on first instruction)
Starting the game with DOSBOX debugger (and using ALT + Pause to break later) works perfectly. Strange.

[ripsaw8080]

Alone In The Dark is not known to cause invalid opcode exceptions, so you may have a bad copy. For the crash when starting the game with the "debug" internal program, try a debug build made from current source, as there has been a recent fix for the issue.

[Daneel53]

Hello,

I order to improve the French translation of Daggerfall, I need to debug the program Fall.exe. Being launched through Dosbox, I was pleased to discover two days ago the debugging facility of Dosbox.

So I downloaded "dosbox-74-debug.exe", installed it in place of the standard Dosbox.exe and launched Daggerfall by the usual shortcut. Everything seems OK, the debug windows opens, information is displayed, Soundblaser IRQs scroll, Daggerfall runs in its window, but... it is not possible to interrupt the program !

I press on both Alt and Pause keys, but Daggerfall keeps on running. And if I go inside the Debug windows nothing appens if I hit Return (which is probably normal if Daggerfall keeps on running).

So, where am I wrong ?

I'm under Windows 10 64 bits and, being French, my keyboard is AZERTY (but Dosbox takes it as a QWERTY one, i cannot switch to french keyboard).

[Qbix]

do you happen to have a mapper file left over from 0.74 ?
If so remove it.

[Daneel53]

Thanks a lot for this very fast answer! I removed the file mapper.txt and now Alt+Pause stops the game. Now I have to test the debugger in order to fully understand how it works.

I know that what I want to do won't be easy, because I would like to trap the moment when the game reads a certain string of text and I saw above that this function doest not exists in your debugger.

Meanwhile, at least I would like to see where in memory the string is. You wrote that for that we have to use the dump memory function (MEMDUMP) and then look for the string with an external tool. OK, I will do that, but if you don't mind I have one small question : how to know the size of the memory used by the game, in order to dump all the content ?

[tigrou]

Hello. Is there a way to break the debugger when a game open a file ? When such thing happen, the debugger usually display "FILES:" in the console log.
I could set a breakpoint on INT 21H but then it will break on ANY dos interrupt. I want to only make this happen when AH= 0x3D (file open)

EDIT : got it, seems BPINT has a special second parameter for that.

[Mok]

Anyone can tell me why interrupt CDh is blocked in heavy debug mode? I was trying to run some old turbo basic game and noticed the weird message and instant quit after. Is it used for something in debug mode? From cpu/cpu.cpp

Code: Select all

   case 0xcd:
#if C_HEAVY_DEBUG
       LOG(LOG_CPU,LOG_ERROR)("Call to interrupt 0xCD this is BAD");
      DEBUG_HeavyWriteLogInstruction();
      E_Exit("Call to interrupt 0xCD this is BAD");
#endif
      break;
   case 0x03:

Edit: No replies, so checked the file history in svn and the original part was in the very first version of this file from 2002... only moved to debug and later to heavy debug. Seems like a cruft from early days of Dosbox. Will just patch it away locally, as it seems completely useless and only prevents some programs from running.

[delsk]

DosBox shows incorrect disassembly for

Code: Select all

0FB6DD movzx bx, ch

It shows

Code: Select all

movzx bx, bp

instead.

[ripsaw8080]

It appears you're using 0.74, and the issue with disassembling prefix 0x0F has been corrected in SVN.