Bicer.ES@XEROX.COM (04/10/86)
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? Thanks for the info, Jack Bicer Bicer.ES@Xerox.ARPA
neil@atari.UUcp (Neil Harris) (04/15/86)
In article <860409-150043-1731@Xerox>, Bicer.ES@XEROX.COM writes: > 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? A true VT52 does not have arrow keys, function keys, or even a numeric keypad. The Atari emulator follows this guideline. ---> Neil @ Atari UUCP: ...lll-crg!vecpyr!atari!neil
wmb@sun.uucp (Mitch Bradley) (04/16/86)
> 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
fischer@YALE.ARPA (Michael Fischer) (04/18/86)
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".
I had a similar problem with ^Q/^S when I wrote a terminal emulator
-- sometimes they would be passed through to my program and sometimes
they would be interpreted by TOS. My advice from Atari was to avoid
the GEMDOS conin()/conout() calls altogether and to use the BIOS
calls directly. I did that and the problem went away. But even
though the problem was only with keyboard input, it seemed to be
necessary to avoid conout() as well, for it interacts in mysterious
ways with conin().
--Mike Fischer
-------