122-key Unicomp, all scancodes?

[xwhatsit]

Hi there,

Excuse me if there's already a thread or two about this -- I did actually search first but couldn't quite get my answer.

I'm very interested in a 122-key M board. I see Unicomp offers them new; they even have a "PC/5250" board which they claim works without drivers. However from lurking around here I see that this outputs key combos rather than individual scancodes.

I use Linux, can map anything to anything. I think it's even possible to use scancode set 3 (although that might cause trouble with graphical (X) apps, as there are no `break' codes). Is there a model that would give me individual scancodes? I take it the `Terminal emulator' models are no good (Unicomp offers three types; `Terminal', `Emulator' and `PC/5250').

Cheers for any help. I've been trying to figure this out and I gather this would be the place to ask.

[ch_123]

On the 122-key keyboards with a PS/2 plug, F13 - F24 are shifted versions of F1 - F12. However, AFAIK, the other keys have unique scancodes and can be mapped to whatever you want.

[ch_123]

Yeah, the Emulator is their version of the 1397000.

Well, in general, you can assume that if it has 122 keys and a PS/2 plug, it behaves like a 1397000. Then again, those terminal keyboards are unpredictable.

[xwhatsit]

You should just call Unicomp.  I suspect the "Emulator" may act like my 1397000 (click on link in Sig for scancode details).

This is the PC/5250  Unicomp data sheet in pdf form.

Awesome. I might email them, I don't think you Americans understand New Zealand English, do you?

On their website they have the three `types' (Terminal, Emulator, PC/5250), and then three `layouts' (`5250 Format', `3270 Format', `PC/5250 Format'). I take it the types define the controller type and resulting scancodes, and the layouts are simply the key labels or something?

Anyway I'll get in contact with them and ask them. Shame there wasn't one with a normal enter key (and left shift, for that matter too).

[ch_123]

They'd also be for connector types. Terminal keyboards would use a special 5 pin DIN connector and have no lock lights. As long as you get one with a PS/2 cable and lock lights, it will function as a normal PC keyboard, and will have spare keys that can be mapped.

[xwhatsit]

They'd also be for connector types. Terminal keyboards would use a special 5 pin DIN connector and have no lock lights. As long as you get one with a PS/2 cable and lock lights, it will function as a normal PC keyboard, and will have spare keys that can be mapped.

No, that's another drop-down box yet again (PS2/Mini-Din, AT/Din, Modular/RJ-45).

Hey, as long as it's got a Rule Home key I'll be happy.

[xwhatsit]

I thought 99% of the New Zealand population went "Baa, Baa" or "Moo, Moo"?

That's my point. Harder to understand than the Model F layout.

Cheers for all the help, I'll ask Unicomp.

[ch_123]

No, that's another drop-down box yet again (PS2/Mini-Din, AT/Din, Modular/RJ-45).

Hey, as long as it's got a Rule Home key I'll be happy.

I suspect that there might be some website design failure there... There would be two quite distinct models of keyboard there - one designed to be used as a normal PC keyboard, but with extra keys, and one designed only to be used with a terminal. The former would use PS/2 or AT DIN, and the latter would use either the RJ connector, or a 240-degree DIN-5 connector.

[Shawn Stanford]

IIRC: The driverless Unicomps (I have the BOSCOM version) don't pass a special scancode for the extra keys. Rather, they pass multiple scancodes. I posted about it in this thread: http://geekhack.org/showthread.php?t=7314

[JohnElliott]

My guess at the options on the website is:

Terminal: Behaves like a real terminal board (ie, only uses scancode set 3) - would require a replacement i8042prt.sys to be used on a PC.
Emulator: Behaves like a 1397000, extra keys return unique scancodes
PC/5250: Extra keys return combinations of shifts.

I know Unicomp made 122-key driverless boards that behaved like the 1397000, because I'm typing on one now :smile:

Of course, the only way to be sure is for someone to buy one of each sort of keyboard and compare how they behave...

[xwhatsit]

OK, sounds like collective geekhack actually knows what it's talking about. Cool story bro.

I emailed Unicomp and they got back to me with this:

"The PC5250 uses all PC codes as you noted;i.e., Shift +F! for F13; Shift +F2 for F14 etc. It also has a 5250 layout. The emulator model on the other hand has unique codes for the non PC buttons.The PC would not understand the unique codes unless you had a unique driver to interpret them."

So the emulator model is indeed correct. I take it he means by `unless you had a unique driver to interpret them', that they will be ignored. On Linux you can simply edit a text file to say which scancodes are tied to what; do you have to write a new driver or something on Windows? Is that what he means?

Anyway, it sounds like the Emulator model is what I need. And I can choose between 3270 and 5250 as a matter of taste it would seem (the 1397000, therefore, is a 122-key Emulator with 3270 layout on the Unicomp website).

Wicked.

[ch_123]

Yeah, under Windows you'd need to make a special driver. Windows is rather opaque with its internals like that...

[JohnElliott]

"The PC5250 uses all PC codes as you noted;i.e., Shift +F! for F13; Shift +F2 for F14 etc. It also has a 5250 layout. The emulator model on the other hand has unique codes for the non PC buttons.The PC would not understand the unique codes unless you had a unique driver to interpret them."

So the emulator model is indeed correct. I take it he means by `unless you had a unique driver to interpret them', that they will be ignored. On Linux you can simply edit a text file to say which scancodes are tied to what; do you have to write a new driver or something on Windows? Is that what he means?

I don't think you'd need a new i8042prt.sys driver; the extra keys send scancodes to Windows programs just fine.

(I tried editing a resource script in Visual Studio to see what it made of the extra keys. It came up with:

F13-14: Ignored
F15: EraseEOF
F16: Help
F17-F24: F13-F20
ErEOF: F22)

So if you actually had a Windows program that knew about F13 to F24 and you wanted it to work with one of these keyboards, you might need to do some work with a registry-based scancode remap. I've done this on mine to turn the bottom two keys in the left-hand block into Windows and Menu).

[Shawn Stanford]

Eventually I found that the gymnastics required to keep Windows and my 122-key semi-happy with each other wasn't worth the effort. Not only that, but having spent so many years with the inverted 'T' cursor layout, I found it completely impossible to switch back-and-forth to the old-style cross layout.

The only way I would go back to the 122 at this point is if one of the programmable keyboard adapter projects came to fruition. That would allow me to do things like reprogram the cursor cross to an inverted 'T', and redefine the 'large movement' keys to their correct layout.

Still happily smurfing on the 'Space Saving' at home, though!

[xwhatsit]

Given that it's utterly straightforward to redefine and assign keycodes on Linux I don't really see that as a problem. I already have my cursor keys redefined on my awful current (104-key) work keyboard (cursor keys disabled -- vim uses jkhl, what else do I need? -- and left cursor made into another Esc).

I recall reading you had the PC/5250 version which sent `combination' scancodes. This is precisely what I want to avoid so that I can make use of 122 keys.

[xwhatsit]

Kishy:

Terminal boards only support scancode set 3, I think? And emulator boards such as the Unicomp and the 1397000 support (possibly?) 1, 2 and 3 (or maybe just 2 or something).

Set 3 won't set break codes. But you can send a command to the board to tell it to send break codes for a key or all keys. Presumably on Windows you'd have to write a new driver or something. But in Linux, presuming it's not already built into the PS/2 driver and keyboard setup commands, you could probably even do it from a BASH script (echo the appropriate bytes to the file corresponding to the keyboard, looks like /dev/input/keyboard might be the file, who knows?).

So even a full-on real terminal board might work fine under Linux with minimal effort. Now I'm learning a bit more about things this emulator board shouldn't be an issue at all.

[xwhatsit]

The typematic repeat thing is interesting. Is this like an outdated hardware-only way to send key repeats? I've seen references to it in various motherboard BIOSes. Graphical X uses the make/break situation to do its own key repeats (i.e. it's software-defined, if the key is held down then it waits for a delay then starts repeating it at a predefined rate). At the Linux console level I assume this can also be set in software.

Yep, as far as I can work out from what Unicomp responded, and what I've read here, the emulator board (as opposed to their PC/5250 board) sends individual key codes. At least I really hope so! Otherwise it's time to build the homemade USB keyboard controller I saw somewhere on this forum...

[JohnElliott]

I have no idea if typematic repeat has been overtaken by anything or not...I was under the impression that software configuration (in Windows, the Keyboard control panel applet) in fact just send commands via the driver and it was still done keyboard-end.

Yes, by default Windows uses the hardware typematic repeat on a PS/2 keyboard. However, it can be switched to software repeat using the 'Accessibility' control panel. This is intended to set up repeat rates that are slower than the one supported by the hardware, but once Windows is using software repeat you can set the rate to anything you like by editing the Registry (HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Response).

[xwhatsit]

Well I've put in my order to Unicomp. Waiting for them to get back to me regarding shipping costs now

[Shawn Stanford]

Hell, I'd have sold you that Boscom for peanuts...

[dfj]

OK, sounds like collective geekhack actually knows what it's talking about. Cool story bro.

I emailed Unicomp and they got back to me with this:

"The PC5250 uses all PC codes as you noted;i.e., Shift +F! for F13; Shift +F2 for F14 etc. It also has a 5250 layout. The emulator model on the other hand has unique codes for the non PC buttons.The PC would not understand the unique codes unless you had a unique driver to interpret them."

So the emulator model is indeed correct. I take it he means by `unless you had a unique driver to interpret them', that they will be ignored. On Linux you can simply edit a text file to say which scancodes are tied to what; do you have to write a new driver or something on Windows? Is that what he means?

Anyway, it sounds like the Emulator model is what I need. And I can choose between 3270 and 5250 as a matter of taste it would seem (the 1397000, therefore, is a 122-key Emulator with 3270 layout on the Unicomp website).

Wicked.

  I have one of the PC/5250 boards, and it generates the combo codes when stuffed into a PC. What I have not tested (because it is loaned out) is whether it will behave properly when set to scancode page 3 (properly meaning generate all the keycodes independently I want.)
  The thing also has a fair number of jumpers on board, I can still hope that they control something interesting.

  Thanks for poking the unicomp folks, they are usually pretty helpful and friendly with almost everyone I've heard of having interacted with them.
  I just wish they had inherited tooling for the 80s style Ms, rather than the lexmark models, but c'est la vie.

 I'm tempted to bug them about it - but hopefully my friend will bring it back for a weekend soon to let me sort it out. The multi-codes mess up the ability to remap stuff easily, so it's not as flexible as a 'normal' one.

dfj

[microsoft windows]

Just use Autohotkey to pick up the scancodes.   Details and code are in the Model M 1397000 link in my sig.

I'm using the same trick right now to reprogram a Japanese keyboard to pick up 3 extra keys in reach of my thumb.

I hate Japanese-layout keyboards. They're just like Japan: Way too cramped and crowded. I like having a space bar.

[ch_123]

I forgot that sucker has jumpers.  Let me know what you find out.

May be new life for my old Boscom controller yet.

Show Image

That thing looks like it was hacked together on a DIY electronics kit.

Probably was an' all =P

[microsoft windows]

On topic as ever.

There IS medication for Assburgers.

Show Image

I just don't get how liking to have a real yard and some property (Which you don't get in japan) and a spacebar I can use comfortably is some disorder.

You got to put in some more effort in your jokes. You're just like the movie industry. Running out of ideas!

[microsoft windows]

That's EIBM.

[JohnElliott]

I forgot that sucker has jumpers.  Let me know what you find out.

May be new life for my old Boscom controller yet.

Show Image

The controller in my Affirmative looks pretty similar, but it's only got two jumpers (and only one selected). I wonder what they do.

[dfj]

Perhaps related to the unpopulated chip socket?

What's the function of that chip?

I am not able to make it out in rip's pic. I don' expect it is a custom order like the main 40-pin. We likely can just look it up once ripster reads the numbers off to us.

dfj

[dfj]

Looks like my mentioned-in-IRC-theory may be correct - it's an E(E)PROM.

Layout or some scancode-related stuff could be stored in there.

Dfj, get in here!

The one with the seat for the chip din' have a jumper there - I'll guess that the boards with the jumper turn on or off the eeprom - but the boards with the seating don' need the jumper, since if the chip isn't present, then it is not turned on.

an 8 pin SPI eeprom will typically have Vcc, gnd, miso, mosi, clk, select, and mebbe a command and carry pin? Anyway, 8 pins are sufficient, even for fairly large memory-size chips since the interface is serial.

With luck someone has a pullable one and can dump the contents for us - else I need to get mine back sooner, rather than later.

sleepy,
dfj

[ch_123]

There I was thinking that it was some sort of 74-series logic chip...

[dfj]

There I was thinking that it was some sort of 74-series logic chip...

 The earlier IBM boards are laced with them, but once the decent micros started working their way in, it wasn't so much. Mostly just as boost now, where they are seen at all.

dfj

[dfj]

The controller in my Affirmative looks pretty similar, but it's only got two jumpers (and only one selected). I wonder what they do.

Show Image

and, courtesy of ripster:

I don't know what the two jumpers going into the middle of the chip do - except that they are both pull-downs. The jumper to the eeprom, however, seems to be connected to the address-size line, and then to the multiplexer for the matrix. I'm guessing that it controls the interpretation of the matrix, then.

However, here is the exciting part: pulling off the jumper converts the keyboard into a sane 122 key scan-code-page 3 board, which will 'just work' under linux, and also work with my PS2->USB converter.
 It reverts the board to the pretty diagrams that John Elliot has posted on his seasip pages. e.g. http://www.seasip.info/VintagePC/ibm_1390876.html

So - if one is to buy a 122 from unicomp, the UB40T56 _is_ the more flexible option.

chuffed,
dfj

My eeprom is soldered down, not in a socket. I hope to be able to extract the contents without pissing off the controller, but I might have little luck. I'll update when I find out more, and give JohnElliot a poke about it if he wants to cut himself a copy of one and stuff it into his board to see what happens. :)
mrr - guess I'll take shots of my controller too, so folks can compare the circuits.

[dfj]

lol - it's OK to use my pics without thanking me here.....

 No worries: I was once an academic, so I decided to replace my notion of intellectual property with attribution instead. It's largely in my spine now.
  Besides, I'm far too old to change.

[mike]

A very cool discovery. Managed to find an appropriate nutspinner at work today, so I'm busy configuring the new layout now - despite all the tools at home, nothing quite reaches the Unicom bolts

Hmm ... so Unicom keyboards are effectively programmable, although I suspect the ability to program the EEPROM isn't on board ? Shame it isn't really - that would be a neat feature ... if Unicom documented it!

[dfj]

A very cool discovery. Managed to find an appropriate nutspinner at work today, so I'm busy configuring the new layout now - despite all the tools at home, nothing quite reaches the Unicom bolts

Hmm ... so Unicom keyboards are effectively programmable, although I suspect the ability to program the EEPROM isn't on board ? Shame it isn't really - that would be a neat feature ... if Unicom documented it!

Given they sell them with custom layouts with next to no delay, I would assume that they can be burned without opening the board - especially since my eeprom is soldered in, rather than in a socket.

Anyway, the board boots into scancode page 2, without the jumper. I will post the bizarre codes for that situation shortly. It accepts a command to go into page 3 happily, though - which is where we get the normal page 3 terminal map.

With the jumper still in place, it goes into mode 3 as well, but it is madness, dropping releases (after accepting a make/break mode command), hitting shifts before certain presses, etc...

So far, I suggest running it without the jumper, under linux or with a terminal driver workaround or my usb dongle (my dongle), in mode 3.

I am looking into whether it is viable in mode-2 without the jumper.

[dfj]

Poking around, I have verified the scancodes my ub40t56 sends in page 3 as being the same as that which JohnElliott lists for the http://www.seasip.info/VintagePC/ibm_1390876.html with three exceptions:
1) Under the right shift, on a 1390876 or even 6110344, the hidden key has code 0x51, while on the unicomp it is 0x68.
2) Under the keypad 0 key, 1390876 etc... have a 0x68 for the hidden key. The Unicomp has 0x78.
3) Under the keypad enter key, in the bottom right keypad position, the 1390876 etc... have 0x78. The Unicomp does not respond - I do not think the mylar membrane's matrix has a contact in this location, for some reason. I have not confirmed this by doing a bolt-mod, but the keyboard does not respond to that press.
Guess they removed the bottom right keypad, then rolled the others over to take the places for some reason.

Hope y'all folks find this entertaining,
dfj

(PS - JohnElliott: I have confirmed the covered scancodes for the all the hidden keys on the 6110347, which is extremely likely to be consistent with your 6110344. Evidence: http://geekhack.org/attachment.php?attachmentid=11680&stc=1&d=1278808912)

[mike]

I'm concentrating on page 2 ... which doesn't look too bad to me. With the exception of the keypad to the left, everything functions more or less ok although there's a bit of confusion going on to the right.

So far I've only found one key that apparently sends neither an accepted scancode nor a scancode that the kernel tells me to setup. I'm working on a table of what is what by default which I'll double-check before going any further.

Of course Terminal compatibility is less important to me than having lots of keys to play with

[dfj]

Oh? Which board did you get? I wasn't able to quickly figure it out from a glance at yer other posts.
dfj

PS: 'nutspinner' -> I will be using this term henceforth.

[mike]

It's a UB40T56 - with just "Home" printed on the key in the middle of the arrows.

Nutspinner is a standard Britishism ... a hex socket on a stick

PS: Early draft of the page 2 page at : http://really.zonky.org/?p=1125. I should really check how JP1 and JP2 are set on my board.

[JohnElliott]

The tool I use to see what scancodes a keyboard is actually returning is one I wrote: KB, running under DOS so it drives the hardware directly. This tends to avoid problems with operating systems being helpful and interpreting or throwing away scancodes; it also lets you see the keyboard ID and select any of the three scancode sets, translated or untranslated.

I don't know if you've found this, but I had to add 'atkbd.softraw=0' to the kernel command line to get the extra keys on the Affirmative to show up in Linux. Looking at your list so far, it seems to be producing similar codes to the Affirmative in translated Set 2; so far, the only difference I can see is that it doesn't have SysRQ in the top left-hand corner.

(Would it help if we referred to the left-hand 10 key positions as L1-L10, like on a Sun Type 3 keyboard?)

[dfj]

The tool I use to see what scancodes a keyboard is actually returning is one I wrote: KB, running under DOS so it drives the hardware directly. This tends to avoid problems with operating systems being helpful and interpreting or throwing away scancodes; it also lets you see the keyboard ID and select any of the three scancode sets, translated or untranslated.

(Would it help if we referred to the left-hand 10 key positions as L1-L10, like on a Sun Type 3 keyboard?)

L1-L10 is not bad, but for new folks, nothing will be all that clear. c'est la vie.

  I don't mess with translation, I read them via an atmel micro, either a teensy or atmega168 etc.. depending on what I have at hand. Also dodges the OS attacking the events. I don' have a machine handy that boots dos, and I needed to handle that code anyway, so I just pipe a debugging stream off of my project(s), via SPI to a serial converter, and thence to a log file. Considered the dos solution, though - remembered that there were commands to switch the mode of the keyboard, and of course, the bios interrupts to disable translation and get a headsup when there were new bytes.

I forget how the prefixes were handled, though - what do you get for stuff like the extended keys and the pause key when in mode 2? Do you get to see the whole string of bytes, or is the i8042 parsing that?
  Anyway, it's definitely the sane way to approach figuring out the keystrokes. If I weren't so deep into my controller projects I would have tried much harder to find a way to do it in DOS.

OK, I'm off to edit up a post for the UB40T56, mode 2, no-jumper-3 table,
dfj

[mike]

A quick post before work ...

I wasn't previously aware of atkbd.softraw (well it rings a bell, but I wouldn't have thought of it). Reading around, there's also i8042.direct. Interesting that you had to turn that off to get responses from some of the keys - did you try the i8042 debug thing ?

