here it is http://dosbox.linuxsecured.net/dosbox73debug.exe

Thanks Qbix.

Thank you!

I'm having problems with the Debugger 😒

There are two problems, which seem very much related.

Firstly, a lot of breakpoints are being "missed". As in, the code executes but DosBox does not catch this happening, and the BP fails to trigger. BPINT always seems to work, it's BP CS:EIP type breakpoints that fail.

Second, the output of LOG/LOGS/LOGL is missing a lot of commands. Ie it will show the command executed at, say 015A, then the next command will be at 0194, missing everything in between. There was no jump, this is a linear sequence of ops, just with many of them missing.

It almost seems like a threading issue... like DOSBox is monitoring one DOSBox thread, but failing to pick up instructions being executed in a different thread. Anyway, that's just a guess, and probably completely wrong...

Either way, I'd like to be able to catch all BPs and see all commands in the LOGCPU.TXT file, if possible.

Cheers!

use core=normal when debugging

Thanks mate, that fixed both issues =)

Hi Qbix,

Qbix wrote:

hehe. I'll compile one day. 😀 creating that installer is most of the work though 😀

What software are you using to generate the installer? It should be possible to make the installer generation a simple 'make' target, .bat file or something like that, assuming a suitable installer generator is used. I have used NSIS for this kind of thing before.

Regards,
David

Qbix wrote:

here it is http://dosbox.linuxsecured.net/dosbox73debug.exe

I can't use the BPM command in this version. Is it removed in DOSBox 0.73 or isn't this the heavydebug version?
Anyway, I want to use memory breakpoints that activate when the value of a memory location is changed, without having to compile DOSBox myself 😀.

What do you type and what is reported in the debug window?

First, I type "?" to get a list of available commands. "BPM" is not in that list.
Then I type "bpm 1234:5678" and press Enter. All that happens is that "bpm 1234:5678" is changed into "BPM 1234:5678".

hmm then I must have made a typo while configuring the debugger enabled build.

it should be fixed now. Redownload it please

Hi, I am trying to use the dosbox debugger to have a bit poke around in an old game. I'm using the latest version posted in this thread. Two problems are occuring.

1) Memory breakpoints (linear - BPLM) seemed to not be working and after a while I realised that the breakpoints were being set 0x14 bytes before the address specified (and before the address shown in the data view and in output of MEMBUMPBIN). So to get them to work I need to type eg. BPLM CAFEBABE+14.

2) As you scroll up and down the code, the disassembly keeps changing. It's like the disassembler keeps changing it's mind about the alignment of instructions - if thats the right word. It makes no sense at all with core set to auto (presumably using the dynamic cpu) so I changed to normal as mentioned earlier in this thread. That made it much better and it seems to work properly if you just step through after hitting a bp. But I want to scroll up and look at the few instructions before the bp, and it gets messed up. 😠

The target is running in 32-bit protected mode (DOS/4GW). Don't know if that's relevant to the BPLM problem. Haven't tried it in any other modes.
Running debug version of dosbox-0.73 on WinXP SP2.

Cheers 😀

Hi, I download and tried the last debug version 0.73
While working with the debugger I got the impression only data changes are noted by the memory breakpoint. So it will not even note a writing of the same data as the one thats already stored on this memory location, right?

correct

Hmm, any hint how to figure out which part of the code is reading from a specified adress? I wana try to run another debugger inside DosBox, maybe it works if here is not some kind of limitation that force touse real cpu hardware.

What debugger?

I will just try some of the old ones, TD or ... I think I still have my old Symantec compiler cd somewhere arround. It had a dosdebugger too AFAIR.
My need is somth that detect memory reads, as I described before

TR may work if it runs under dosbox, since it has some emulation capabilities.
Other stuff may not catch memory reads since that relies on debug registers
which are not emulated by dosbox.

If you want to set breakpoints on memory read, you could try updating the last patch at Searching memory for values with Dosbox debugger to latest dosbox.

The diff file has to be included in the source code and than compiled with the debugger feature I guess?
Seems to be a bit to complicated for me 😵