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