Esc on my board is also labelled "SysReq" and "Attn". Personally I feel L1-L10 is a little obscure for most, and perhaps a little unIBM

[JohnElliott]

I forget how the prefixes were handled, though - what do you get for stuff like the extended keys and the pause key when in mode 2? Do you get to see the whole string of bytes, or is the i8042 parsing that?

Those always come through, whether translation is turned on or off.

[JohnElliott]

A quick post before work ...

I wasn't previously aware of atkbd.softraw (well it rings a bell, but I wouldn't have thought of it). Reading around, there's also i8042.direct. Interesting that you had to turn that off to get responses from some of the keys - did you try the i8042 debug thing ?

Esc on my board is also labelled "SysReq" and "Attn". Personally I feel L1-L10 is a little obscure for most, and perhaps a little unIBM

No, I didn't try the debug option.

The thought with using L1-L10 is that it unambiguously describes key positions, whereas keycaps vary from one board to the next. For example, the key in the L1 position is captioned "Attn / SysRq" on the Affirmative, but "Help / SysRq" on the 6110344.

[dfj]

For folks edification, here are the codes for page 2 on the Unicomp UB40T56.
I have listed the common name for keys, then the scancode that the key would have on a 1390876 as per : http://www.seasip.info/VintagePC/ibm_1390876.html finally the meat: the make and break codes that I have confirmed so far.

enjoy,
dfj

PS: I'll edit in the last of the hidden keys shortly.

Code: [Select]



101 or AT   1390876 page 3 location (break is always F0 NN for page 3)
location    |
name        |   unicomp page-2, no j3
|           |   makes   breaks
|           |   |       |
TF-13       08  1F      F0 1F
TF-14       10  27      F0 27
TF-15       18  2F      F0 2F
TF-16       20  5E      F0 5E
TF-17       28  08      F0 8
TF-18       30  10      F0 10
TF-19       38  18      F0 18
TF-20       40  20      F0 20
TF-21       48  28      F0 28
TF-22       50  30      F0 30
TF-23       57  38      F0 38
TF-24       5F  40      F0 40

TF-1        07  05      F0 5
TF-2        0F  06      F0 6
TF-3        17  04      F0 4
TF-4        1F  0C      F0 C
TF-5        27  03      F0 3
TF-6        2F  0B      F0 B
TF-7        37  83      F0 83
TF-8        3F  0A      F0 A
TF-9        47  01      F0 1
TF-10       4F  09      F0 9
TF-11       56  78      F0 78
TF-12       5E  07      F0 7

LF-1        05  6D      F0 6D
LF-2        06  5F      F0 5F

