Just ordered a Unicomp AC40T56 / 122-key

[Lessaire]

I just ordered a Unicomp AC40T56 from ebay.

How similar is it to a UB40T56? Specifically, how do I make it act like a UB40T56 with jumper 3 removed, aka Mode 3?

[jabar]

that is a really good price for that keyboard shipped... too bad I already have my Model M 122...

[Lessaire]

that is a really good price for that keyboard shipped...

Hence why I bought it first and asked questions here later. I wish I could have afforded two.

[jabar]

I am going to venture a guess that the rebranding resulted in a similar catalog number for the same UB40T56 keyboard. I am not familiar with the different jumper modes however (please enlighten me  ).

[rootwyrm]

Mechanical differences between AT40T56 and UB40T56 are limited to the branding.

Firmware is Mode2 limited and depends on the Affirmative / TN3270 application driver for that model, I believe.

[Lessaire]

It allows all 122 keys to have unique scan codes.
http://geekhack.org/index.php?topic=10985.0
http://webcache.googleusercontent.com/search?q=cache:Ruy00J_RQTAJ:really.zonky.org/%3Fp%3D1125+&cd=6&hl=en&ct=clnk&gl=us

Basically, these boards default to 'emulation' mode. F13 actually sends Shift-F1 to the computer, thus there is no such thing as Shift-F13. When in Mode 3, it's possible. If you disassemble a UB40T56 there is a jumper on the controller which sets it to Mode 3. I just want to know if anyone already knows for an absolute fact whether the rebranded Affirmative Computer boards are identical to the default Unicomp boards in this fashion.

[rootwyrm]

It allows all 122 keys to have unique scan codes.
http://geekhack.org/index.php?topic=10985.0
http://webcache.googleusercontent.com/search?q=cache:Ruy00J_RQTAJ:really.zonky.org/%3Fp%3D1125+&cd=6&hl=en&ct=clnk&gl=us

Basically, these boards default to 'emulation' mode. F13 actually sends Shift-F1 to the computer, thus there is no such thing as Shift-F13. When in Mode 3, it's possible. If you disassemble a UB40T56 there is a jumper on the controller which sets it to Mode 3. I just want to know if anyone already knows for an absolute fact whether the rebranded Affirmative Computer boards are identical to the default Unicomp boards in this fashion.

Ah - I've never been inside one. Yes, they are just rebranded - that is the only difference, which is why the model numbers are pretty much identical. ("UB" = Unicomp Brand, "AT" = Affirmative Technology.) You're more likely to have BIOS issues with Mode3 these days though - BIOS development jumped off a cliff a few years back and has been digging a hole since.

[Lessaire]

BIOS development jumped off a cliff a decade ago.

FTFY.

I ain't scared. I've got some pretty advanced BIOS editing tools from doing SLICs for my family. They act too dumb to learn Linux, and too cheap to pay for Windows. But I already know my current motherboard can handle Mode 3 just fine.

[jabar]

SLICs for my family. They act too dumb to learn Linux, and too cheap to pay for Windows.

hehehe

My Model M 122 seems to throw unique scancodes although I'm not 100% sure about F13 - F24. Should plug that in when I have the chance.

[rootwyrm]

BIOS development jumped off a cliff a decade ago.

FTFY.

I ain't scared. I've got some pretty advanced BIOS editing tools from doing SLICs for my family. They act too dumb to learn Linux, and too cheap to pay for Windows. But I already know my current motherboard can handle Mode 3 just fine.

You have the tools that got out into the wild which are incomplete and usually obsolete, passed around largely by folks who have no idea why there's a read-only bank at that address but hey they can set DMI data!

So good luck fitting 6148KB of data into less than 6144KB of space while trying to lift ROM for an incompatible LPC. Which hey, happens to be pretty much exactly why BIOSes don't have full Mode3 or even translation half the time, and most LPC SIOs don't either. (Nuvoton/Winbond set 60h[6]=1.)

