Thanks for answer. DOSBox is a great emulator and very useful not only to play, but also to debug. I'll give it a try and try to load the BIOS in memory and then do a JMP FFFF:0 Let's see if I can somehow get further.

I'm having an issue with memdump/memdumpbin - for some reason it's not producing a memory dump. I've tried with and without running the program under DEBUG (MS-Debug). DosBox gives me the correct log message of "DEBUG: Memory dump success.", however I cannot find memoydump.txt/bin under my current directory, where DosBox is installed, or where the program I'm debugging is installed. I've also done multiple full-system searches for these files and they do not exist.

EDIT: I just downloaded DOSBox-X and this feature appears to work. File is saved in the mounted directory as expected.

Alek wrote on 2023-05-01, 01:35:

I'm having an issue with memdump/memdumpbin - for some reason it's not producing a memory dump. I've tried with and without running the program under DEBUG (MS-Debug). DosBox gives me the correct log message of "DEBUG: Memory dump success.", however I cannot find memoydump.txt/bin under my current directory, where DosBox is installed, or where the program I'm debugging is installed. I've also done multiple full-system searches for these files and they do not exist.

It looks like it should be "MEMDUMP.TXT" in your current working directory, presumably in ugly uppercase if you have a case-sensitive filesystem. Would your searches have picked that up?

doshea wrote on 2023-05-02, 09:25:

Alek wrote on 2023-05-01, 01:35:

I'm having an issue with memdump/memdumpbin - for some reason it's not producing a memory dump. I've tried with and without running the program under DEBUG (MS-Debug). DosBox gives me the correct log message of "DEBUG: Memory dump success.", however I cannot find memoydump.txt/bin under my current directory, where DosBox is installed, or where the program I'm debugging is installed. I've also done multiple full-system searches for these files and they do not exist.

It looks like it should be "MEMDUMP.TXT" in your current working directory, presumably in ugly uppercase if you have a case-sensitive filesystem. Would your searches have picked that up?

Yes as I explained above I did a full system search and searched in all the logical places, however DosBox-X has this feature working just fine - it puts it where the fs is mounted.

In the debugger, the MEMDUMP command creates a text file named MEMDUMP.TXT, the MEMDUMPBIN command creates a binary file named MEMDUMP.BIN. The files are created in the current directory, sometimes referred to as the working directory, which is not necessarily the same as a mounted directory although it might be. On Windows, if the DOSBox executable is run directly then the current directory is where the executable is located, but if run through a shortcut then the current directory is where the shortcut specifies (i.e., the "Start in" textbox of the shortcut). If the dump files are not being created then perhaps the current directory is invalid in the shortcut or access rights are insufficient to create files in the current directory.

ripsaw8080 wrote on 2023-05-03, 07:48:

In the debugger, the MEMDUMP command creates a text file named MEMDUMP.TXT, the MEMDUMPBIN command creates a binary file named MEMDUMP.BIN. The files are created in the current directory, sometimes referred to as the working directory, which is not necessarily the same as a mounted directory although it might be. On Windows, if the DOSBox executable is run directly then the current directory is where the executable is located, but if run through a shortcut then the current directory is where the shortcut specifies (i.e., the "Start in" textbox of the shortcut). If the dump files are not being created then perhaps the current directory is invalid in the shortcut or access rights are insufficient to create files in the current directory.

Would DosBox give me the "DEBUG: Memory dump success." message if creating the file has failed due to access rights?

I wouldn't think so, but then I'd also think the file is being created. What is the current directory in your case?

i also always got trouble easily finding the output files - so i just added a fixed path to all my needed output files memdump, cpulog etc. - maybe also a solution for you or a way to check if the file isn't generated at all (for whatever reason)

ripsaw8080 wrote on 2023-05-04, 05:00:

I wouldn't think so, but then I'd also think the file is being created. What is the current directory in your case?

