VOGONS


DOSBox debugger

Topic actions

Reply 61 of 159, by hookersuper

User metadata
Rank Newbie
Rank
Newbie

DOSBOX debugger (installer 0.72) does not run in Windows 7.
WHY?
Look at the attached JPG. If u don't speak Russian - the alert says:
"The program "DOSBOX emulator" does not work and will be closed.
Click to close it."

Attachments

Reply 62 of 159, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I'll add creating a debugger version of 0.74 to my to do list.
I'll try to have it done this week.

Water flows down the stream
How to ask questions the smart way!

Reply 66 of 159, by egons

User metadata
Rank Newbie
Rank
Newbie

all things what i want from debugger:
1. conitional BP's like bp if edx=value. this feature supported in Syser kernel debugger.
2. dump VGA palette. it would be great, tired of catching some palettes.

256bytes.net - demos all-in-one

Reply 68 of 159, by mwinter

User metadata
Rank Newbie
Rank
Newbie

I've found the heavy debugger to be incredibly useful for interrogating old assembly code of mine. I've noticed however that when single-stepping through a program, the dosbox display doesn't seem to update regularly. This can be frustrating when dealing with more complicated c-code because, for example, I tend to have to wait for an indeterminate amount of time to see a printf output.

Looking through the code it seems that the debug loop doesn't regularly call the render updates, which seem to all stem from VGA_VerticalTimer. Since this also adds several PIC events I can see why it would be a potential problem to have that regularly run while debugging, but would it be possible to force a display update with a command in the debug window? Is it in fact dangerous to run VGA_VerticalTimer while the debugger is broken on a line?

Thanks,
-Mark Winter

Reply 70 of 159, by mwinter

User metadata
Rank Newbie
Rank
Newbie

I was using auto, however a quick test with core=normal exhibits the same behavior. Specifically, the the dosbox window won't change after single-stepping over a "printf" call and in fact the only way to get an update seems to be to set a breakpoint past some code which takes a bit more time to run and hit F5.

In this case I'm testing with some straight c code compiled with borland turbo-c 2.01. Digging far enough down, the screen print inside the printf is an "INT 21h,AH=40h," dos write-to-file call with stdout (0x01) as the file handle. I believe the behavior on a direct write to video memory is the same though.

-Mark Winter

Reply 71 of 159, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

ah you mean the main window, not the debug window.
Indeed, that one needs vga events to trigger. You could if your code allows it, fire a timerirq. There is a debug command for that.

Water flows down the stream
How to ask questions the smart way!

Reply 72 of 159, by mwinter

User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:

ah you mean the main window, not the debug window.
Indeed, that one needs vga events to trigger. You could if your code allows it, fire a timerirq. There is a debug command for that.

Yes, sorry for the confusion and I'll give timerirq that a try, thanks.

-Mark Winter

Reply 74 of 159, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Debugger builds provided by Qbix are probably "heavy"; few bother with the middle ground. However, if you want to know for sure in any debugger build, there will be memory-change breakpoint commands (BPM/BPPM/BPLM) and CPU logging commands listed when you use the HELP command in the debugger.

Reply 75 of 159, by Zyxel

User metadata
Rank Newbie
Rank
Newbie
ripsaw8080 wrote:

Debugger builds provided by Qbix are probably "heavy"; few bother with the middle ground. However, if you want to know for sure in any debugger build, there will be memory-change breakpoint commands (BPM/BPPM/BPLM) and CPU logging commands listed when you use the HELP command in the debugger.

Thanks for your help,
The Win binary executable, that I was referring to, indeed offers the BPM/BPPM/BPLM commands, so according to this criteria - this is an indication that this binary is the "Heavy Debug" version.

BTW: Do you know of any document that describes the functionality of debugger commands. I am teaching basic assembler to some young students and such description of debugger commands would come in really handy.
I tried the DosBox Wiki at:
http://www.dosbox.com/wiki/Main_Page
...but I could not find any descriptions of the debugger commands there, e.g. the path where the HEAVYLOG command saves its results, etc...

Reply 76 of 159, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There's a guide for the debugger in the guides section, but it's rather ancient, so might not be 100% accurate now. The guide is not in-depth; some familiarity with concepts found in other debugging environments is assumed. You can refer to the debugger source code for specifics that aren't obvious, if needed.

Reply 77 of 159, by Allegro

User metadata
Rank Newbie
Rank
Newbie

Hi all,