[dfj]

  So - once you have found and flipped the jumper, you should now have an equivalent board to an 80s style 122. This means that you can apply the windows patch to the PS/2 driver, or enable the module options to support the 122 on linux.
  The cleanest option is usually to convert the beast to USB, however. This will give you a reliable keyboard even at bios-time, as this is bioses are somewhat mainboard-specific.
  Details on an inexpensive conversion option here.

  http://geekhack.org/index.php?topic=17458.0

  Converting such a beast to native PS/2 is what you are starting with, btw - there aren't enough sane keycodes in PS/2 to actually support a happy 122, hence all the funky shift/meta state juggling. If you intend to use the extra keys for MMOs or macros, etc... you'll want to map them to USB codes, of which there are more of. You can then map them host side to whatever you want - now that they have been uniquely sent.
  Converting to USB also lets one allocate more power for the beast, which is dodges the flaky PS/2 power limits on some mainboards. :/
I tend to stuff my adapters into the keyboards themselves as there is lots of space, then run the USB cable out through the normal strain relief - this won't work as well on an M with a removeable cable, but those unicomps tended to use fixed cables iirc.

Much luck, all'y'all can find me on irc anytime, of course.
dfj

[oTurtlez]

I got an IBM 122 for around that same price shipped, came in with a giant crack in the bottom case. Didn't mind it too too much, converted it with a Teensy w/ help from Soarer to develop a firmware that would work with the 122, and then realized that the switches all felt stiff and uncomfortable, so I took the Teensy and threw it in my M and called it a day. I'd love to use the 122, but I couldn't find anything on "lubing" the switches.

[dfj]