I just tested again by running as an admin. Again for some reason this works with DOSBox-X and not regular DOSBox. My mount is in C:\dosprogs, DOSBox-X runs out of my user Downloads folder, DOSBox runs out of C:\Program Files, that's why I thought maybe its a permissions issue. Just to reiterate, I've done full system scans for the files in case I missed obviously places where the memdumpbin/memdump would put the files. The file creation is likely failing, and although I haven't looked at the source - I'm certain there are probably some additional checks to verify the file was created, written, and closed correctly. Perhaps also add to the DEBUG message, "Wrote file to: <location>". For now I have to use DOSBox-X because the binary I'm working with is packed, so I need to dump out the unpacked segments. Sorry to be a nuisance; I'd check the source and do further testing if this wasn't on subversion 🙁

"Program Files" is likely the problem, as you'd tend to run into UAC. You could try making a shortcut that puts the current directory somewhere not restrictive; or just put the vanilla debugger executable where you're putting the fork executable.

The SaveMemory() code in DOSBox-X appears no different than that in official source, so the environment given to the respective programs decides the results.

I ran as admin and it still didn't work, I'll try moving to a user directory. In this case the file create would still fail, so I think there should be error checking at least instead of saying the dump was saved.

Alek wrote on 2023-05-06, 14:18:

I ran as admin and it still didn't work, I'll try moving to a user directory. In this case the file create would still fail, so I think there should be error checking at least instead of saying the dump was saved.

Writes from unprivileged programs to Program Files don't fail, they get redirected to user\AppData\Local\VirtualStore\Program Files.

At least in 0.74-3, in the MEMDUMP* commands there is error checking for the call to fopen(), but not for the calls to fprintf()/fwrite()/fclose(). Sorry, I'm not going to offer a patch for this as I don't have a build tree set up and haven't built DOSBox in a very long time!

jmarsh wrote on 2023-05-06, 20:36:

Alek wrote on 2023-05-06, 14:18:

I ran as admin and it still didn't work, I'll try moving to a user directory. In this case the file create would still fail, so I think there should be error checking at least instead of saying the dump was saved.

Writes from unprivileged programs to Program Files don't fail, they get redirected to user\AppData\Local\VirtualStore\Program Files.

I scanned my entire computer for the files and they never show up regardless, it only works with DosBox-X. I haven't got around to moving my DosBox install to a user directory, but regardless I'm very certain that the files are not being created.

Edit: Also yes, they will fail with error code 5 if its a permissions issue. Not sure where you are getting this information about VirtualStore.

Hi There,

On a Reverse Engineering Website, I read the following :-

"For finding the graphic routines you have two options:

The first is to entirely use IDA, and simply search for immediate values of 'A000h'. Since this is the area of memory that graphics are commonly displayed in, it can be a quick way to locate graphic routines.

The other alternative is to use the DosBox Debugger. It has a use command called 'bpm' that allow you to set a memory breakpoint, which then gets triggered if the given memory address changes. So you could do 'bpm A000:0' to set a breakpoint on the first byte of the screen memory (i.e. the top left hand corner of the screen). Then whichever routine modifies it first will trigger the breakpoint. Using the previously discussed techniques, you can find the same place in your IDA disassembly, and look into reversing that method first.

It will be likely that related functions will be next to each other, so once you've looked into the given identified function, you may also be able to review previous or following functions to see if they have identifiable graphic routines."

I am trying to find In IDA Pro 5 the Assembly Code, For a Plane in a WW2 Dos Game. I typed the bpm A000:0 in Dosbox X Debugger and then ran the game and changed to a view showing the Plane in Question.

I got the following output :- DEBUG: Memory breakpoint : A000:0000 - 9F -> 15 what does this output mean ? In IDA Pro 5 with the game .exe File Decompiled what should I search for ?

I have allready looked for A000h in IDA Pro , but what should I interpret from that DEBUG line i.e. what does 9F -> 15 mean ?

Any help and info would be much appreciated.

eddywinch82 wrote on 2023-09-21, 21:32:

I am trying to find In IDA Pro 5 the Assembly Code, For a Plane in a WW2 Dos Game. I typed the bpm A000:0 in Dosbox X Debugger and then ran the game and changed to a view showing the Plane in Question.
I got the following output :- DEBUG: Memory breakpoint : A000:0000 - 9F -> 15 what does this output mean ? In IDA Pro 5 with the game .exe File Decompiled what should I search for ?
I have allready looked for A000h in IDA Pro , but what should I interpret from that DEBUG line i.e. what does 9F -> 15 mean ?