`/~         0E  0E      F0 0E
KB-1        16  16      F0 16
KB-2        1E  1E      F0 1E
KB-3        26  26      F0 26
KB-4        25  25      F0 25
KB-5        2E  2E      F0 2E
KB-6        36  36      F0 36
KB-7        3D  3D      F0 3D
KB-8        3E  3E      F0 3E
KB-9        46  46      F0 46
KB-0        45  45      F0 45
KB--        4E  4E      F0 4E
KB-=        55  55      F0 55
u-backspc   5D  
Backspace   66  66      F0 66

insert      67  17      F0 17
home        6E  E0 7D   E0 F0 7D
pg-up       6F  E0 7A   E0 F0 7A

np-num-lock 76  76      F0 76
np-/        7E  7E      F0 7E
np-*        7E  7C      F0 7C
np--        84  E0 4A   E0 F0 4A

LF-3        04  39      F0 39
LF-4        0C  E1 14 77 E1 F0 14 F0 77 (page 2 pause - there is no break)

tab         0D  D       F0 D
q           15  15      F0 15
w           1D  1D      F0 1D
e           24  24      F0 24
r           2D  2D      F0 2D
t           2C  2C      F0 2C
y           35  35      F0 35
u           3C  3C      F0 3C
i           43  43      F0 43
o           44  44      F0 44
p           4D  4D      F0 4D
{           54  54      F0 54
}           5B  5B      F0 5B

delete      64  E0 69   E0 F0 69
end         65  E0 70   E0 F0 70
pg dn       6D  E0 71   E0 F0 71

np-7        6C  6C      F0 6C
np-8        75  75      F0 75
np-9        7D  7D      F0 7D
np+/field-  7C  79      F0 79

LF-5        03  53      F0 53
LF-6        0C  50      F0 50

capslock    14  58      F0 58  (right control)
a           1C  1C      F0 1C
s           1B  1B      F0 1B
d           23  23      F0 23
f           2B  2B      F0 2B
g           34  34      F0 34
h           33  33      F0 33
j           3B  3B      F0 3B
k           42  42      F0 42
l           4B  4B      F0 4B
;           4C  4C      F0 4C
'/"         52  52      F0 52
}/{         53  5D      F0 5D
enter       5A  5A      F0 5A

cp-up       63  E0 75   E0 F0 75

np-4        6B  6B      F0 6B
np-5        73  73      F0 73
np-6        74  74      F0 74
np-field+   7B  7B      F0 7B

LF-7        83  E0 12 E0 7C E0 F0 7C E0 F0 12 (shifted 7C, numpad - (or * on 1391401))
LF-8        0A  6F      F0 6F

L-shift     12  12      F0 12
>/<         13  61      F0 61 (under left shift on 1391401)
z           1A  1A      F0 1A
x           22  22      F0 22
c           21  21      F0 21
v           2A  2A      F0 2A
b           32  32      F0 32
n           31  31      F0 31
m           3A  3A      F0 3A
,           41  41      F0 41
.           49  49      F0 49
/           4A  4A      F0 4A
u-r-shift   51  E0 1F   E0 F0 1F
r-shift     59  59      F0 59

cp-left     61  E0 6B   E0 F0 6B
cp-rule     62  E0 6C   E0 F0 6C
cp-right    6A  E0 74   E0 F0 74

np-1        69  69      F0 69
np-2        72  72      F0 72
np-3        7A  7A      F0 7A
np-enter    79  E0 5A   E0 F0 5A

LF-9        83  5C      F0 5C
LF-10       09  48      F0 48

L-CTRL      11  14      F0 14
l-alt       19  11      F0 11
space       29  29      F0 29
R-alt       39  E0 11   E0 F0 11
R-ctrl      58  E0 14   E0 F0 14

cp-down     60  E0 72   E0 F0 72

u-np-0      68  E0 2F   E0 F0 2F
np-0        70  70      F0 70
np-.        71  71      F0 71

[/B]

[JohnElliott]

For folks edification, here are the codes for page 2 on the Unicomp UB40T56.

And here's one of my SVG diagrams based on that information. I've shaded those keys where, as far as I can see, the scancodes are different from those that the Affirmative produces; some of these are for keys that send different codes depending what modifiers are in effect, so it's possible that they'll turn out to be the same after all.

[mike]

I'm concentrating on page 2

Or rather scan code set 1 ... or at least it looks that way. I've set atkbd.softraw=0 which has brought to life the printscreen key and updated my table (http://really.zonky.org/?p=1125).

[dfj]

Or rather scan code set 1 ... or at least it looks that way. I've set atkbd.softraw=0 which has brought to life the printscreen key and updated my table (http://really.zonky.org/?p=1125).

Don't be too sure - if translation is on, then all those numbers will appear in the fashion you show, rather than as f0 strings.

I noticed that one of the things that this layout does is renumber all the 0x80 and up keys so that they won't bork up when run through the i8042 translation.
 Notice that there are multi-char strings still - they just have the f0 replaced with +0x80. we're looking at the same mode, I think - I'll double check more closely later, but I must run now - grats on the success, though. What you have is more useful to remap in linux, since noone wants to deal with the f0s.

dfj

[mike]

Don't be too sure - if translation is on, then all those numbers will appear in the fashion you show, rather than as f0 strings.

Perhaps we should call it the funky Linux scan code set

I'll get on with the keypad tomorrow night and hopefully add the default keycodes together with what keycodes need remapping to match the key symbols (I can deal with an Esc key with the wrong label as long as it is where it usually is, or where it should be, but not where NumLock usually is!).

[JohnElliott]

Or rather scan code set 1 ... or at least it looks that way.

It's almost certainly set 2 coming down the wire, and being translated into set 1 by your motherboard.

[dfj]

And here's one of my SVG diagrams based on that information. I've shaded those keys where, as far as I can see, the scancodes are different from those that the Affirmative produces; some of these are for keys that send different codes depending what modifiers are in effect, so it's possible that they'll turn out to be the same after all.

Oh rock on - I was about to ask you to cut one of those for me!

PS under the enter, where one might want to put a \| is 5D, F0 5D like you guessed, but under the backspace: E0 27, E0 F0 27

As you put it L7, or AT F-7, has that crazy shift-7C sequence. not certain how you normally encode long strings like pause, etc... huh - interesting, I never noticed - pause can be thought of as right-ctrl, num-lock, num-lock-break, right-ctrl-break

happy,
dfj

[JohnElliott]

PS under the enter, where one might want to put a \| is 5D, F0 5D like you guessed, but under the backspace: E0 27, E0 F0 27

As you put it L7, or AT F-7, has that crazy shift-7C sequence. not certain how you normally encode long strings like pause, etc... huh - interesting, I never noticed - pause can be thought of as right-ctrl, num-lock, num-lock-break, right-ctrl-break

I've now updated the diagram with those two keys.

If a key produces a sequence of scancodes that isn't just 'xx' or 'E0 xx' I tend to show the bit of the sequence that isn't fake Shift or Ctrl keys, colour the key in, and describe what it actually does in the surrounding text.

[dfj]

I did another pass of the keys in  mode three, without jumper 3:

There are three differences from the 1390876 in scan-code mode 3:
under the right shift has a different code, as does the pad under the keypad 0. The keypad-enter does not seem to have an extra pad under it.

This is the set I will be using, though I'll wager the mode 2 sans-jumper-3 could likely be made to work well with windows and AHK without much trouble, excepting the pause and print-screen, which might be hard to move.

enjoy,
dfj

Code: [Select]


top fct keys:
TF-13                               08            08  F0 08              
TF-14                               10            10  F0 10
TF-15                               18            18  F0 18
TF-16                               20            20  F0 20
TF-17                               28            28  F0 28
TF-18                               30            30  F0 30
TF-19                               38            38  F0 38
TF-20                               40            40  F0 40
TF-21                               48            48  F0 48
TF-22                               50            50  F0 50
TF-23                               57            57  F0 57
TF-24                               5F            5F  F0 5F


TF-1                                07            07  F0 07
TF-2                                0F            0F  F0 0F
TF-3                                17            17  F0 17
TF-4                                1F            1F  F0 1F
TF-5                                27            27  F0 27
TF-6                                2F            2F  F0 2F
TF-7                                37            37  F0 37
TF-8                                3F            3F  F0 3F
TF-9                                47            47  F0 47
TF-10                               4F            4F  F0 4F
TF-11                               56            56  F0 56
TF-12                               5E            5E  F0 5E


left fct keys:
LF-1                                05            05   F0 05
LF-2                                06            06   F0 06
LF-3                                04            04   F0 04
LF-4                                0C            0C   F0 0C
LF-5                                03            03   F0 03
LF-6                                0B            0B   F0 0B
LF-7                                83            83   F0 83
LF-8                                0A            0A   F0 0A
LF-9                                01            01   F0 01
LF-10                               09            09   F0 09


main text area:
`/~                                 0E            0E  F0 0E
KB-1                                16            16  F0 16
KB-2                                1E            1E  F0 1E
KB-3                                26            26  F0 26
KB-4                                25            25  F0 25
KB-5                                2E            2E  F0 2E
KB-6                                36            36  F0 36
KB-7                                3D            3D  F0 3D
KB-8                                3E            3E  F0 3E
KB-9                                46            46  F0 46
KB-0                                45            45  F0 45
KB--                                4E            4E  F0 4E
KB-=                                55            55  F0 55
u-backspc                           5D            5D  F0 5D  
Backspace                           66            66  F0 66

