Ctrl-C Interrupt?

[Bill Chatfield]

Is there any way to have Ctrl-C interrupt a BIN program like it does a
Basic program? I know Ctrl-Reset will do it, but that messes up the
screen and probably other things too.

[fadden]

It's not a system feature; it doesn't send a signal the way a UNIX line discipline does. It's being tested for explicitly by the BASIC interpreter, here: https://6502disassembly.com/a2-rom/Applesoft.html#SymISCNTC

[Hugh Hood]

Bill,

Are you able to patch the particular BIN program?

If so, I might suggest you inject a JMP somewhere in the program's main
'run' loop to some new code you graft onto the end of the code.

The new code would save the registers, poll the keyboard, check for a
CTRL-C, and just BRK if a CTRL-C is found. If not, just add whatever
code you messed up by inserting the JMP to the new code, restore the
registers, and then JMP back to where the program was interrupted.

Or, if the program already is polling the keyboard for some input, can
you just re-purpose a key you don't normally need to do the same, or
maybe JMP to a routine to add the check for CTRL-C?

Just some thoughts. Maybe none of them are appealing.

I'm assuming you're not using a IIgs where you can interrupt and Visit
the Monitor.




Hugh Hood

[I am Rob]

> Is there any way to have Ctrl-C interrupt a BIN program like it does a
> Basic program? I know Ctrl-Reset will do it, but that messes up the
> screen and probably other things too.

A simple method would be to just poll $C000, then place JSR's to this routine where you would want the keyboard to be interrupted. Say, after a page of text is displayed or even throughout your code at various places.

Another method is to just put a $00, after the code you want to check out. It has the added benefit of displaying the registers.


BIT $C000
BPL RETURN

LDA $C000
BIT $C010
CMP #$83
BNE RETURN

JMP $FF69 ; for monitor of $3D0 for Applesoft

RETURN RTS

[Bill Chatfield]

On Sun, 10 Dec 2023 17:54:54 -0800 (PST)
fadden <fad...@fadden.com> wrote:

> It's not a system feature; it doesn't send a signal the way a UNIX
> line discipline does.

Is it too much to ask for an Apple II to work like UNIX? Haha :-) :-)

I've always been frustrated by the inconsistency that you Ctrl-C a
BASIC program but you have to Ctrl-Reset a binary program. You have to
know what type of program is running to know what interrupt to use. I
guess you can always use Ctrl-Reset, but that is more invasive.

[Bill Chatfield]

On Sun, 10 Dec 2023 21:10:13 -0600
Hugh Hood <hugh...@earthlink.net> wrote:

> Just some thoughts. Maybe none of them are appealing.
>
> I'm assuming you're not using a IIgs where you can interrupt and
> Visit the Monitor.

I am working on a Apple II/e/c program with the cc65 C compiler. I can
check for Ctrl-C in various places.

[Bill Chatfield]

On Sun, 10 Dec 2023 20:30:01 -0800 (PST)
I am Rob <gid...@sasktel.net> wrote:

> A simple method would be to just poll $C000, then place JSR's to this
> routine where you would want the keyboard to be interrupted. Say,
> after a page of text is displayed or even throughout your code at
> various places.

Yes, I can try that. Thanks!

[Oliver Schmidt]

Hi Bill,

> I am working on a Apple II/e/c program with the cc65 C compiler. I can
> check for Ctrl-C in various places.

In this case I suggest to use
- kbhit() and cgetc() to detect the Ctrl-C
- exit() to quit if Ctrl-C was detected
- atexit() to run custom cleanup code

Not directly related but there's also doesclrscrafterexit() that allows you
determine if the user will be able to read output from your program after
exit - i.e. an error message. You can call it i.e. from your atexit()
function and call cgetc() if it returns true having the user acknowledge
that he has read the message.

Regards,
Oliver

[Bill Chatfield]

On Mon, 11 Dec 2023 19:10:41 -0000 (UTC)
Oliver Schmidt <ol...@web.de> wrote:

> In this case I suggest to use
> - kbhit() and cgetc() to detect the Ctrl-C
> - exit() to quit if Ctrl-C was detected
> - atexit() to run custom cleanup code

Thanks! I was thinking of using an asm block to check KBD for
characters. What you said is much better. I also forgot about atexit().
I need to put that in now to close files. It's like the "finally" block
of a try/catch/finally around main(). I'm a Java programmer during the
day.

[Oliver Schmidt]

Hi Bill,

> Thanks!

You're welcome :-)

> I was thinking of using an asm block to check KBD for
> characters. What you said is much better.

I'm quite often surprised by the amount of workarounds people "find"
although the functionality is already present in the Apple II C library.

> I also forgot about atexit().
> I need to put that in now to close files. It's like the "finally" block
> of a try/catch/finally around main(). I'm a Java programmer during the
> day.

You don't need to do so for closing files. All still open files are closed
by the C library exit code.

That code is by the way also executed on Ctrl-Reset during the runtime of a
cc65 C program. So the behavior on Ctrl-Reset isn't as undefined/fatal as
you might think.

I even had once the case where I totally ran out of memory so I couldn't
add some quit code. Instead I simply documented Ctrl-Reset as the official
way to quit the program ;-)

Regards,
Oliver

[Bill Chatfield]

On Tue, 12 Dec 2023 20:36:39 -0000 (UTC)
Oliver Schmidt <ol...@web.de> wrote:

> You don't need to do so for closing files. All still open files are
> closed by the C library exit code.

I am always amazed about how well cc65 implements the standard. I was
thinking in terms of BASIC which does not do that and gets completely
screwed up if you don't close files.

> That code is by the way also executed on Ctrl-Reset during the
> runtime of a cc65 C program. So the behavior on Ctrl-Reset isn't as
> undefined/fatal as you might think.

That is very impressive. I never would have guessed that.

> I even had once the case where I totally ran out of memory so I
> couldn't add some quit code. Instead I simply documented Ctrl-Reset
> as the official way to quit the program ;-)

:D