Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Escape key with breakpoint set; the program asks user to press (ESC); Pressing ESC halts execution #269
Is there a way to disable the ESCAPE key behavior while a BREAKPOINT is set?
I have a breakpoint set in a path of code that is executed after the program will solicit input and the user has the option to press the ESCAPE key.
I then boot the WizardryIV disk. I get the solicit from the program with the option to press the ESCAPE key. I press the ESCAPE key, but instead of Wizardry getting the key press, APPLEWIN processes the key and displays the debugger window at a somewhat random location.
I'd like to be able to disable the default action of APPLEWIN when the ESC key is pressed so that I can get into the code that processes the ESCAPE key in Wizardry and then hit a breakpoint in that path of code.
This might apply to other keys besides just the ESCAPE key, but this is the one causing me problems at the moment.
The specific sequence in Wizardry is:
I want to explore the path of code in WizardryIV that processes the ESC key.
I've quickly checked the source code and the short summary is only the ESC key stops the debug stepping mode. And there's no way to disable or change to a different key.
Specifically this happens in
Also the ESC key is fed into the debugger to generate the same "stop debug stepping" behaviour here:
So any change or extension to the behaviour needs to take all of the above into account.
What do you suggest as an alternative to ESC to quit this stepping mode? (Maybe just relying on F7 is enough?)
Since this is only a problem with the ESC key, perhaps it is not a big issue especially since I have a work-around, but here are my ideas if a change is deemed appropriate.
Some users will want the ESC key to work the way it currently does. Others will want it to always be accepted as input to the AppleII. And yet others might want it to work one way on Monday and differently on Tuesday. So we invent a configuration check-box on the AppleWin "Input" tab:
[ ] Send all keystrokes (including ESC) to the AppleII
The default is to not have it checked. When checked, and the ESC key is pressed, it is sent to the AppleII just like any other key.
Another alternative is to invent a sequence of keystrokes that are interpreted as "whatever the next keystroke is, send it to the Apple II and don't process it as you normally would". I was thinking along the lines of the following:
Say you are e.e. cummings using Notepad and you want to enter the capital letter "A" into a document, but your shift key is broken. Can it be done? Yes! Press and hold the ALT key, and then using the numeric keypad press and release the keys: "0", "6", "5". Now release the ALT key. The ASCII character 065, "A", appears in your document.
I don't think this technique can be used by AppleWin because I think the sequence of keys is interpreted by Windows and then sent to the program (Notepad) as though the "A" was pressed on the keyboard, but perhaps you get the idea.
And here is my work-around:
Run the emulator until the dialog with the ESC key option is displayed. Set a breakpoint in the ESC key handler in WizardryIV. Set another breakpoint on $C000. Go back to the emulation and press any key. The breakpoint at $C000 is hit. Change the value in the loaded register (here the Accumulator) to have the character we really want ($1B) and set the Negative flag in the processor status (debugger command: SEN). We have now faked out the emulator into thinking that we pressed ESC instead of the infamous "any key". The emulator will now stop in the WizardryIV ESC key handler.