![]() Keeping this issue open until we'll have proper documentation for building with this feature enabled. Remember about creating release build, otherwise our normal debug logs will interfere with debugger feature. Windows: install pdcurses using vcpkg, manually edit file src/platform/visualc/config.h and enable the version of debugger you want, build Release configuration.ĭon't ask me what's the difference between debugger and heavy-debugger because authors didn't bother to write documentation. C:MinGWmsys1.0homeAdministratordosboxsrc to the folder you created. Copy the dosbox.exe file located under the dosboxsrc folder, e.g. Create a folder with a name of your choosing. Linux, macOS: install ncurses development package using your native package manager, create a release build with additional configure flag, either: -enable-debug or -enable-debug=heavy. The last step is to gather all the files together in a folder. That being said, I consider the debugger feature to be broken currently and have no real incentive to fixing it.Ĭontributions in this area are very welcome - starting with properly documenting how to build a version with Debugger feature enabled quick documentation is as follows: how do I bring up the debugger (classic DOSBox appears to do that with Alt-Pause keys: how do I do that if my computer doesn't have a pause key?)Īfter building a version with debugger feature enabled for yourself, pressing Ctrl+F1 will bring up a keymapper, and in there a new action appears (called "Debugger") you will be able to remap this action to some other key combination, it will look like this:.No, we do not provide pre-built versions of DOSBox with debugger feature enabled (neither the "debug" nor "heavy debug" flavours). Are there dosbox-staging builds with debug enabled?. ![]() Back in the days, I remember finding and tweaking the "loiter a while" 3 hours time limit in less than 30 minutes. ![]() I used it like 20 years ago and never found any other debugger as powerful as this one was. To be honest, I really missed good old SoftICE. So, did some of you manage to use it successfully? I'm pretty sure I'm not doing things right but even after looking for information on the internet, I can't understand why DOSBox debugger is behaving like it does with DF. And then, if it does, I can only hope current CPU registers will give me enough information. It can be used to see in real time the state of the palette, display offset, display stride, and other useful information. This debug information reflects the video state at the start of active display. It's quite frustrating and the only solution I came into is to set breakpoints on a dozen function instructions, hoping DOSBox will eventually break into one of them. Added debug menu and nf option to show debug information at the bottom of the screen when enabled. But then, either DOSBox never breaks (even if it goes through the code) or if it does, I'm unable to step over/through the following instructions using F10/F11. I'm able to locate the exact instruction where I want DOSBox to stop and put a breakpoint there. Even if I managed to understand some very useful functions and translate them from decompiled C code to DFU C# engine (see my recent PR related to NPC greetings), the main problem I have is I can't manage to use DOSBox debugger properly. However, my current method of doing it is essentially static. During the last months, I've gathered some experience at reverse engineering classic mechanics.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |