The type of GDB Server being connected to. The hostname or IP of the GDB Server to connect to. These options apply only when 'GDB Server' is selected as 'Target Connection'. The GDB Server Options configure how to connect to a GDB Server and how to handle it. Specify additional J-Link options to allow enabling or disabling advanced features and fine tuning. The file path of the optional J-Link script file to use.ĭefine a memory range that should not be cached by J-Link The required JTAG/SWD clock frequency in kHz (0 to auto-detect best possible).ĭisplay the J-Link log messages to the output window. Specifies the type of interface the target has. String, select from possible interface types String, USB, USB s/n, IP s/n, IP, selection from available J-Linksĭefines how to connect Embedded Studion to the J-Link. These options apply only when 'J-Link' is selected as 'Target Connection'. The J-Link Options configure how to connect to a J-Link and how J-Link connects to the target. If it is not defined then the main load file is used. This property will have macro expansion applied to it. Specifies the type interpretation file to use. The symbol or 0x prefixed value to set the stack pointer on start debugging. If enabled the debugger will service RTT input/output in the debug terminal. The symbol or 0x prefixed address of the RTT control block. Struct members that contain the (case insensitive) string will not be displayed. The aligned page size the debugger uses when uploading address ranges. If enabled the debugger will only display variables located in the memory map.ĭebugger will start execution at symbol if defined.

The command arguments passed to the executable. The working directory for a debug session. The maximum number of threads to display. The name of the file containing register definitions.Ī file to write the output from the debug terminal to. If yes the debugger will start execution from the entry point symbol.If no the debugger will start execution from the core specific location.ĭebugger will leave the target running on debug stop. Software breakpoints and debugIO will be enabled after this point has been reached. Specifies the point in the program where startup is complete. Specifies where to set the initial breakpoint. Specifies when the initial breakpoint should be set. String, select from the list of known devicesĪlways, Only With No Breakpoint Set, Never, On Entry Select the debug interface to use to connect to the target device. These options apply to all debug interfaces. Back in the days, I remember finding and tweaking the 'loiter a while' 3 hours time limit in less than 30 minutes.The Debugger options control how to debug the project. 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'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. 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.

Dosbox debugger set entry breakpoint