Lubing - I've never heard of an M needing such Much more likely something nasty is on the keys and on or in the barrels. If it were an F you could strip it down and clean it, but the M 122s require a boltmod to survive that process.
  Still - you could try removing all the caps and switches and giving them a solid cleaning with detergent. A lot of folks like to use denture cleaner, soak them, but I prefer hot water and dishwasher detergent as it is much faster. Regardless, of how one cleans keys, they need to be fully dry ( I spin them in a towel, then leave in a delicates bag overnight in front of a fan, or behind a PC's hot air exhaust) otherwise any small amount of water can and will rust the springs.
  If there is gunge down the barrels, then I'd suggest either a painstaking go with a q-tip, or a bolt-mod - or give to someone else to finish the cleanup.
just taking a close look at a few keys and cleaning them up a bit should help you figure out if dirt is a problem. It might have been used in a smoking office - or worse, been superficially cleaned up by recyclers after a fire. (I received one board in such a state - I was *not* impressed.)
dfj

lucks.

[fohat.digs]

something nasty is on the keys and on or in the barrels.

I bought a "non-working" Model M a few months back that was actually a botched grease mod. Whatever he put in the springs was really horrible and nasty, way worse than axle grease. So I took it apart, immediately threw the spring hammers into the garbage, and salvaged the rest of the parts after a thorough cleaning with hot soapy water.

[oTurtlez]

Lubing - I've never heard of an M needing such Much more likely something nasty is on the keys and on or in the barrels. If it were an F you could strip it down and clean it, but the M 122s require a boltmod to survive that process.
  Still - you could try removing all the caps and switches and giving them a solid cleaning with detergent. A lot of folks like to use denture cleaner, soak them, but I prefer hot water and dishwasher detergent as it is much faster. Regardless, of how one cleans keys, they need to be fully dry ( I spin them in a towel, then leave in a delicates bag overnight in front of a fan, or behind a PC's hot air exhaust) otherwise any small amount of water can and will rust the springs.
  If there is gunge down the barrels, then I'd suggest either a painstaking go with a q-tip, or a bolt-mod - or give to someone else to finish the cleanup.
just taking a close look at a few keys and cleaning them up a bit should help you figure out if dirt is a problem. It might have been used in a smoking office - or worse, been superficially cleaned up by recyclers after a fire. (I received one board in such a state - I was *not* impressed.)
dfj

lucks.

It's a weird kinda scratchy feeling, lots of friction compared to my Model M which I scored from my High School. A science teacher was cleaning out the space from under her back tables and found a bunch of ancient IBM lab equipment, maybe 5 M's, and an unopened copy of DOS 5. I managed to snag the DOS and the nicest looking M which had a rubber key cover (like the library ones) on the keys and that one is in pretty damn good shape. But I digress. I'll have to look at the barrels tonight after work and see if they're gunked up. And maybe try to source a new bottom :/

[JohnElliott]

My recollection from participating on the earlier thread is that there are at least three different ways a 122-key Unicomp Model M can behave:

• PC/5250: Supports Scancode sets 1-3. Function keys F13-F24 generate scancodes for Shift+F1-F12.
• Emulator: Supports Scancode sets 1-3. Function keys F13-F24 generate scancodes for F13-F24.
• Terminal: Only supports Scancode set 3. Function keys F13-F24 generate scancodes for F13-F24.

What was reported was that if jumper J3 was removed from a PC/5250 type keyboard, it would start behaving like an Emulator keyboard -- still using Scancode set 2 (so it worked without patching the Windows keyboard driver) but with the extra keys returning unique scancodes.

The only Unicomp keyboard I've got is an Affirmative 1227T, which doesn't have jumper J3 and always behaves like an Emulator keyboard, so this isn't something I've needed to test for myself.

(The best guess at the way it's done is that PC/5250 keyboards include a small 8-pin EEPROM containing the function-keys-generate-shifts layout, and unplugging J3 disables the EEPROM).

[rootwyrm]

My recollection from participating on the earlier thread is that there are at least three different ways a 122-key Unicomp Model M can behave:

• PC/5250: Supports Scancode sets 1-3. Function keys F13-F24 generate scancodes for Shift+F1-F12.
• Emulator: Supports Scancode sets 1-3. Function keys F13-F24 generate scancodes for F13-F24.
• Terminal: Only supports Scancode set 3. Function keys F13-F24 generate scancodes for F13-F24.

What was reported was that if jumper J3 was removed from a PC/5250 type keyboard, it would start behaving like an Emulator keyboard -- still using Scancode set 2 (so it worked without patching the Windows keyboard driver) but with the extra keys returning unique scancodes.

The only Unicomp keyboard I've got is an Affirmative 1227T, which doesn't have jumper J3 and always behaves like an Emulator keyboard, so this isn't something I've needed to test for myself.

(The best guess at the way it's done is that PC/5250 keyboards include a small 8-pin EEPROM containing the function-keys-generate-shifts layout, and unplugging J3 disables the EEPROM).

Ahha, I KNEW somebody had that information around here somewhere. Now we just need photos of the PCB - I'm familiar with the PSoC Unicomp uses.
However, my understanding is also that this has changed to 2-way/2-way; PC/5250+Terminal or Emulator+Terminal. To my knowledge, the Affirmative is always defaulted to Emulator since they presume presence of or provide the required Windows driver for Half-3 (Mode2 + Mode3 F-keys.) When in Terminal mode, 99% or so of BIOSes will cheerfully tell you to sod off because Mode3 support is long removed. Even LPC SIOs with Mode3 don't actually have Mode3 - they have Mode3->Mode2 translation. They also depend on the BIOS providing either interpretation or pass-through of the scancodes.

As you can guess, the 1227T is the later of the two, at least to my recollection. If they were using Cypress PSoC3 for the old ones with J3, there's no external bank and no support for external SROM. J3 probably functions as internal SROM bank select (PSoC 3 is 16KB!) presumably using GPIO trigger.

[dfj]

JohnElliot - I don't recall that 122 being able to act in set 2 without the shifts, since, well - what would they do with all the extra keys? Mebbe it was one of the other jumpers, I don't know what the first two did? Of importance to me was that without that jumper the one I had did run in set 3, since my code doesn't support set 2 at all.
   Guess we should go dig up what's left of that thread. :/
dfj

ah - was linked above...
found this in it :
http://geekhack.org/index.php?topic=10985.30
Removing the third jumper (likely disabled access to my soldered down eeprom) but - it clearly set mine into scanset 3, since my converter code then worked. My converter code simply does not support mode 2. 
  Grr - mine is still packed, though I need to find it soon and test it, before sending it off to a new home. At least I'll be able to confirm again shortly.

[JohnElliott]

Now we just need photos of the PCB - I'm familiar with the PSoC Unicomp uses.

Front or back?

 

However, my understanding is also that this has changed to 2-way/2-way; PC/5250+Terminal or Emulator+Terminal. To my knowledge, the Affirmative is always defaulted to Emulator since they presume presence of or provide the required Windows driver for Half-3 (Mode2 + Mode3 F-keys.) When in Terminal mode, 99% or so of BIOSes will cheerfully tell you to sod off because Mode3 support is long removed. Even LPC SIOs with Mode3 don't actually have Mode3 - they have Mode3->Mode2 translation. They also depend on the BIOS providing either interpretation or pass-through of the scancodes.

As you can guess, the 1227T is the later of the two, at least to my recollection. If they were using Cypress PSoC3 for the old ones with J3, there's no external bank and no support for external SROM. J3 probably functions as internal SROM bank select (PSoC 3 is 16KB!) presumably using GPIO trigger.

As far as I know, no Unicomp keyboard does "Mode2 + Mode3 F-keys." A 'Terminal' board has mode 3 function keys (F13=08h, F14=10h, F15=18h...) and an 'Emulator' board in mode 2 has mode 2 function keys (F13=1Fh, F14=27h, F15=2Fh, F16=5Eh...). Oddly, the default Windows keyboard layout does assume a mode 2 keyboard with mode 3 function keys -- I believe that's based on a Keytronic KB 3270 board.

The date codes on the 1227T PCB would seem to date it to 1998-9.

[JohnElliott]

JohnElliot - I don't recall that 122 being able to act in set 2 without the shifts, since, well - what would they do with all the extra keys?

There's plenty of room in Sets 1 and 2 for all the extra keys. It's easier to show them after translation to set 1: PA1 becomes 5A, F13-F24 become 5B-5D and 63-6B, the left-hand function keys get codes in the 6C-76 range, and the spare positions under double-size keys map to 73,78,7C,7D.

Mebbe it was one of the other jumpers, I don't know what the first two did? Of importance to me was that without that jumper the one I had did run in set 3, since my code doesn't support set 2 at all.
   Guess we should go dig up what's left of that thread. :/

In this message you seem to have had the UB40T56 (with J3 removed) operating in set 2. I even drew a diagram of it.

[dfj]

Um... wow - that's even a decent bit of work, and I remember none of it, stupid brain.

Thanks, and, well - there we go: what the unicomp spits out in scanset two with the jumper removed. Handy.
Bloody handy in fact - that will work without an adapter, particularly on linux where you'll be able to receive and remap all them keys.
Lessaire, find a 5.5mm (or 7/32") thin-wall socket, toss that jumper and enjoy.

dfj

[rootwyrm]

Now we just need photos of the PCB - I'm familiar with the PSoC Unicomp uses.

Front or back?

Show Image

Oh wow, that's the OLD one with the actual 40 pin DIP 8051 instead of the PSoC!
However, I was correct in that J3 is bank select jumper and there is no external ROM. At least not in that example. The LGS part there is the multiplexor - not ROM. I believe U3 is never used, but you'd have to ask Unicomp - it's obviously not a required component.
 

As far as I know, no Unicomp keyboard does "Mode2 + Mode3 F-keys." A 'Terminal' board has mode 3 function keys (F13=08h, F14=10h, F15=18h...) and an 'Emulator' board in mode 2 has mode 2 function keys (F13=1Fh, F14=27h, F15=2Fh, F16=5Eh...). Oddly, the default Windows keyboard layout does assume a mode 2 keyboard with mode 3 function keys -- I believe that's based on a Keytronic KB 3270 board.

I probably did a less than stellar job explaining, because you've got the order of operation wrong. (This happens when I'm popping in for a few minutes at most and can't collect my thoughts.)
The keyboard may or may not send Mode3, but that is entirely irrelevant, because the keyboard is dependent on the i8042 (LPC SIO) and BIOS to send those signals to the host. So what I said is this:
Keyboard Mode 3 -> Wire -> LPC SIO -> Mode3 xlate Mode2+Partial Mode3 -> BIOS -> Discard Mode3 or Pass-Through
I'm leaving out the part where LPC SIO also has to check if the BIOS will even accept translation (usually a separate licensed feature, so frequently the case is no.) So it really doesn't matter WHAT the keyboard is speaking at the peripheral end, and never has. The only part that actually matters is what the operating system sees, which is defined by the LPC SIO/i8042 and BIOS. Older stuff more frequently did straight pass-through - the newer stuff it's less common, in order to save space in the BIOS.
There is no requirement that LPC SIO or BIOS not translate or transcode keyboard input; only that they provide recognized scan codes to host and accept recognized scan codes from the attached peripheral. There's even a specific licensed feature in I think it was PhoenixBIOS where you could translate all supported sets into Mode 2. (Yes, even Mode 1.)
Believe me, I know the BIOS side of the house from very painful experience.

The date codes on the 1227T PCB would seem to date it to 1998-9.

I'd say that's definitely a part from '98-'00, maybe even later. Remember that MOQ on even semi-custom ICs is extremely high, so it's likely the stock lasted at least 2-3 years.

Thanks, and, well - there we go: what the unicomp spits out in scanset two with the jumper removed. Handy.
Bloody handy in fact - that will work without an adapter, particularly on linux where you'll be able to receive and remap all them keys.
Lessaire, find a 5.5mm (or 7/32") thin-wall socket, toss that jumper and enjoy. :)

Yep, that sounds about right. That's interesting to know though, because that's not 1 jumper. That's 2 x 2 pin jumpers. (JP1/JP2) That arrangement indicates that there's possibly more than two banks - off the top of my head it would give you a configuration potential of 5 banks: 1 On, 2 Off; 1 Off, 2 On; 1 On, 2 On; 1 Off, 2 Off; 1-2 Short (middle pins). I'd presume they don't use all five though.
I'm not seeing any photos showing JP3, so I'm guessing it's a 3-pin which would indicate likely a set of 3 banks are present in all models, meaning any given Unicomp 122 can operate in Mode2, Mode3 and Unknown Mode. Might be unused to save space though, or used to change layout for different languages.

[JohnElliott]

Oh wow, that's the OLD one with the actual 40 pin DIP 8051 instead of the PSoC!
However, I was correct in that J3 is bank select jumper and there is no external ROM. At least not in that example. The LGS part there is the multiplexor - not ROM. I believe U3 is never used, but you'd have to ask Unicomp - it's obviously not a required component.

I took the photos to compare to the controller from Ripster's Boscom-branded PC/5250 keyboard in the old thread. The picture of that's long gone, of course, but as I remember it the PCB for that looked almost identical, except that it had an 8-pin serial EEPROM at U3 instead of the socket, and the J3 jumper.

I probably did a less than stellar job explaining, because you've got the order of operation wrong. (This happens when I'm popping in for a few minutes at most and can't collect my thoughts.)
The keyboard may or may not send Mode3, but that is entirely irrelevant, because the keyboard is dependent on the i8042 (LPC SIO) and BIOS to send those signals to the host. So what I said is this:
Keyboard Mode 3 -> Wire -> LPC SIO -> Mode3 xlate Mode2+Partial Mode3 -> BIOS -> Discard Mode3 or Pass-Through

I still don't see what you're using 'mode2 + partial mode3' to mean.

If the i8042 is set not to translate, you get
Keyboard set 2 -> Wire -> i8042 -> Set 2 -> BIOS (or i8042prt.sys, or /vmlinuz)
Keyboard set 3 -> Wire -> i8042 -> Set 3 -> BIOS (or i8042prt.sys, or /vmlinuz)

If it is set to translate,
Keyboard set 2 -> Wire -> i8042 -> Set 1 -> BIOS (or i8042prt.sys, or /vmlinuz)
Keyboard set 3 -> Wire -> i8042 -> Translated Set 3 -> BIOS (or i8042prt.sys, or /vmlinuz)

Did you mean what I've called 'Translated Set 3'? That's nothing like Set 2 -- it's closer to Set 1.

I'm leaving out the part where LPC SIO also has to check if the BIOS will even accept translation (usually a separate licensed feature, so frequently the case is no.) So it really doesn't matter WHAT the keyboard is speaking at the peripheral end, and never has. The only part that actually matters is what the operating system sees, which is defined by the LPC SIO/i8042 and BIOS. Older stuff more frequently did straight pass-through - the newer stuff it's less common, in order to save space in the BIOS.
There is no requirement that LPC SIO or BIOS not translate or transcode keyboard input; only that they provide recognized scan codes to host and accept recognized scan codes from the attached peripheral. There's even a specific licensed feature in I think it was PhoenixBIOS where you could translate all supported sets into Mode 2. (Yes, even Mode 1.)
Believe me, I know the BIOS side of the house from very painful experience.

I think you can only realistically have two possibilities for the LPC SIO, though, because Windows and Linux deal with it directly, and from their point of view it's got to behave like the i8042 in the original PC/AT. Either it passes all scancodes through unchanged, or it translates scancodes 00-7F plus 83 and 84 according to this table and passes the rest through unchanged. Certainly the translation can't be changed for any scancode that a 102-key PS/2 keyboard in Set 2 might send, and what would be the point of having different translations for the other ones?

Even LPC SIOs with Mode3 don't actually have Mode3 - they have Mode3->Mode2 translation.

Why would the SIO distinguish between set 2 and set 3? The original i8042 doesn't.

The date codes on the 1227T PCB would seem to date it to 1998-9.

I'd say that's definitely a part from '98-'00, maybe even later. Remember that MOQ on even semi-custom ICs is extremely high, so it's likely the stock lasted at least 2-3 years.

I've just taken another look, and the build date on the case is 31 July 2000.

[Wall Street]

To steer this thread back on topic, I've ordered one of these boards from EBay which FedEx says should be delivered on Friday.

After reading this thread, I am actually somewhat disappointed in this keyboard, as I think it may actually work straight out of the box on my PC with a PS/2 port.  I wanted to tinker...

[Thimplum]

To steer this thread back on topic, I've ordered one of these boards from EBay which FedEx says should be delivered on Friday.

After reading this thread, I am actually somewhat disappointed in this keyboard, as I think it may actually work straight out of the box on my PC with a PS/2 port.  I wanted to tinker...

LOL.

[dfj]

Once you get it, fire up AutoHotkey, and see what it can get for the different keystrokes, and what it can remap for you.
One frustration, is that for DirectInput games, not all of the keys that are known to windows, and an even smaller sub set of those that are defined in USB, can be used due to the age of that spec.
  MS has even deprecated it - the current 'correct' way for a game to get keyboard input on a PC is via the OS call GetKeyboardState and/or GetKeyboardAsyncState.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646293%28v=vs.85%29.aspx
  Why does this matter to you? Because if you want to use all the fun keys within reach of home-row (long fingers!) you cannot use the default layout, and AHK will only get you so far in terms of how deeply you can remap under a program. :/
  So - if you want to have other layouts reliably, proxy with a uC through a converter (say to usb), or perhaps reverse and replace that eeprom with something more useful.
 Lucks,
dfj

[fohat.digs]

I wanted to tinker ....

Get an F-122. That is the real deal.

[Tarzan]

I have a Unicomp 122-key, model BO40B56.  I was curious to try out the jumper settings, but I only see one jumper on the board;



It was across both pins, so I removed it.  How can I tell if the F13-F122 key row is returning unique scancodes?

[0100010]

Could probably do so running this script in AHK.

[Tarzan]

Could probably do so running this script in AHK.

Okay, my programming skills are horrible, I couldn't get this to work.  Updated the default AHK script and everything...

I did find this utility, trying it out now.  Sure seems to give me scancodes, now I need to find out what they mean:

ShowKey http://wiki.xbmc.org/index.php?title=ShowKey

[dorkvader]

I think Aqua's key test will give you the scancodes of the last key pressed at the bottom. For linux, xev should give you more information than you can handle about keyboard events received.

[Tarzan]

I think Aqua's key test will give you the scancodes of the last key pressed at the bottom. For linux, xev should give you more information than you can handle about keyboard events received.

Sweet, thanks!

[dfj]

using autohotkey, you don't need to do anything fancy, just start it up, then bring it up if it was initially minimized to the icons.
 now hit View->Key History and Script Info in the menu.
  The resulting screen only updates when you hit F5, (so as to minimize the performance effect of running AHK, presumably).
The first number is the window 'VK' key code, the second is the PS/2 scancode, the u/d refers to whether the key just went up or down and the time is the number of seconds since the last event. Finally, the human readable name of the key as windows sees it follows.
The result will look something like this:

74  03F       u   0.09   F5                
4C  026       d   2.64   L                 
4B  025       d   0.02   K                 
4A  024       d   0.03   J                 
48  023       d   0.03   H                 
4C  026       u   0.05   L                 
4B  025       u   0.03   K                 
4A  024       u   0.02   J                 
48  023       u   0.02   H                 
83  06B       d   2.01   F20               
82  06A       d   0.03   F19               
81  069       d   0.08   F18               
80  068       d   0.08   F17               
83  06B       u   0.06   F20               
82  06A       u   0.03   F19               
81  069       u   0.00   F18               
80  068       u   0.02   F17               
74  03F       d   1.31   F5                
Press [F5] to refresh.

If you end up getting strange results with some keys not showing up, you might try adding #InstallKeybdHook up at the start of the file (it might be there already, commented out with a ; at the start of the line, in which case, all you'd need to do is remove the ;

lucks
dfj

[Tarzan]

using autohotkey, you don't need to do anything fancy, just start it up, then bring it up if it was initially minimized to the icons.
 now hit View->Key History and Script Info in the menu.
  The resulting screen only updates when you hit F5, (so as to minimize the performance effect of running AHK, presumably).
The first number is the window 'VK' key code, the second is the PS/2 scancode, the u/d refers to whether the key just went up or down and the time is the number of seconds since the last event. Finally, the human readable name of the key as windows sees it follows.
The result will look something like this:

74  03F       u   0.09   F5                
4C  026       d   2.64   L                 
4B  025       d   0.02   K                 
4A  024       d   0.03   J                 
48  023       d   0.03   H                 
4C  026       u   0.05   L                 
4B  025       u   0.03   K                 
4A  024       u   0.02   J                 
48  023       u   0.02   H                 
83  06B       d   2.01   F20               
82  06A       d   0.03   F19               
81  069       d   0.08   F18               
80  068       d   0.08   F17               
83  06B       u   0.06   F20               
82  06A       u   0.03   F19               
81  069       u   0.00   F18               
80  068       u   0.02   F17               
74  03F       d   1.31   F5                
Press [F5] to refresh.

If you end up getting strange results with some keys not showing up, you might try adding #InstallKeybdHook up at the start of the file (it might be there already, commented out with a ; at the start of the line, in which case, all you'd need to do is remove the ;

lucks
dfj

I appreciate the instructions!  It works as you've outlined, but I sure am getting some off results.  For example, I get F13-F20 mapped to keys F17-F24.  F21- F22, F23, and F24 are in the ten-key block to the left of the main key area.  Hrm...

Maybe I need to put that jumper back and see what results I get.  :-)

[JohnElliott]

I appreciate the instructions!  It works as you've outlined, but I sure am getting some off results.  For example, I get F13-F20 mapped to keys F17-F24.  F21- F22, F23, and F24 are in the ten-key block to the left of the main key area.  Hrm...

Maybe I need to put that jumper back and see what results I get.  :-)

I'd suggest installing one of my keyboard layouts to make the VK_ codes come out right. Windows' default mappings were written for a "KB 3270" keyboard which has different scancodes for F13-F24.

[Lessaire]

Mine is supposed to arrive tomorrow.

Now I hope I can still find that bit that actually fit for disassembling it. Having moved five times in the past two years really wears a person down and makes staying organized quite the bother.

[dfj]

Crap - I just moved once, and I still can't find anything (about 7 weeks ago).
dfj

[Lessaire]

It arrived yesterday, but I couldn't find a 5.5mm / 7/32 deep socket or nutspinner for the life of me, so today I said 'screw it' and went and bought one for $3.29 at Napa Auto.

The construction seems more simplistic than I remember my old one being, but that could just be my memory lying to me.

One thing that is definitely different is the left key block. The controller looks pretty similar to the one from the ancient thread.

[Wall Street]

My TD1221 arrived today from the same EBay seller listed in the first post.  I am typing on this board right now.  My board was manufactured on April 12, 2010.  As far as these boards go, that would seem to be fairly recently.  There was only slight scuffs on the bottom as if it were in a keyboard tray and the keys look very new.  After some cleaning with Alcohol I am up and running.  Now I am fooling with SharpKeys to try to map the extra/unusual keys.  I think I can get used to the enter key, and I've mapped the blank key (what was this originally intended for?) to the left shift, however, Sharpkeys can't tell the difference between F1-F12 and F22-F24 with the jumper in place.  I might have to get creative to map these.

I think that the next step may be to order a set of media keys and some blanks from Unicomp and rearrange the top row.

[LdrJagMan]

To revive a zombie thread, I thought it might be relevent that I bought a brand new 122 key UB40B5A And it looks like.... https://www.dropbox.com/s/xz7c0t9ao82h908/2014-07-09%2019.23.20.jpg that. I was wondering if cutting that blue band over what looks to be pins, be a good idea....

[0100010]

Don't cut it - it's a capacitor.