VOGONS


DOSBox debugger

Topic actions

Reply 20 of 107, by jefferl

User metadata
Rank Newbie
Rank
Newbie

You must create a short cut from desktop,
Then run this short-cut , else you will shutdown dosbox-debugger immediately.

You may run the dosbox.exe from MSYS terminal environment,
this will fail to run it.
Strange things: normal version dosbox can run under MSYS terminal.

Reply 21 of 107, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

My experience is that MSys must be able to find the curses files during the configuration with the debug parameter, you should see configure messages like:

checking curses.h usability... yes
checking curses.h presence... yes
checking for curses.h... yes

the necessary files are:
\include\curses.h
\include\panel.h
\lib\libpdcurses.a
\lib\libpanel.a

You can use the lib and include folders under \MinGW or \msys\1.0\local

I always do this with a first-time configure of the source to ensure all the make files are correctly generated for an enabled debugger.

Reply 22 of 107, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

The scenario where it silently fails, dosbox has compiled configured with the debugger. It fails when trying to launch dosbox.exe. You don't need a desktop link, but jefferl figured it out, it crashes from trying to run from msys.

Reply 23 of 107, by jefferl

User metadata
Rank Newbie
Rank
Newbie

When I using dosdebugger to single steps,
The User video screen lagged to update,
Even I have steps many instruction , The screen still not updated.
In DOS environment , It's the best feature compare to windows.
Have any direction to fixed this issue ?

Reply 25 of 107, by !(rugged|handsome)

User metadata
Rank Newbie
Rank
Newbie

With the help of this howto, I've successfully compiled Dosbox 0.72 under OpenSuse 11.1.

But when I run
./configure --enable-debug=heavy
it shows the following warning (even though the packages libncurses5, libncurses6 and ncurses-devel are installed):

checking curses.h usability... yes                               
checking curses.h presence... yes
checking for curses.h... yes
checking for initscr in -lcurses... no
checking for initscr in -lpdcurses... no
configure: WARNING: Can't find curses, debug mode disabled

Apparently, the configure script looks for "curses" when it should be looking for "ncurses".
How can I change this?

Reply 26 of 107, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

try using the cvs version of dosbox (dosbox.linuxsecured.net/dosboxcvs.tgz)
it should check for ncurses as well.

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

Reply 31 of 107, by MiniMax

User metadata
Rank Moderator
Rank
Moderator
bttr wrote:

Not everybody knows how to compile such a large project successfully. 🙁

As with so much else in life. I don't know how to repair a car or build a house, so I pay other people to do it.

DOSBox 0.73 ReadMe | DOSBox Wiki | DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Win 10 Pro

Reply 33 of 107, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

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

Reply 36 of 107, by MiniMax

User metadata
Rank Moderator
Rank
Moderator

Thanks Qbix.

DOSBox 0.73 ReadMe | DOSBox Wiki | DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Win 10 Pro

Reply 38 of 107, by k9wazere

User metadata
Rank Newbie
Rank
Newbie

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!