Link Alloy (Similar to Cherry G80-0693) Conversion
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
Working on a new theory that I'm a moron and the 6P6C cable is crossing over the wires... stay tuned!
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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}
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!

- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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:
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:
Spoiler:
Spoiler:
Spoiler:
Spoiler:
Spoiler:
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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?
Spoiler:
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?
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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?




- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
DEAR LORD. WE HAVE SIGNS OF LIFE!!!


- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
Only two keys on the board produce any sort of activity in hid_listen or Saleae logic: RShift and LCtrl
RShift (press)

RShift (release)

RShift (press)

RShift (release)

-
- Location: Melbourne
- DT Pro Member: -
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.
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.
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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 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]:
Some miscellaneous thoughtsWhen 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.
- 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.
-
- Location: Melbourne
- DT Pro Member: -
Possibly, it does however narrow down the scan set to 1.
This is where a multimeter / scope comes in handy. you need to see what is happening on the controllers power pins.
Almost makes me think the it is continually resetting, but also maybe not, maybe its just polling for host to be ready.
Agree.
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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!


On the bright side I guess we've learned that one more key works!
-
- Location: Melbourne
- DT Pro Member: -
I'm still puzzled why you are not seeing a clock. it should be there. you need to find the clock.
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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.
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
So it looks like things are falling into two groups....
Group A: Keys that "work"
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?
Group A: Keys that "work"
- Left Shift
- Right Shift
- Left Ctrl
- Everything else
Spoiler:
Spoiler:
-
- Location: Melbourne
- DT Pro Member: -
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?
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?
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
Good call! Here's what I got:


- seebart
- Offtopicthority Instigator
- Location: Germany
- Main keyboard: Rotation
- Main mouse: Steelseries Sensei
- Favorite switch: IBM capacitive buckling spring
- DT Pro Member: 0061
- Contact:
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
Ah! The solder joint on one of the green boys wasn't making contact to ground. Getting some new behavior out of the keyboard now. I'll post back once I fuel up on coffee 





- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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.
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.
I believe it was because of that magazine snip you shared that said it's a "PC-XT-type keyboard"
Spoiler:
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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
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
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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.


Now let's see if I can mash together some community members' code to get a working board.
-
- Location: Melbourne
- DT Pro Member: -
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.
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"

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.
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
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.
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.
- snacksthecat
- ✶✶✶✶
- Location: USA
- Main keyboard: SSK
- Main mouse: BenQ ZOWIE EC1-A
- DT Pro Member: 0205
- Contact:
Alrighty here is the end product.
Hardware:
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
Hope this info is helpful to someone!
Spoiler:
- Teensy 2.0
- 9V step-up voltage regulator
- 6p6c breakout board
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);
}
}