tab                                 0D            0D  F0 0D
q                                   15            15  F0 15
w                                   1D            1D  F0 1D
e                                   24            24  F0 24
r                                   2D            2D  F0 2D
t                                   2C            2C  F0 2C
y                                   35            35  F0 35
u                                   3C            3C  F0 3C
i                                   43            43  F0 43
o                                   44            44  F0 44
p                                   4D            4D  F0 4D
{                                   54            54  F0 54
}                                   5B            5B  F0 5B
\|                                  5C            5C  F0 5C

capslock                            14            14  F0 14
a                                   1C            1C  F0 1C
s                                   1B            1B  F0 1B
d                                   23            23  F0 23
f                                   2B            2B  F0 2B
g                                   34            34  F0 34
h                                   33            33  F0 33
j                                   3B            3B  F0 3B
k                                   42            42  F0 42
l                                   4B            4B  F0 4B
;                                   4C            4C  F0 4C
'/"                                 52            52  F0 52
}/{ (under enter on US)             53            53  F0 53
enter                               5A            5A  F0 5A

L-shift                             12            12  F0 12
>/<                                 13            13  F0 13
z                                   1A            1A  F0 1A
x                                   22            22  F0 22
c                                   21            21  F0 21
v                                   2A            2A  F0 2A
b                                   32            32  F0 32
n                                   31            31  F0 31
m                                   3A            3A  F0 3A
,                                   41            41  F0 41
.                                   49            49  F0 49
/                                   4A            4A  F0 4A
u-r-shift                           51            68  F0 68 <-- different
r-shift                             59            59  F0 59

L-CTRL                              11            11  F0 11
l-alt                               19            19  F0 19
space                               29            29  F0 29
R-alt                               39            39  F0 39
R-ctrl                              58            58  F0 58


cursor-pad area:
insert                              67            67  F0 67
home                                6E            6E  F0 6E
pg-up                               6F            6F  F0 6F

delete                              64            64  F0 64
end                                 65            65  F0 65
pg dn                               6D            6D  F0 6D

cp-up                               63            63  F0 63

cp-left                             61            61  F0 61
cp-rule                             62            62  F0 62
cp-right                            6A            6A  F0 6A

cp-down                             60            60  F0 60


number-pad area:
np-num-lock                         76            76  F0 76
np-/                                77            77  F0 77
np-*                                7E            7E  F0 7E
np--                                84            84  F0 84

np-7                                6C            6C  F0 6C
np-8                                75            75  F0 75
np-9                                7D            7D  F0 7D
np+/field-                          7C            7C  F0 7C

np-4                                6B            6B  F0 6B
np-5                                73            73  F0 73
np-6                                74            74  F0 74
np-field+                           7B            7B  F0 7B

np-1                                69            69  F0 69
np-2                                72            72  F0 72
np-3                                7A            7A  F0 7A
np-enter                            79            79  F0 79

u-np-0                              68            78  F0 78 <-- different
np-0                                70            70  F0 70
np-.                                71            71  F0 71
u-np-enter                          78            --        <-- different.
            [/B]

[dfj]

So to summarize for us mere humans it seems removing the Boscom/Unicom J3 jumper makes the Boscom/Unicomp act like a IBM/Lexmark Model M 1397000.   At least at first pass looking at the scan codes.

Dang, I have no clue what codes the 1397000 puts out - anyone done a full audit? My google-fu is weak.

dfj

[dfj]

It appears that without that jumper, these keyboards are a NIB, currently manufactured, alternative to the old IBM terminal boards.
  They can even be had with sparkly keys. o.0

I'm not overly curious what is on that eeprom - my fear is that it is 1/2 of the matrix decoding logic, rather than anything sane. I only have my board back until monday, so I may or may not have time to pull it.

  enjoy yer boscoms, unicomps and 7000s folks.

dfj out

[dfj]

No google needed. It's in the 1397000 link.

bah, I read through the whole thing, even followed to dw_junion's post (he had a few scattered codes, already eaten by the i8042, though.)

I must be daft.

If we find them, I'll edit this post to stuff them in, to save the next daft sucker the effort of looking.

dfj

[JohnElliott]

I did another pass of the keys in  mode three, without jumper 3:

There are three differences from the 1390876 in scan-code mode 3:
under the right shift has a different code, as does the pad under the keypad 0. The keypad-enter does not seem to have an extra pad under it.

And here's the corresponding picture.

[JohnElliott]

I'm not overly curious what is on that eeprom - my fear is that it is 1/2 of the matrix decoding logic, rather than anything sane. I only have my board back until monday, so I may or may not have time to pull it.

If you don't, perhaps Ripster's Boscom controller could be induced to give up its EEPROM for the cause of [strike]mad[/strike] science?

[dfj]

If you don't, perhaps Ripster's Boscom controller could be induced to give up its EEPROM for the cause of [strike]mad[/strike] science?

 I've got one of them multi-pin clamp-style connectors, and I've got the keyboard for a bit longer to do a bolt-mod.
  I'll try harder to take a shot at it.

 Someone had a board less the chip? Not sure how that works, exactly. I also have no clue what the first two jumpers do yet - haven't noticed any effects from them.

dfj

[mike]

Well I've finished off my blog posting on re-mapping this keyboard (http://really.zonky.org/?p=1125) - finished off mapping out the scancodes and keycodes with the exception of the QWERTY pad (which is not so interesting) plus dealing with keymapping for X.

There's something odd going on with the Record key - once it has been pressed, some of the other keys send their own keycode followed by the Record keycode. Some sort of terminal feature ?

[JohnElliott]

Well I've finished off my blog posting on re-mapping this keyboard (http://really.zonky.org/?p=1125) - finished off mapping out the scancodes and keycodes with the exception of the QWERTY pad (which is not so interesting) plus dealing with keymapping for X.

There's something odd going on with the Record key - once it has been pressed, some of the other keys send their own keycode followed by the Record keycode. Some sort of terminal feature ?

The "E02A" that the Record key produces is fake-Shift. If you assign a keycode to that, you'll get it reported on any other key that generates fake-Shift. The sequence E02A,E037 that you've documented is produced by PrintScreen on a normal 101-key or 102-key board; and, indeed, on my Affirmative the PrintScreen key is in the L7 position, where your Record key is.

[dfj]

The "E02A" that the Record key produces is fake-Shift. If you assign a keycode to that, you'll get it reported on any other key that generates fake-Shift. The sequence E02A,E037 that you've documented is produced by PrintScreen on a normal 101-key or 102-key board; and, indeed, on my Affirmative the PrintScreen key is in the L7 position, where your Record key is.

Thanks fer the updated pic!

And now you folks see why I find mode-2 so much fun, and thus prefer mode 3. At least when I get to be the byte consumer...
 
OTOH:
 Trying to hack terminal mode 3 into the 'dose driver is a lot hurty.
I'm pretty sure that a filter-driver won't cut it, since the kb will already be harassed into lala-land by the time the init-callback takes place. If the event call-back is in place first, then one can filter the calls a bit I hope.
 Alternately, one could reset the keyboard at the init-callback and try again... stuff to experiment with if one likes windows driver dev.

  This approach doesn't get around my fundamental beef, though, which is that more and more computers are being made without PS2 ports, and the USB converters don't give one a virtual PS2 - they give one a HID device and typically only know how to eat 102-5 keyboards. Alternately, the PS2 controllers on some modern boards are pissy (especially the shared kb/mouse trick ones), and get grumpy if they don' see a canonical 102-5 keyboard on the port. Then yer drivers don't matter - the mainboard is claiming there _is no keyboard_.

Bah,
Back to trying to get boot-mode working in me firmware. I busted it at some point recently,
dfj

[mike]

The "E02A" that the Record key produces is fake-Shift.

Aha! I would say that makes sense, but it really doesn't ... I wouldn't be at all surprised if the committee that designed scan code set 2 always met in the afternoon after long liquid lunches

Corrected that minor point.

[JohnElliott]

Aha! I would say that makes sense, but it really doesn't ... I wouldn't be at all surprised if the committee that designed scan code set 2 always met in the afternoon after long liquid lunches

The whole thing about set 2 is it's trying to be backward-compatible with the 84-key AT keyboard, so that if you plug an enhanced keyboard into an AT the extra keys still do what they should. On the AT, PrintScreen is Shift + Keypad *: 2A 37. The enhanced keyboard then added a separate PrintScreen key, which produces the sequence E02A E037. The AT ignores the E0s and you get the right effect. A computer that recognises the E0s can distinguish between the two keys and ignore the fake Shift.

Similarly, Pause: E11D 45. On an AT, the E1s are ignored and you get 1D 45: Ctrl + NumLock.

[dfj]

The whole thing about set 2 is it's trying to be backward-compatible with the 84-key AT keyboard, so that if you plug an enhanced keyboard into an AT the extra keys still do what they should. On the AT, PrintScreen is Shift + Keypad *: 2A 37. The enhanced keyboard then added a separate PrintScreen key, which produces the sequence E02A E037. The AT ignores the E0s and you get the right effect. A computer that recognises the E0s can distinguish between the two keys and ignore the fake Shift.

Similarly, Pause: E11D 45. On an AT, the E1s are ignored and you get 1D 45: Ctrl + NumLock.

  OK - this is quite useful, I didn't know that the AT would ignore the E0 and E1 prefixes - much more makes sense now.

yup,
dfj

[xwhatsit]

There's some very good stuff in this thread. Opens up a few more eBay options should the need arise!

My Unicomp board is currently being manufactered, will be on its way soon. Cool bananas.

[xwhatsit]

Awesome, keyboard arrived, FedEx was cheap and arrived sooner than expected so happy.

What a solid board! Jesus.

Key weight actually a bit lighter than I was expecting, but getting used to it. Would be nicer if it were a shade heavier though.

Co-workers getting pissed with the noise already. Excellent.

Thank-you to the contributors to this thread -- I have all the extra keys working under Linux now. Used the atkbd.softraw=0 option to be able to see all the keys. Remapped the keys in a similar way to Mike's blog article. Why exactly is it that the setkeycode output is different from what X sees?

Anyway all is working well. Very pleased! Thanks all!

[mike]

Not sure why something adds 8 to the keycodes for X, but it seems that the first 8 keycodes are reserved for some reason :-

% DISPLAY=:0 xdpyinfo | grep key
keycode range:    minimum 8, maximum 255

Did a little searching with no results as to why this may be ... nothing immediately obvious although I didn't spend much time on it.

[xiphmont]

I'm probably going to start a new thread once I do some more thorough analysis, but since I came to this thread looking for the contents of the little U3 EEPROM and eventually just ended up dumping it myself, I thought I'd up here for now:  unicomp.bin (2 kB - downloaded 196 times.)

The arrangement is a bit odd. Addresses 0x000-0x0ff looks like a 128 entry 16 bit big endian translation table (even bytes always 0x00).  Whatever it is, it's not in scancode order and it doesn't appear to follow any natural arrangement on the physical matrix either,  so I assume the translation is being done according to some internal key position representation.  I haven't dug into it too far yet.

Hex 0x100-0x2ff appears to be a jump table in the same order as the translation table, but each entry is four bytes wide (again with even bytes 0x00).  The translated function keys are clearly visible here.

Hex 0x300-0x4ff is empty; it's coincidentally enough space for a second jump table.  I'll try that at some point.

Octal 0x500 is the start of the jump table entries.  The jump table contents that are present are obvious enough: A sequence of Set 2 make and break codes.

The keyboard identification code (0xab 0x83) is at 0x7e0, 0x7e2.  The 0xaa at 0xe4 is an OK code?

This was a board (Unicomp P/N 01U1117) with controller 03U0508 out of a BOSCOM keyboard.  It has J3 and a soldered-in CSI 93C86 EEPROM.  I pulled the EEPROM to read it, replaced it with a socket, and tested that a copy into another 93C86 worked as expected.  J3 present enables the Shift+foo and Alt+foo translations of keys like the function keys.  Removing the jumper results in getting all 122 unique scancodes.  Removing the EEPROM entirely seems to function the same as removing the jumper.  I haven't inspected carefully to see if there are any hidden differences in what the keyboard is returning on the wire when the EEPROM is gone as opposed to just jumpered.  As someone else already noted, J3 does not tie to an enable pin-- when present, it sets the EEPROM into 8 bit mode, and when absent it set the EEPROM to 16 bit mode.  I have no idea if this is some kind of cute bank-switching hack that ended up not being used, or was intended as a way of disabling the EEPROM (the controller certainly has the ability to notice the serial timing differences between the two EEPROM modes and adjust how it talks to it, even if it can't see the jumper itself).  Especially weird since it seems to mostly use even addressing, ie, it's set up so it would get consistent results with a little fiddling in either mode.

