🚀 go-pugleaf

> I have noticed that the arrow keys don't seem to work in the VT52 Terminal
> Mode.  Also the function keys, as well as the cursor keys, don't seem to
> produce unique or distinguishible codes. Has anyone else noticed this? 

The ST keyboard outputs "scan codes" which are numbers that identify
the key that was depressed but which bear no relation to ASCII.  The
keyboard handling code in TOS has some translation tables which map
the scan codes into ASCII characters.

The trouble is, the default translation tables translate all the
special keys, including the arrow keys, into the same ASCII code
which happens to be NULL (ASCII code 0).  Unless a program explicitly
requests to change these translation tables, it gets the same
ASCII code for each of these special keys.

I suspect that the VT52 emulator just uses the default tables.
It is somewhat of a pain to try to look at the scan codes for the
special keys and map them into something sensible.  The definition
of "sensible" is also somewhat difficult in the context of a VT52
emulation (VT52's don't have arrow keys, so what ASCII sequence do
you transmit for these keys?).  They should have emulated a VT100
or something a little more modern instead.  On the other hand, the
VT52 command set is somewhat less baroque than the VT100's.

The keyboard code in TOS is pretty screwed up in general.  Here is
one gotcha with changing the translation tables:  If you change them,
you must make a system call to put back the default ones before you
exit, otherwise the system will lock up (because you have presumably
put the new tables in your program's address space, which TOS clears
to all zeroes when a program exits).  So far, no problem.  Your
program should be careful to restore the translation tables.  But
what if TOS kills your program without giving it a chance to fix up
the keyboard?  Here's how this can happen:  If your program is not
presently asking to read the keyboard, and you happen to type a
control C, TOS will kill your process.  If a conin() request is
pending when you type the ^C, your program gets to see the ^C and
handle it itself.  If no conin() is pending, the program gets killed.

Does anybody know how to get control of the ^C handling?  I would
like to find some way to prevent my program from getting killed
without giving it a chance to clean up.  (It doesn't seem possible
to keep a conin() request pending all the time, because, for
instance, when you are in the middle of a long write() to a file
you are sensitive to being killed).  Clearly one should just not type
^C, but I would like to make my software "idiot proof".

Mitch