1. this is the Dosbox - not Dosbox X - forum - but the feature set is similar - but go to the Dosbox X webpage to discuss bugs you eventual find

2. do you know how mode 13h, 320x200 at 256 colors is programmed/working?
that is the first thing that is absolutely needed to understand what the debugger gives you back and how to read the code behind

3. its a write to A000:0000 and the value 9F gets replaced with 15 - so some code is changing the color of pixel 0,0

but beware: its very unlikely that the code behind that pixel write is directly some function that draws planes - if will be just a pixel-set/or texture set routine that is used for every drawing in the game
normally there a some functions above this call that are relevant

so the question is: what is your assembler, 16bit coding, IDA Pro/Ghidra background - because that knowledge is very needed to understand even the tiniest part of the code

another problem is getting the point of code in IDA when finding code in the Dosbox debugger - the IDA output is not relocated but the code inside Dosbox is

and another thing: do you know that the SWOTL.EXE is LZEXE compressed - so if you look at the code in IDA, without uncompressing it first you will just see the decompression code for the exe itself?
use UNP: https://keenwiki.shikadi.net/wiki/UNP

Hi llm,

Many thanks for your very useful reply. I know the basics of using IDA Pro and basics of Assembly language. And I also understand Mode 13h for VGA Graphics. How should I go about finding the Pixel Write code in IDA Pro, if DOSBox does what you say in terms of Code relocation ?

eddywinch82 wrote on 2023-09-22, 10:42:

Hi llm,

Many thanks for your very useful reply. I know the basics of using IDA Pro and basics of Assembly language. And I also understand Mode 13h for VGA Graphics. How should I go about finding the Pixel Write code in IDA Pro, if DOSBox does what you say in terms of Code relocation ?

the clean way:
1. i extended my Dosbox Staging version to print the loading-segment of the DOS exe, calculate the 32bit offset from that = load_seg *16 = load_ofs32
2. the seg:ofs of the code your sitting in the Dosbox Debugger - the code you want to reach in IDA -> calculate the linar offset of it with seg*16+ofs => current_ofs32
3. distance = current_ofs32 - load_ofs32
4. in IDA jump to the ea(adress) with the distance

the search way:
look at the bytes around your dosbox debugger code and try to find that Hex-Pattern in HxD in the exe file and its fileoffset- do not use code bytes that contain segments (like mov ax,ds or mov dx,es ...) because these will change due to relocation
the go to IDA an jump to the file-offset you found in HxD

Hi llm,

Many thanks for you help so far, excellent info you have provided. I have looked at the DOSBox Staging Website on Github, and I have looked at the download page, which version of DOSBox is your Staging Version is it. 0.78.0 ? I noticed your name credited there, on the page for that Version ? Is the print the loading-segment of the DOS exe feature, also available in Version 0.78.1 or only 0.78.0 ? I say that, as that version has the Debugger built in, whereas the other versions don't. Also in your staging Version, how do you print the loading segment from the .exe file ? I.e. what Key or Key combination do you press , to show and export the data ?

the BPM (breakpoint on memory change) feature seems not to work when using F10 (only with F5) - or do i use it the wrong way?

long time dosbox debugger user but never used BPM before

in src\platform\visualc\config.h

1#define C_DEBUG 1
2#define C_HEAVY_DEBUG 1

in dosbox-SVN.conf

1[cpu]
2core      = normal

current SVN build with VS2022 and latest third party source builds using vcpkg

my nasm test program bpm.asm

1; nasm -f bin bpm.asm -o bpm.com
2org 100h
3mov byte [var],1
4mov byte [var],2
5mov byte [var],3
6mov ax,4C00h
7int 21h
8var db 0ffh

the breakpoint only hits after program end

what i try

1. in dosbox: debug bpm.com
2. set data view to ds:114 - the variable with the start value 0xFF
3. set a BPM to ds:114
4. step through the 1,2,3 assign - nothing happens
5. at the end a breakpoint hit?

shouldn't the breakpoint hit on every [var] mov - or is it a feature that is does not break on F10?