nather@ut-emx.UUCP (Ed Nather) (02/07/89)
The Toshiba T1200HB laptop is a light-weight (11 lbs) PC clone with a supertwist backlighted LCD screen, 1 Meg memory, 720K minifloppy drive, and 20 Mb hard disk, based on an 80C86 running at 9.54 MHz. It's a small, fast machine that is very nice to use ($2250 discounted) but it has a bomb built into the keyboard system it took me two days to unravel. On "normal" PC clones the keyboard sends individual scan codes to the processor which are interpreted by the BIOS. Each key sends one (and ONLY one) unique code, with the high bit set to 0 when the key is depressed, and set to 1 when it is released. The keyboard repeats the on-going code if it is held down. All keys are independent of each other, and all do the same thing: 1 code, plus repeats, off-going marked as "negative". So for something like the left keyboard shift key, code (+)42 indicates it has been depresses, further (+)42 codes indicate it's been held down, and a -42 code indicates it's been released. I wrote a real-time data acquisition program that has run unchanged on a real IBM PC, a Standard brand clone, a Blue Chip clone, a JDR clone, and a Toshiba T3100. I was startled when it failed to run properly on a Toshiba 1200. Here's why it failed: The keys Home, PgUp, PgDn, End, Ins, Del and the 4 arrow keys send multiple codes when they are actuated. Each code is preceded by a code 224 (-96). My program ignores unrecognized codes so it didn't barf on this. But that's not all, fffolks! IF the left-hand shift key is down when you press, say, the right arrow key, the keyboard send the code sequence -96 -42, thus indicating to the program that the user has undepressed the shift key! When the right arrow key is released, it sends -96 (+)42, indicating the left-hand shift key has been pressed again! This also happens with the right-hand shift key (54) -- any of the above named keys does the same dastardly thing. In addition to totally violating the basic design criteria of the scan-coded keyboard, this heinous deed is compounded by a total silence in the normal documentation that comes with the machine. The keyboard lies to the program, and the documentation stone-walls for it. Watergate had nothing on this. I have written extra code that traps the code -96 precursor, and that throws away the bogus -42 and -54 codes generated by the keyboard, and the program now works as it should. Bah. Arrrrrrrrrrrrrrgh. Fooey. If it weren't otherwise such a nice machine I'd have crushed it under a truck wheel. -- Ed Nather Astronomy Dept, U of Texas @ Austin
dab@ftp.COM (Dave Bridgham) (02/07/89)
I'd say you havn't used any of the the so called 'extended' keyboards yet. They also engage in this idiocy. They send 0xe0 as a prefix for most of the 'extended' keys and 0xe1 followed by two codes for one key (I forget which one). The Pause key sends the scan codes to simulate pushing Ctrl then NumLock. And the PrintScreen key sends an incredible confusion of codes which change depending on what shift keys are depressed at the time. Note that 0xe0 is the UP code for 0x60. On IBM keyboards, no key has a scan code greater than or equal to 0x60. However, some third party keyboards do. I have a Keytronic KB3270/pc keyboard which gives scan codes up through 0x7f. Fortunately, it seems to avoid the magic value of 0x60 (and therefore 0xe0). Speaking of that particular keyboard. One of its keys (the key that's in the same position as the End key on an extended keyboard) doesn't give an UP code. Does anybody have any clues on this? David Bridgham FTP Software