First post, by jez

User metadata
Rank Member

Hi all. This is a bit of a long shot but I thought I'd try here to see whether anyone could help. I'm trying to debug a DOS game, Castles, and I'm debugging the executable CASTLES1.EXE. I've opened and analyzed it in IDA, and I'm also running the DOSBox debugger 0.74-2 and starting the program with "DEBUG CASTLES1.EXE".

I've found the location of the code I want to break on in IDA, and struggled to find where that code was in the DOSBox debugger window. I think I've found it, which I basically did by doing a "MEMDUMPBIN xxxx:0000 100000" where xxxx is the code segment I was in when the program started up, and searching for the byte sequence I wanted. I then jumped to that offset in DOSBox debugger and the code bytes matched. I set a breakpoint there, and.... it doesn't hit the breakpoint, ever.

Logically it should. It's some code that changes a string in the game, and I modified it to make it always show the same string. When I did that modification, the game always showed the same string, so it's definitely this code that is getting run to change the string. But the DOSBox debugger doesn't hit it.

Any ideas about what I might be doing wrong? Any more info needed? Cheers!

== Jez ==

Reply 1 of 2, by ripsaw8080

User metadata
Rank DOSBox Author
DOSBox Author

Probably because the segment register is not a match for your breakpoint. For example, 01A2:28AA and 0000:42CA reference the same location in memory, but the segment has to match to trigger the breakpoint. I've thought of adding a BPL breakpoint that references the linear memory address rather than segment/descriptor:offset, but it has some complications.

Something I've done in the situation is to use the debugger's SM command to modify the code at the target location to an interrupt instruction and then set a BPINT breakpoint. INT 64 is good to use because it is usually available. When the interrupt breakpoint triggers you will learn the value of CS at the time the code executes.