that is a really good price for that keyboard shipped...
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.
BIOS development jumped off a cliff a decade ago.
SLICs for my family. They act too dumb to learn Linux, and too cheap to pay for Windows.hehehe
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.
something nasty is on the keys and on or in the barrels.
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.
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).
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.
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. :/
Now we just need photos of the PCB - I'm familiar with the PSoC Unicomp uses.
Front or back?Show Image(http://www.seasip.info/VintagePC/Images/1227T_front.jpg)
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.
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. :)
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 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.
Even LPC SIOs with Mode3 don't actually have Mode3 - they have Mode3->Mode2 translation.
QuoteThe 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.
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...
I wanted to tinker ....
Could probably do so running this (http://www.autohotkey.com/board/topic/21105-crazy-scripting-scriptlet-to-find-scancode-of-a-key/) script in AHK.
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.
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. :-)