Page 2 of 3
Posted: 14 Apr 2018, 23:19
by snacksthecat
Working on a new theory that I'm a moron and the 6P6C cable is crossing over the wires... stay tuned!
Posted: 15 Apr 2018, 00:42
by snacksthecat
zool wrote: Opps, I missed your pic of the numbering.
here is my corrected pin out with my reasons in "{}"
1. Case GND/Shield. {connects to Ground Plane}
2. Reset {link not populated so optinal reset line}
3. VCC {Suppression Cap}
4. GND {center pin of regulator(assuming 7805)}
5. Clock/Data {goes off to hex buffer}
6. Clock/Data {goes off to hex buffer}
snacksthecat wrote: Working on a new theory that I'm a moron and the 6P6C cable is crossing over the wires... stay tuned!
Really sorry for confusing anyone. I basically posted pictures of (1) the keyboard connector pinout and (2) the 6c6p breakout board pinout with conflicting numbering. Here's a picture of everything in context
(side note: as you can see in the picture, both the keyboard pcb and the breakout board are numbered this way so I have no idea why I didn't pay attention to this):
Anyways my tests were matching this and also matches with your latest post zool (after fixing my dumb numbering):
1. Clock or Data
2. Clock or Data
3. GND
4. Vcc
5. Reset or NC
6. Case GND/Shield
Yes! I swear to God, YES!
Posted: 15 Apr 2018, 01:23
by zool
well I'm glad that's been cleared up. : P
Posted: 28 Apr 2018, 18:48
by snacksthecat
Enough is enough. Today marks the beginning of my war on capacitors.
Just to recap, the Alloy Link case is a an unsolved death with few suspects to date. Upon to the scene, investigators found the victim unresponsive with no signs of life. The case immediately became suspicious due to the young age and outward healthy appearance of the board.
Recently we received a tip from a CI to look into the capacitor gang (notorious for mysterious keyboard deaths). Today we apprehended twelve suspects and are beginning the interrogation process.
I'm reaching out to the true (keyboard) crime community for help identifying the individuals.
Here are the dirty dozen in a lineup:
If you know names the following individuals, please contact me here with information.
Green Boy:
Big Red:
Little Red:
Blue Dude:
Tiny Tim:
Posted: 28 Apr 2018, 23:47
by zool
Green Boy 0.1uF ceramic
BigRed look like poly or tantalum?
LittleRed look like poly or tantalum?
BlueDude 2.2uF Tantalum
Tiny Tim 10pF Ceramic
Posted: 29 Apr 2018, 02:33
by snacksthecat
Some new developments in the case have unfolded in these past couple hours. I was reviewing the crime scene photos and found something that I had overlooked initially. It looks to me like one of the jumpers on the board had met an untimely fate and was either snipped or accidentally severed. I must warn you, the following photos may be shocking to some viewers:
This jumper connects to the trace for pin #5 (presumed to be reset or NC) and leads to the indicated pin on HD7407P component.
Now due to public outcry about the perceived innocence of ceramic/poly/tantalum capacitors, the department will be releasing all current suspects in this case back to the board at this time.
I'm not sure of the significance of the snipped jumper and am again turning to the public for tips. Is this just an innocent misunderstanding or is it possible that it's something more than that?
Posted: 29 Apr 2018, 05:13
by zool
replace the link. repeat experiments.
just be sure, when you release blue dude that he get back home the right way, or else your gonna have a bad day.
Posted: 29 Apr 2018, 16:11
by snacksthecat
Three other jumpers are missing as well (J05, J06, J09). However, these look like they were intentionally left disconnected from the factory rather than cut after the fact (since they appear to have never been populated in the first place). Is it safe to assume that these probably are not the problem?
Posted: 30 Apr 2018, 01:25
by snacksthecat
DEAR LORD. WE HAVE SIGNS OF LIFE!!!
Posted: 30 Apr 2018, 02:24
by zool
snacksthecat wrote: DEAR LORD. WE HAVE SIGNS OF LIFE!!!
yay
Posted: 30 Apr 2018, 06:04
by snacksthecat
Only two keys on the board produce any sort of activity in hid_listen or Saleae logic: RShift and LCtrl
RShift (press)
RShift (release)
Posted: 30 Apr 2018, 09:34
by zool
0x36(54) (I don't know why it does parse the first nibble) and 0xb6(182) are indeed the right scan codes for scancode set 1, 2 and set 3's Right Shift.
if you get 0x1d and 0x9d for the Left Control you have set 1 or 2 if 0x38 then that narrows it down to set 3.
further reading:
http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html
That aside, you can also use your logic analyser to check that the keyboard is being scanned (just solder on some wire some to the matrix, that will help you trace down what is going on, and why only a few keys are being sent. and don't forget you can use the port on your saleae(gen2 or later) as analog if the levels are being pull low from a bad components etc.
Posted: 01 May 2018, 03:23
by snacksthecat
So I was able to get this far after I realized that the keyboard needed more than 5v (should have known!). It's still just those two keys but I haven't really had any time to tinker with it more. I did have a chance to try out LCtrl and it did indeed output 0x1d and 0x9d.
When I first plug it in, the keyboard sends a bunch of the same message over and over again until I hit one of the two magic buttons. Here's what it looks like:
Would this imply that the keyboard is AT protocol? I was reading on the train today and came across this sentence that struck me [1]:
When the AT keyboard is first reset it's supposed to send an AA if its self-test passed or FD or FC if it failed. But before it does this, it sends a continual stream of AAs with the parity incorrect. Once the computer sends an FE to indicate that there is a parity error, the keyboard stops sending bad AAs and sends a correct AA or an FD or FC.
Some miscellaneous thoughts
- I'm still not sure if I have the power situation figured out. Right now I have it boosted up to 12v using a step up regulator thingy.
- The LEDs are certainly brighter with this 12v but they flicker a bit (not sure if normal).
- It's interesting that the two keys that work are modifier keys (at least it seems a bit noteworthy)
- I want to play around with the teensy and see if I'm able to send it the "FE" mentioned above
- Soarer's converter still isn't working (though I haven't tried forcing the code set through config in this new state)
- Hoping I didn't mess anything up when I removed all the capacitors. I made sure to put everything back exactly like it was before
- I'm still clueless about that snipped jumper. Right now I replaced it with a bit of wire but it doesn't seem to make a difference.
[1]
https://www.cs.cmu.edu/~jmcm/info/key2.txt
Posted: 01 May 2018, 04:16
by zool
snacksthecat wrote:
Would this imply that the keyboard is AT protocol?
Possibly, it does however narrow down the scan set to 1.
snacksthecat wrote:
- I'm still not sure if I have the power situation figured out. Right now I have it boosted up to 12v using a step up regulator thingy.
This is where a multimeter / scope comes in handy. you need to see what is happening on the controllers power pins.
snacksthecat wrote:
[*]The LEDs are certainly brighter with this 12v but they flicker a bit (not sure if normal).
Almost makes me think the it is continually resetting, but also maybe not, maybe its just polling for host to be ready.
snacksthecat wrote:
[*]I want to play around with the teensy and see if I'm able to send it the "FE" mentioned above
Agree.
Posted: 04 May 2018, 04:02
by snacksthecat
Not much news but I realized that left shift was being depressed by the stabilizer bar which accounts for the never ending stream of "0x2A"s coming out of the keyboard
On the bright side I guess we've learned that one more key works!
Posted: 04 May 2018, 10:13
by zool
snacksthecat wrote: Not much news but I realized that left shift was being depressed by the stabilizer bar which accounts for the never ending stream of "0x2A"s coming out of the keyboard
On the bright side I guess we've learned that one more key works!
I'm still puzzled why you are not seeing a clock. it should be there. you
need to find the clock.
Posted: 04 May 2018, 15:02
by snacksthecat
We’ll get there. I’m not the smartest cookie when it comes to this stuff but I’m persistent as hell and have raging OCD.
Posted: 05 May 2018, 16:31
by snacksthecat
So it looks like things are falling into two groups....
Group A: Keys that "work"
- Left Shift
- Right Shift
- Left Ctrl
Group B: Keys that don't work
The
Group A keys are all connected directly to the big chip on the board and to ground.
The
Group B keys are all matrixed to different combinations of the smaller chips. (note: I'm not being precise here; some of these little chips might not be part of the matrix and might serve a different purpose)
Based on this, I'm thinking that one or more of the smaller chips might be dead and that's why they aren't producing a signal (and possibly why there is no clock signal produced by the board). I think my next experiment will be to swap out these small chips for fresh components. Does that sound logical?
Posted: 05 May 2018, 17:32
by zool
a dead multiplexer would give you the most issues with the other keys, but it is moot without the clock.
1. check voltage on all the IC supply pins, they all should be 5V. On this vintage DIP they tend to be on opposite corners like this
2. I would expect to see the clock generated from the main processor. (the NEC part aka the big chip).
3. The multiplexer will the the next biggest chip. in might be a dec hex multiplex. (check your pics and yeah it the 7419 chip and it is a hex decoder that will go off to the other switches in the matrix).
4. Two mysteries remain for me.
A. is the power supply. something does not seem right, but that may just be in the communication?
B. is the clock, where is the clock. If there is no clock it must be serial, but there was a reason we thought it was not serial wasn't there?
Posted: 05 May 2018, 17:46
by snacksthecat
Good call! Here's what I got:
Posted: 05 May 2018, 17:47
by seebart
snacksthecat wrote: Thanks! And I apologize if this is a stupid question or if I've worded it stupidly; I'm not the best at articulating myself.
Nothing stupid about it at all. Nice board and good job!
Posted: 05 May 2018, 18:01
by zool
U4 and u5 are both 5V chips. have a bit of a poke around on VCC traces and see if you can find what is pulling it down (probably one of the bypassing caps (Green Boys)). you can desolder those ones next to U4 and U5 with any harm.
Posted: 05 May 2018, 18:51
by snacksthecat
Posted: 05 May 2018, 19:34
by snacksthecat
Good news:
All the keys produce a signal according to the Saleae. Here's an "A":
Even the lock lights work!
Bad news:
Still no sign of a clock.
zool wrote:
B. is the clock, where is the clock. If there is no clock it must be serial, but there was a reason we thought it was not serial wasn't there?
I believe it was because of that magazine snip you shared that said it's a "PC-XT-type keyboard"
Posted: 05 May 2018, 20:30
by snacksthecat
I searched through the Hasu's awesome collection of converters looking for anything based on serial and decided to try out the Sony News converter [1]. Much to my surprise, it actually kinda works! By that I mean that when I hit some keys on the keyboard, some letters appear on my PC. Obviously it's all gibberish since it sounds like the Alloy board uses XT scan codes.
I'm wondering if there are any converters (similar to Soarer's or Hasu's) that are RS232 to USB and might be easy to modify the code to process XT scan codes?
Alternatively, I could try to modify Hasu's Sony News converter but the code looked a little bit over my head so I'm not sure how I'd go about doing that.
[1]
https://github.com/tmk/tmk_keyboard/tre ... r/news_usb
Posted: 05 May 2018, 22:14
by snacksthecat
Holy smokes! I'm able to read the scan codes using the UART pin on the teensy! This is really cool
Now let's see if I can mash together some community members' code to get a working board.
Posted: 06 May 2018, 03:40
by zool
fantastic!
So thats pretty cool, they must have done a terminal style workstation at some point.
If the news reads fine then all you will need to do (probably/maybe) is to change the keymap.
Posted: 06 May 2018, 06:24
by zool
So you maybe be wondering a bit where from here?
Since RS232 has been with us for such a long time there have been quite a few different variations, and since Link Alloy made their own systems it could be running their own standards. It could be some really weird mix.
One thing that you will need to figure out is if it is a scan code based system or if it is a character based system. It is a subtle difference, with a character based system the keyboard holds keyboard state, with the scan code system the host hold the keyboard state.
You can test this pretty easy. Try "A" key, note the make and break codes, then hold shift and note the make break codes for "A" key.
if you get different codes for "A" then you have a character based system. (which is cool as to have what I presume would be a lightly modified ascii keyboard?).
Anyway the method I would recommend is to get a picture of the keyboard layout and with your arduino sketch go through and note all the code for press and release of each key individually. Then do it again but holding down the each of modifers in turn and noting the codes. And then test with shift and crtl mods and all the other keys once again noting codes. and then again with all the combos of the lock keys, oh and sys req(my favorite key btw)
There are a couple of other things that would probably happen with certain key combos, eg all the escaped key sequences to terminals should also be tested. And some you might be able to send to the keyboard itself such a "bell 0x07"
ctrl is "normally" the "escape" key.
After all that keyboard cartography you should have a pretty good idea how it all works, or should work.
Good luck, I'm interested in what it turnouts to be.
Posted: 06 May 2018, 21:19
by snacksthecat
Awesome information!
It appears to be scan code based. I was able to adapt my Arduino sketch by picking bits and pieces from other members' projects. I'm going to see if I can wire up something a bit more rugged and flash it onto there. I'll post the source code a little later today if everything works out.
Posted: 06 May 2018, 22:11
by snacksthecat
Alrighty here is the end product.
Hardware:
- Teensy 2.0
- 9V step-up voltage regulator
- 6p6c breakout board
Software:
Manak1n's Open Source XT Converter basically makes up the entirety of the code. I simply changed the looping bit to read from the hardware serial (PD2) on the Teensy instead of the clock-based reading that worked for his Model F. His XT scan code handling makes up the remainder of the sketch. Just like Manak1n's, this sketch requires that you set the "USB type" in Arduino IDE to "Keyboard + Mouse + Joystick" before you compile. Saleae told me the baud rate is 4800 and that appears to be perfect.
Here's the sketch
Code: Select all
/* Copyright (C) 2018 David M. Bednarski
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
/*
* This code is based almost entirely on Manak1n's Open Source Converter
* (XT). Please see this link for the original code:
* https://deskthority.net/workshop-f7/xt-to-usb-project-t12597.html
*/
// Please note:
// One thing I learned is that, for some reason, you can't do
// statements like "if (target == KEY_Q)"
// You'll notice that instead I compare directly with the raw
// value of that respective key.
// EG, use
// if (target == 83)
// Instead of
// if (target == KEY_NUM_LOCK)
// Otherwise, the statement will always result in FALSE!
#define HWSERIAL Serial1
// Array tracks keys currently being held
uint8_t keysHeld[6] = {0, 0, 0, 0, 0, 0}; // 6 keys max
// global variables, track Ctrl, Shift, Alt, Gui (Windows), and NumLock key statuses.
int modifiers = 0; // 1=c, 2=s, 3=sc, 4=a, 5=ac, 6=as, 7=asc, 8=g, 9=gc...
int numLock = 0; // so you have F11, F12, and the windows key (F8 when numlock is on)
void setup() {
HWSERIAL.begin(4800);
}
// These handle press/release of Ctrl, Shift, Alt, and Gui keys
// We don't combine these as a single toggle (using XOR ^) because
// if the key press state between teensy and computer get out of sync,
// you would be stuck with the key state being reversed (up=down, down=up)
// (Okay, I'm paranoid)
void modKeyPress(uint8_t target) {
modifiers = modifiers | target;
updateModifiers();
}
void modKeyRel(uint8_t target) {
modifiers = modifiers ^ target;
updateModifiers();
}
void updateModifiers() {
Keyboard.set_modifier(modifiers);
Keyboard.send_now();
}
// Finds an open slot to place the key press signal in. (6 keys max)
// Ignores built-in key repeating.
void setOpenKey(uint8_t target) {
for (int i = 0; i < 6; i++) {
// if (keysHeld[i] == target)
// break;
if (keysHeld[i] == 0) {
switch (i) {
case 0:
Keyboard.set_key1(target);
break;
case 1:
Keyboard.set_key2(target);
break;
case 2:
Keyboard.set_key3(target);
break;
case 3:
Keyboard.set_key4(target);
break;
case 4:
Keyboard.set_key5(target);
break;
case 5:
Keyboard.set_key6(target);
break;
default:
break;
}
keysHeld[i] = target;
Keyboard.send_now();
break;
}
}
}
// Clears a key from the buffer if it's there. Otherwise, ignores.
void clearKey(uint8_t target) {
for (int i = 0; i < 6; i++) {
if (keysHeld[i] == target) {
switch (i) {
case 0:
Keyboard.set_key1(0);
break;
case 1:
Keyboard.set_key2(0);
break;
case 2:
Keyboard.set_key3(0);
break;
case 3:
Keyboard.set_key4(0);
break;
case 4:
Keyboard.set_key5(0);
break;
case 5:
Keyboard.set_key6(0);
break;
default:
break;
}
keysHeld[i] = 0;
Keyboard.send_now();
}
}
}
// These handle differences between regular key presses and numlock functions
// previously, I ran all keypresses through this. However, the number of "if"
// statements makes it somewhat inefficent, and it would break the "d" key when
// NumLock was enabled. I couldn't find out why, so I just manually re-routed
// most keys to setOpenKey()
void pressKey(uint8_t target) {
if (target == 83) { //number of keylock key
setOpenKey(KEY_NUM_LOCK);
numLock = numLock ^ 1;
} else { /// HANDLING OF EXTRA NUMLOCK KEYS. F11, F12, PAUSE, PRTSC, AND SUCH
if (numLock == 1) {
if (target == 66)
setOpenKey(KEY_F11);
else if (target == 7)
setOpenKey(KEY_F12);
else if (target == 71)
setOpenKey(KEY_PAUSE);
else if (target == 85)
setOpenKey(KEY_PRINTSCREEN);
else if (target == 58)
setOpenKey(KEY_INSERT);
else if (target == 59)
setOpenKey(KEY_DELETE);
else if (target == 65) { // Since there is no windows key.
modifiers = modifiers | 8;
updateModifiers();
} else
setOpenKey(target);
} else {
setOpenKey(target);
}
}
}
void releaseKey(uint8_t target) {
if (target == 83) {
clearKey(KEY_NUM_LOCK);
} else { /// HANDLING OF EXTRA NUMLOCK KEYS. F11, F12, PAUSE, PRTSC, AND SUCH
if (numLock == 1) {
if (target == 66)
clearKey(KEY_F11);
else if (target == 7)
clearKey(KEY_F12);
else if (target == 71)
clearKey(KEY_PAUSE);
else if (target == 85)
clearKey(KEY_PRINTSCREEN);
else if (target == 58)
clearKey(KEY_INSERT);
else if (target == 59)
clearKey(KEY_DELETE);
else if (target == 65) { // Since there is no windows key.
modifiers = modifiers ^ 8;
updateModifiers();
} else
clearKey(target);
} else {
clearKey(target);
}
}
}
// This function translates scan codes to proper key events
// First half are key presses, second half are key releases.
// setOpenKey()/clearKey() are used for siple keypresses (optimized)
// modKeyPress()/modKeyRel() are used for ctrl,shift,alt,windows (optimized)
// pressKey()/releaseKey() are used for keys that are potentially affected by NumLock (semi-optimized. buggy?)
void handleKeyEvent(int value) {
switch (value) {
case 1:
setOpenKey(KEY_ESC);
break;
case 2:
setOpenKey(KEY_1);
break;
case 3:
setOpenKey(KEY_2);
break;
case 4:
setOpenKey(KEY_3);
break;
case 5:
setOpenKey(KEY_4);
break;
case 6:
setOpenKey(KEY_5);
break;
case 7:
setOpenKey(KEY_6);
break;
case 8:
setOpenKey(KEY_7);
break;
case 9:
pressKey(KEY_8);
break;
case 10:
pressKey(KEY_9);
break;
case 11:
setOpenKey(KEY_0);
break;
case 12:
setOpenKey(KEY_MINUS);
break;
case 13:
setOpenKey(KEY_EQUAL);
break;
case 14:
setOpenKey(KEY_BACKSPACE);
break;
case 15:
setOpenKey(KEY_TAB);
break;
case 16:
setOpenKey(KEY_Q);
break;
case 17:
setOpenKey(KEY_W);
break;
case 18:
setOpenKey(KEY_E);
break;
case 19:
pressKey(KEY_R);
break;
case 20:
setOpenKey(KEY_T);
break;
case 21:
setOpenKey(KEY_Y);
break;
case 22:
setOpenKey(KEY_U);
break;
case 23:
setOpenKey(KEY_I);
break;
case 24:
setOpenKey(KEY_O);
break;
case 25:
setOpenKey(KEY_P);
break;
case 26:
setOpenKey(KEY_LEFT_BRACE);
break;
case 27:
setOpenKey(KEY_RIGHT_BRACE);
break;
case 28:
setOpenKey(KEY_ENTER); // technically KEYPAD_ENTER
break;
case 29:
modKeyPress(MODIFIERKEY_CTRL); // Model F CONTROL KEY IS IN STRANGE SPOT
break;
case 30:
setOpenKey(KEY_A);
break;
case 31:
setOpenKey(KEY_S);
break;
case 32:
setOpenKey(KEY_D);
break;
case 33:
setOpenKey(KEY_F);
break;
case 34:
setOpenKey(KEY_G);
break;
case 35:
setOpenKey(KEY_H);
break;
case 36:
setOpenKey(KEY_J);
break;
case 37:
setOpenKey(KEY_K);
break;
case 38:
setOpenKey(KEY_L);
break;
case 39:
setOpenKey(KEY_SEMICOLON);
break;
case 40:
setOpenKey(KEY_QUOTE);
break;
case 41:
setOpenKey(KEY_TILDE);
break;
case 42:
modKeyPress(MODIFIERKEY_SHIFT); // Left shift
break;
case 43:
setOpenKey(KEY_BACKSLASH);
break;
case 44:
setOpenKey(KEY_Z);
break;
case 45:
setOpenKey(KEY_X);
break;
case 46:
setOpenKey(KEY_C);
break;
case 47:
setOpenKey(KEY_V);
break;
case 48:
setOpenKey(KEY_B);
break;
case 49:
setOpenKey(KEY_N);
break;
case 50:
setOpenKey(KEY_M);
break;
case 51:
setOpenKey(KEY_COMMA);
break;
case 52:
setOpenKey(KEY_PERIOD);
break;
case 53:
setOpenKey(KEY_SLASH);
break;
case 54:
modKeyPress(MODIFIERKEY_SHIFT); // Generic (left) shift used, right shift key.
break;
case 55:
pressKey(KEYPAD_ASTERIX); // Make sure to handle NUM LOCK internally!!!!!
break;
case 56:
modKeyPress(MODIFIERKEY_ALT); // left alt
break;
case 57:
setOpenKey(KEY_SPACE);
break;
case 58:
setOpenKey(KEY_CAPS_LOCK);
break;
case 59:
pressKey(KEY_F1); // F* Keys are handled under NumLock. Numlock off = 1-10. When on, F9=F11, F10=F12
break;
case 60:
pressKey(KEY_F2);
break;
case 61:
pressKey(KEY_F3);
break;
case 62:
pressKey(KEY_F4);
break;
case 63:
pressKey(KEY_F5);
break;
case 64:
pressKey(KEY_F6);
break;
case 65:
pressKey(KEY_F7);
break;
case 66:
pressKey(KEY_F8);
break;
case 67:
pressKey(KEY_F9);
break;
case 68:
pressKey(KEY_F10);
break;
case 69:
pressKey(KEY_NUM_LOCK); // HANDLED SEMI-INTERNALLY!
break;
case 70:
pressKey(KEY_SCROLL_LOCK);
break;
case 71:
pressKey(KEYPAD_7); // numbers are NumLock handled by OS
break;
case 72:
pressKey(KEYPAD_8);
break;
case 73:
pressKey(KEYPAD_9);
break;
case 74:
pressKey(KEYPAD_MINUS);
break;
case 75:
pressKey(KEYPAD_4);
break;
case 76:
pressKey(KEYPAD_5);
break;
case 77:
pressKey(KEYPAD_6);
break;
case 78:
pressKey(KEYPAD_PLUS);
break;
case 79:
pressKey(KEYPAD_1);
break;
case 80:
pressKey(KEYPAD_2);
break;
case 81:
pressKey(KEYPAD_3);
break;
case 82:
pressKey(KEYPAD_0);
break;
case 83:
pressKey(KEYPAD_PERIOD); ///THIS IS THE LAST KEY ON THE MODEL F
break;
/////////////THESE ARE THE BREAK SIGNALS//////////////
case 129:
clearKey(KEY_ESC);
break;
case 130:
clearKey(KEY_1);
break;
case 131:
clearKey(KEY_2);
break;
case 132:
clearKey(KEY_3);
break;
case 133:
clearKey(KEY_4);
break;
case 134:
clearKey(KEY_5);
break;
case 135:
clearKey(KEY_6);
break;
case 136:
clearKey(KEY_7);
break;
case 137:
clearKey(KEY_8);
break;
case 138:
clearKey(KEY_9);
break;
case 139:
clearKey(KEY_0);
break;
case 140:
clearKey(KEY_MINUS);
break;
case 141:
clearKey(KEY_EQUAL);
break;
case 142:
clearKey(KEY_BACKSPACE);
break;
case 143:
clearKey(KEY_TAB);
break;
case 144:
clearKey(KEY_Q);
break;
case 145:
clearKey(KEY_W);
break;
case 146:
clearKey(KEY_E);
break;
case 147:
clearKey(KEY_R);
break;
case 148:
clearKey(KEY_T);
break;
case 149:
clearKey(KEY_Y);
break;
case 150:
clearKey(KEY_U);
break;
case 151:
clearKey(KEY_I);
break;
case 152:
clearKey(KEY_O);
break;
case 153:
clearKey(KEY_P);
break;
case 154:
clearKey(KEY_LEFT_BRACE);
break;
case 155:
clearKey(KEY_RIGHT_BRACE);
break;
case 156:
clearKey(KEY_ENTER); // This is technically KEYPAD_ENTER
break;
case 157:
modKeyRel(MODIFIERKEY_CTRL); // Model F CONTROL KEY IS IN STRANGE SPOT
break;
case 158:
clearKey(KEY_A);
break;
case 159:
clearKey(KEY_S);
break;
case 160:
clearKey(KEY_D);
break;
case 161:
clearKey(KEY_F);
break;
case 162:
clearKey(KEY_G);
break;
case 163:
clearKey(KEY_H);
break;
case 164:
clearKey(KEY_J);
break;
case 165:
clearKey(KEY_K);
break;
case 166:
clearKey(KEY_L);
break;
case 167:
clearKey(KEY_SEMICOLON);
break;
case 168:
clearKey(KEY_QUOTE);
break;
case 169:
clearKey(KEY_TILDE);
break;
case 170:
modKeyRel(MODIFIERKEY_SHIFT); // Left shift
break;
case 171:
clearKey(KEY_BACKSLASH);
break;
case 172:
clearKey(KEY_Z);
break;
case 173:
clearKey(KEY_X);
break;
case 174:
clearKey(KEY_C);
break;
case 175:
clearKey(KEY_V);
break;
case 176:
clearKey(KEY_B);
break;
case 177:
clearKey(KEY_N);
break;
case 178:
clearKey(KEY_M);
break;
case 179:
clearKey(KEY_COMMA);
break;
case 180:
clearKey(KEY_PERIOD);
break;
case 181:
clearKey(KEY_SLASH);
break;
case 182:
modKeyRel(MODIFIERKEY_SHIFT); // Generic (left) shift used, right shift key.
break;
case 183:
releaseKey(KEYPAD_ASTERIX); // Make sure to handle NUM LOCK internally!!!!!
break;
case 184:
modKeyRel(MODIFIERKEY_ALT); // Technically left alt, registers as left alt
break;
case 185:
clearKey(KEY_SPACE);
break;
case 186:
clearKey(KEY_CAPS_LOCK);
break;
case 187:
releaseKey(KEY_F1); // F* Keys are handled under NumLock. Numlock off = 1-10. When on, F9=F11, F10=F12
break;
case 188:
releaseKey(KEY_F2);
break;
case 189:
releaseKey(KEY_F3);
break;
case 190:
releaseKey(KEY_F4);
break;
case 191:
releaseKey(KEY_F5);
break;
case 192:
releaseKey(KEY_F6);
break;
case 193:
releaseKey(KEY_F7);
break;
case 194:
releaseKey(KEY_F8);
break;
case 195:
releaseKey(KEY_F9);
break;
case 196:
releaseKey(KEY_F10);
break;
case 197:
releaseKey(KEY_NUM_LOCK); // HANDLED SEMI-INTERNALLY!
break;
case 198:
releaseKey(KEY_SCROLL_LOCK);
break;
case 199:
releaseKey(KEYPAD_7); // numbers are NumLock handled by OS
break;
case 200:
releaseKey(KEYPAD_8);
break;
case 201:
releaseKey(KEYPAD_9);
break;
case 202:
releaseKey(KEYPAD_MINUS);
break;
case 203:
releaseKey(KEYPAD_4);
break;
case 204:
releaseKey(KEYPAD_5);
break;
case 205:
releaseKey(KEYPAD_6);
break;
case 206:
releaseKey(KEYPAD_PLUS);
break;
case 207:
releaseKey(KEYPAD_1);
break;
case 208:
releaseKey(KEYPAD_2);
break;
case 209:
releaseKey(KEYPAD_3);
break;
case 210:
releaseKey(KEYPAD_0);
break;
case 211:
releaseKey(KEYPAD_PERIOD); ///THIS IS THE LAST KEY ON THE MODEL F
break;
/////////SORRY, I ONLY IMPLEMENTED MODEL F XT 83 KEY SUPPORT/////////////
default:
break;
}
}
void loop() {
int incomingByte;
if (HWSERIAL.available() > 0) {
incomingByte = HWSERIAL.read();
handleKeyEvent(incomingByte);
}
}
Hope this info is helpful to someone!