[edit: I originally had the endianness swapped due to pilot error in my hex editor, and hex addressing is probably easier to read for most of us than octal]

[dfj]

Interesting - not sure what the eeprom looks like in detail, I haven't opened it in hex yet. :p
However - these are the 122 key mode 3 scancodes arranged by the matrix of a 122 F:
Column is row, row is column since I scan by column. Notice that the table is incredibly reptitive, and could just as easily have been a few lines of logic instead of a lookup if memory was tight (as it was on early boards).

Code: [Select]

static uint8_t PROGMEM matrix122F_to_set3[] = {
0x78, 0x79, 0x7a, 0x7b, 0x7c, 0x7d, 0x7e, 0x84, // (), npenter, np3, (), np+, np9, np*, np-
0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, // np0, np., np2, np5, np6, np8, numlck, np/
0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, //
0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
0x58, 0x59, 0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f,
0x00, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, // 0x50 vanishes - is test key.
0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, // 0x48 vanishes - else roll back.
0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48,
0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f, 0x40,
0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38,
0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30,
0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28,
0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20,
0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18,
0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10,
0x01, 0x83, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, // 0x02 is replaced with 0x83.
};

enjoy
dfj

[xiphmont]

Well, the 122 M uses a 20x8 membrane matrix, and the IBM/Lexmark 112 M doesn't use the same matrix as the later Unicomps.  This Unicomp controller at very least can't read the entire original IBM membrane either; eight possible combinations all get mapped to internal offset 0xff (so that there's no way to remap them, even using the EEPROM translation, as it's effectively a bounds error).  I'm also guessing from the some of the weirdness in the mapping that Unicomp modified the membrane a few times; it's like several fixups got layered into the controller, each over the last.  Lots of out-of-order combos get mapped that aren't on the plastic membrane, but then there are the eight possible row/column combinations that don't map at all.