I am newbie on this forum and in dosbox development (and honestly in xNIX as well) so please be polity for my presumaby stupid questions.

I've tried to compile dosbox on Win 7, using latest MinGW/MSYS and pdcurses 3.4 with heavy debug option turned on. everything went fine but when debugger activated none of extended keys (arrow keys, Insert/Delete/Home/End/Page Up/Page Down) works. I've tried to use both latest SVN and RELEASE 0.74 revisions, but the result is the same. Digging into source code and debugging shown that funtion toupper changes correct key returned by getch function to wrong one for extended keys. For example: KEY_UP (0x103) turns into 0x3. What may be the reason of such odd behavior?

Reply 78 of 159, by klise

User metadata
Rank Newbie
Rank
Newbie

I'm so happy I've successfully compiled DosBox 0.74 heavy-debug version in Visual C++ 2010 Express, the source code downloads from

http://source.dosbox.com/dosboxcvs.tgz

and I've seen the debugger help text, which is the newest, and it's quite different from the old guide of

Guide to the DOSBox debugger

I'm so glad that BPINT command now has included an AL parameters, not only an AH like the older version.

Here is the inner help text of this newest DosBox 0.74 Heavy-Debug version:

Debugger commands (enter all values in hex or as register):
--------------------------------------------------------------------------
F3/F6 - Previous command in history.
F4/F7 - Next command in history.
F5 - Run.
F9 - Set/Remove breakpoint.
F10/F11 - Step over / trace into instruction.
ALT + D/E/S/X/B - Set data view to DS:SI/ES:DI/SS:SP/DS:DX/ES:BX.
Escape - Clear input line.
Up/Down - Move code view cursor.
Page Up/Down - Scroll data view.
Home/End - Scroll log messages.
BP [segment]:[offset] - Set breakpoint.
BPINT [intNr] * - Set interrupt breakpoint.
BPINT [intNr] [ah] * - Set interrupt breakpoint with ah.
BPINT [intNr] [ah] [al] - Set interrupt breakpoint with ah and al.

BPM [segment]:[offset] - Set memory breakpoint (memory change).
BPPM [selector]:[offset]- Set pmode-memory breakpoint (memory change).
BPLM [linear address] - Set linear memory breakpoint (memory change).
BPLIST - List breakpoints.
BPDEL [bpNr] / * - Delete breakpoint nr / all.
C / D [segment]:[offset] - Set code / data view address.
DOS MCBS - Show Memory Control Block chain.
INT [nr] / INTT [nr] - Execute / Trace into interrupt.
LOG [num] - Write cpu log file.
LOGS/LOGL [num] - Write short/long cpu log file.
HEAVYLOG - Enable/Disable automatic cpu log when dosbox exits.
ZEROPROTECT - Enable/Disable zero code execution detection.
SR [reg] [value] - Set register value.
SM [seg]:[off] [val] [.]..- Set memory with following values.
IV [seg]:[off] [name] - Create var name for memory address.
SV [filename] - Save var list in file.
LV [filename] - Load var list from file.
ADDLOG [message] - Add message to the log file.
MEMDUMP [seg]:[off] [len] - Write memory to file memdump.txt.
MEMDUMPBIN :[o] [len] - Write memory to file memdump.bin.
SELINFO [segName] - Show selector info.
INTVEC [filename] - Writes interrupt vector table to file.
INTHAND [intNum] - Set code view to interrupt handler.
CPU - Display CPU status information.
GDT - Lists descriptors of the GDT.
LDT - Lists descriptors of the LDT.
IDT - Lists descriptors of the IDT.
PAGING [page] - Display content of page table.
EXTEND - Toggle additional info.
TIMERIRQ - Run the system timer.
HELP - Help

Edit by Qbix: Update archive location to prefered location

Reply 79 of 159, by klise

User metadata
Rank Newbie
Rank
Newbie

Hello, Qbix,

I've compiled doxbox successfully via MinGW+MSys in my Windows XP, event the heavy-debugger too. It needs SDL library for dosbox, and "pdcurses" for the debugger, to complete the works. I think I should post a topic to write down these steps so the others can save their time when they try to do this at next time.

Here I encounter a problem, that the dosbox.exe is 14,033KB big, and the heavy-debugger is 14,590KB too. I think it maybe contains much more "in-line debugging information" inside the EXE file. I'm working in Windows so I'm no so farmiliar to *nix, so how can I reduce the size of the output EXE file ?

P.S:
My dosbox version is : http://source.dosbox.com/dosboxsvn.tgz