der Mouse <mouse_at_rodents.montreal.qc.ca> wrote:
> Does anyone know of any doc on the protocol spoken by the LK401?
I have the LK201 spec, which appears in Appendix B of VCB02 Video Subsystem
Technical Manual (EK-104AA-TM, a scan is online and listed in
http://vt100.net/manx/), but nothing for LK401. But I like the LK201 better,
though. LK201 is more classic, more real. LK401 is a more flimsy plastic
thingy. I'm also quite pissed off by and won't tolerate the removal of the
Compose and Wait LEDs, and the PeeCee-smelling Alt keys are disgusting.
(What ASCII codes are they supposed to generate? A keyboard is by definition a
device for transferring ASCII codes from a human to a computer.)
> Specifically, both shift keys give me
> the same code, and both "Alt Function" keys and the right-hand "Compose
> Character" key are completely dead.
Yup, the LK401 is in LK201 compatibility mode. It's there so that those who
love LK201 but don't have one can use LK401 as a stopgap substitute until we
can seize state power in a Revolution and order resumed production of LK201s.
> While the shift keys could be
> wired together, the presence of an LK_KEY_R_SHIFT define argues against
> that,
They are wired together on LK201. Separate codes for left and right Shift keys
are an LK401 extension.
> I conjecture that at least some of this is because it's running in
> LK201 mode; on comparing it to an LK201 I note that the three dead keys
> have no obvious analogues on the LK201.
Exactly.
> There are defines which appear to imply that sending 0xe9
> and expecting 0xba in return might put it in LK401 mode,
That's what you need to do.
> but there's no
> indication of what changes (for example, how LK201-compatible it is).
> I can of course just try it and see, but I'd much rather have real doc
> if it's available.
Well, sorry, I don't have any LK401 docs, just LK201, so you'll have to just
experiment.
> I'm not sure whether this is
> strictly on-topic or not,
It definitely is!
Paul Koning <pkoning_at_equallogic.com> wrote:
> I can't offer LK401 specifics, but just in case it helps, you can find
> the complete LK201 description in the PRO 300 series technical
> manual. An online copy lives in
> http://www.bitsavers.org/pdf/dec/pdp11/EK-PC300-V1-001_pro300tecV1.pdf
> or ...V2.pdf. I don't remember which of the two volumes has this.
It's probably the same LK201 spec that I have from Appendix B of VCB02 TM. (I
can't look at it, though, as it's a PDF, and I don't look at PDFs. If you want
me to look at something, make it ASCII.)
MS
P.S. I'm right in the process of writing some code for LK201. Here is the
header comment describing what I'm doing:
/*
* This module turns the DEC LK201 keyboard into an IFCTF keyboard. All LK201
* keys are given their standard ASCII meaning, and Compose feature is supported
* for entry of 8-bit characters (see below). Arrow keys generate ISO standard
* control sequences. The keypad can operate in numeric or application mode
* like on VT100, generating the same codes/sequences as on VT100. All function
* keys generate control sequences like on VT220 with some extensions. In
* general, the LK201 operates like the input half of VT220.
*
* ASCII input from the keyboard goes into a UNIX tty. This module can be
* activated by any user on any given tty, in which case the tty line is to be
* connected to the LK201, and input goes into the input queue of the same tty
* via ttyinput. Workstation drivers in the kernel can also attach this module
* in different ways so that the hardware which talks to the LK201 doesn't have
* to presented as a tty, and the input can be routed to another tty that may
* also handle workstation display output.
*
* Input in three charsets is supported: ASCII, ISO Latin-1 and KOI-8. The base
* keyboard always inputs ASCII and supports all 128 possible 7-bit characters.
* If the tty receiving the input allows 8-bit input, Compose key is enabled and
* 8-bit ISO Latin-1 characters can be entered. Hex compose using the numeric
* keypad is supported like on VT340 and VT420, which allows all 8-bit codes to
* be entered, including C1. (While 7-bit characters can also be entered via
* Compose, it is intended for entering 8-bit ISO Latin-1 characters, and is
* enabled only when the receiving tty allows 8-bit input.)
*
* An additional feature not offered by DEC is provided to enter 8-bit input in
* Russian KOI-8 instead of Latin-1. If the tty receiving the input is
* configured for KOI-8, the Latin-1 Compose feature is not available (Latin-1
* characters are garbage in KOI-8 environment) and the Compose key is redefined
* as the KOI-8 RUS/LAT switch. LAT mode is ASCII and in RUS mode Russian KOI-8
* characters are entered per yawerty map. Also in KOI-8 mode a Meta mode is
* provided which temporarily supercedes the RUS/LAT mode, entered via
* Shift-Compose. In this mode the keyboard uses the standard 7-bit ASCII map
* (with Shift, Caps Lock, and Ctrl working normally), but bit 7 is set. Like
* hexadecimal compose in Latin-1 mode, this feature allows all 8-bit codes to
* be entered.
*
* The VT220-like operation of LK201 can be altered in two ways to make it more
* UNIX-friendly. One modification, originating in VT320, puts ESC at E00
* (upper left corner of main keypad), moves the `~ key to B00 where DEC has put
* <>, and puts '<>' over ',.'. This modification makes the keyboard more like
* traditional ASCII keyboards UNIX was designed for. The other modification
* makes the F11/12/13 keys generate ESC/BS/LF like in VT100 mode on VT2xx/3xx
* terminals, while all other function keys generate their "canonical" VT2xx-
* style control sequences. This modification allows people to start taking
* advantage of new VT2xx generation features while keeping the ESC/BS/LF
* function of F11/12/13 keys from VT100 mode. Finally, the character rubout
* key generates the erase character set on the receiving tty.
*
* Autorepeat, bell and keyclick can be customised like on DEC products. A note
* about keyclicks though. The LK201 is misdesigned in a way that makes very
* clear why keyboards should be designed and built as IFCTF keyboards in
* hardware. LK201 was designed so that the host needs to configure it and then
* for the most part let it take care of itself. It implements both autorepeat
* and keyclick internally so that in theory the host only needs to receive and
* accept its transmissions without sending anything back on every key.
*
* The problem is that the keyboard doesn't know whether any given key has any
* function or not in the application in use (in each combination of Ctrl and
* Shift modifiers), and with the VT2xx/3xx terminals we've grown used to the
* keyclick being generated only if the key is defined. The keyboard isn't
* really designed for host control of the keyclick either: while there is a
* command to generate a keyclick, the keyboard is clearly designed for
* automatic keyclick generation. So how do the terminals do it? Magic?
* Well, they do a real kludge. When the keyclicks are enabled in setup, the
* LK201 is configured with keyclicks disabled. When the terminal receives a
* code for a pressed key, it checks whether that key is defined and thus
* should sound a keyclick. If a keyclick is needed, it sends a sequence to
* the LK201 that enables the keyclicks (with the desired volume), sounds the
* keyclick, and disables the keyclicks right away. Of course this is ugly and
* basically defeats the LK201 design. (Actually this is so ugly that I just
* couldn't believe that DEC terminals do it. I had to sniff the traffic
* between VT340 and LK201 to convince myself that it really does this. It
* really does unfortunately.)
*
* In this implementation I've decided not to bother with this and to let LK201
* click on every key. In this implementation almost all keys are always
* defined and generate some code or sequence. The only exceptions are Compose
* in 7-bit only mode and some main keypad keys that are not defined with Ctrl.
* Since these are rare exceptions and they are the only ones, I have decided
* not to bother.
*/
Received on Sun Feb 22 2004 - 13:36:31 GMT