Anyway, a recap of what I've learned to date for certain:

The first 256 bytes are a straight-up positional translation table for remapping keys into new positions.  Each entry is a 16 bit integer in the range 0x00-0x7f.  Higher bits appear to be masked off and completely ignored.

This remapping table is applied before any kind of set translation, and as I mentioned before, it's done according to an internal key position representation that doesn't correspond to any specific scancode set (yes, I mapped it all out, will make a pic with the offsets filled in if folks are interested).

The 256 byte translation table uses the special value 0x52 to trigger a 'macro' sequence.  The controller reads the 32 bit value at 2*offset+0x100 and then uses that to index byte position lookup*2.  At that point it issues the bytes it sees as Set 2 scancodes until it hits 0x00 (the bytes as they appear in in the EEPROM are untranslated Set 2, not matrix positions/etc).  Be careful to get the address right, or you could end up dumping most of the contents of the EEPROM out the PS/2 port which will confuse an X server to no end :-)

The macro setup explains the oddity on these Unicomps where the position hidden under the numlock enter key produces no keypress; in the translation table as shipped, that happens to be position 0x52. With the EEPROM enabled, translation table position 0x52 is the value 0x52.  This triggers a macro sequence, but the jump table lookup finds all zeros as the lookup address, reads position 0x00 in the EEPROM memory, finds the byte 0x00 and issues no scancode.  It seems disabling the EEPROM does not actually stop the translation machinery, it just doesn't read it from the EEPROM, and the 0x52 is still resulting in a map-to-0x00.  It _is_ possible to remap position 0x52 with the EEPROM to produce output.

At a guess, Unicomp needed macros, needed a trigger code in the 0x00-0x7f range and chose a position in the matrix that is never actually exposed on any keyboard model despite existing on the membrane.  On my membrane, no position maps to offset 0x04 either, but perhaps it exists and is exposed on some other model.  Or something.  The whole arrangement honestly feels kind of ad-hoc and half-implemented.

Keys that are simply remapped make/break/repeat and translate into all three sets as expected.  Keys that trigger 'macros' issue the entire sequence of Set 2 scancodes immediately. There is no break, and there appears to be no way to issue a macro on break.  So, for example, you could move the combo ScrollLock/Numlock key and still get make/break/repeat/different scancodes on shift.  You could also use use the EEPROM to set up separate ScrollLock and NumLock, but they would not repeat or send break codes.

Oh, and everything's big endian.

[dfj]

Yeah - the matrix kept changing for some reason - extra pad under the keypad enter being a victim in later versions, for example. I put pause there, myself.
  Messing with the Ms is good fun, but eventually I got my hands on an F 122, and then the fun really began. :)

mrr - I have a recent uni with the eprom socketted, wonder how different it is from what you describe. :)
dfj

[xiphmont]

Yeah - the matrix kept changing for some reason - extra pad under the keypad enter being a victim in later versions, for example. I put pause there, myself.
  Messing with the Ms is good fun, but eventually I got my hands on an F 122, and then the fun really began.

mrr - I have a recent uni with the eprom socketted, wonder how different it is from what you describe.
dfj

Well... takes about 15 minutes to make a SI-Prog board that will read it :-)  Assuming you have the parts handy anyway.
I'd be curious to know what's on it.  If you mailed me the EEPROM, I'd dump it.