When setting a breakpoint in x86 code (real or protected mode) in PC98 mode, pressing F11 to trace into the next instruction always causes the I flag to be set, if it is not, sets CS to F000 and IP to EA3x~, causing an interrupt to this location regardless of what instruction or register values are present.
I do not know what interrupt this corresponds to (maybe its DOS' KEYINT)? but it causes a hang for my software.
Attached image is from stepping once after 1fc0:0000.
The reason I think it might be KEYINT is because the dosbox-x window, while looks frozen, isnt actually frozen during debugging, and can accept key presses (which eventually show up). Also given function key's unreliability on macOS, perhaps it is related.
Steps to reproduce the behaviour
Load into PC-98 mode, any CPU type or model, debugger enabled
Enter debugger and use command "bp 1fc0 0"
Load a self-bootable disk into Drive A (e.g. Record of Lodoss War)
"boot a:"
In debugger window, press F11**
Observe strange results
** View desktop shortcut must be disabled in system settings
Additional behaviors:
Pressing F8, F9, F10 etc. seem to change the EIP to a different, preset location, but pressing them multiple times does nothing. Many function key functionalities appear to be broken on macOS but I cannot personally verify.
Expected behavior
JMP +0E should jump 0E bytes in front of you, not jump to F000:EA30
Recommended solution:
Allow text-alternative inputs for all debugger commands. e.g. "step", "skip", "trace" as you do with F5/"run".
What operating system(s) this bug have occurred on?
macOS sonoma 14.3.1
What version(s) of DOSBox-X have this bug?
2024.3.1 arm mac SDL2 64-bit 3.31.24/3:43:22
Used configuration
As stated above, default except mode is pc98
Output log
No relevant logging.
Additional information
It APPEARS that if you just type run then the application will return to its normal state; indicating that the step function doesn't seem to do anything to the program state at all (or perhaps it was just a lucky state before a RET).
Have you checked that no similar bug report(s) exist?
[X] I have searched and didn't find any similar bug report.
Code of Conduct & Contributing Guidelines
[X] I agree to follow the code of conduct and the contributing guidelines.
Describe the bug
When setting a breakpoint in x86 code (real or protected mode) in PC98 mode, pressing F11 to trace into the next instruction always causes the I flag to be set, if it is not, sets CS to F000 and IP to EA3x~, causing an interrupt to this location regardless of what instruction or register values are present.
I do not know what interrupt this corresponds to (maybe its DOS' KEYINT)? but it causes a hang for my software.
Attached image is from stepping once after 1fc0:0000.
The reason I think it might be KEYINT is because the dosbox-x window, while looks frozen, isnt actually frozen during debugging, and can accept key presses (which eventually show up). Also given function key's unreliability on macOS, perhaps it is related.
Steps to reproduce the behaviour
** View desktop shortcut must be disabled in system settings
Additional behaviors:
Expected behavior
JMP +0E should jump 0E bytes in front of you, not jump to F000:EA30
Recommended solution: Allow text-alternative inputs for all debugger commands. e.g. "step", "skip", "trace" as you do with F5/"run".
What operating system(s) this bug have occurred on?
macOS sonoma 14.3.1
What version(s) of DOSBox-X have this bug?
2024.3.1 arm mac SDL2 64-bit 3.31.24/3:43:22
Used configuration
Output log
Additional information
It APPEARS that if you just type run then the application will return to its normal state; indicating that the step function doesn't seem to do anything to the program state at all (or perhaps it was just a lucky state before a RET).
Have you checked that no similar bug report(s) exist?
Code of Conduct & Contributing Guidelines