New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Escape key with breakpoint set; the program asks user to press (ESC); Pressing ESC halts execution #269

Closed
TommyGH opened this Issue Feb 24, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@TommyGH

TommyGH commented Feb 24, 2015

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:

  • Boot disk 1
  • Press "M" for M)ake Scenario
  • Press ENTER key for next screen
  • Press ESC

I want to explore the path of code in WizardryIV that processes the ESC key.

Tommy

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Feb 25, 2015

Contributor

Hi Tommy,

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 void DebuggerInputConsoleChar(TCHAR).

Also the ESC key is fed into the debugger to generate the same "stop debug stepping" behaviour here:

  • When the PAUSE key is pressed and g_nAppMode == MODE_STEPPING
  • When the Debug icon (F7) is pressed and g_nAppMode == MODE_STEPPING

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?)

Contributor

tomcw commented Feb 25, 2015

Hi Tommy,

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 void DebuggerInputConsoleChar(TCHAR).

Also the ESC key is fed into the debugger to generate the same "stop debug stepping" behaviour here:

  • When the PAUSE key is pressed and g_nAppMode == MODE_STEPPING
  • When the Debug icon (F7) is pressed and g_nAppMode == MODE_STEPPING

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?)

@tomcw tomcw added the enhancement label Feb 25, 2015

@sicklittlemonkey

This comment has been minimized.

Show comment
Hide comment
@sicklittlemonkey

sicklittlemonkey Feb 26, 2015

Contributor
Contributor

sicklittlemonkey commented Feb 26, 2015

@TommyGH

This comment has been minimized.

Show comment
Hide comment
@TommyGH

TommyGH Feb 26, 2015

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.

Tommy

TommyGH commented Feb 26, 2015

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.

Tommy

@TommyGH TommyGH closed this Feb 26, 2015

@TommyGH TommyGH reopened this Feb 26, 2015

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Aug 15, 2017

Contributor

FYI, this was fixed in 1.26.3.0 (commit 5e6a445).

Contributor

tomcw commented Aug 15, 2017

FYI, this was fixed in 1.26.3.0 (commit 5e6a445).

@tomcw tomcw closed this Aug 15, 2017

@tomcw tomcw added this to the 1.27 milestone Sep 29, 2017

@tomcw tomcw self-assigned this Sep 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment