geekhack

geekhack Community => Keyboards => Topic started by: kishy on Mon, 10 August 2009, 19:02:21

Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 10 August 2009, 19:02:21
What This Thread is About:
Converting 3179 (and compatible) terminal keyboards for use with the AT or PS/2 interface
There are two "halves" to this - hardware and software.
Thread details hardware rather thoroughly.
Software is still a bit hairy - throw in some questions if you need a hand, I am happy to help.
The software 'half' consists of two things - replacing/modifying a driver and remapping keys through the Windows registry.

Progress You Can Attain By Following This Thread:
Almost 100% - there is still no typematic repeat, however.

This mod can be done by users of Linux or Windows (I can verify my own success for Win2k/XP users only, though)
Chances are good that users with Hackintosh setups will likely not succeed.

---

A proper, more direct write up can be found here (http://geekhack.org/showwiki.php?title=Island:7306).
This is the information/discussion/theorizing thread for that mod, terminal keyboards in general, and any potentially relevant "stuff".

---

Before You Continue

It is highly recommended that you have an extra, "unimportant" computer or motherboard available for testing that your wiring is correct. If the wiring is not correct, you can and possibly will permanently destroy the PS/2 keyboard interface on your computer!

Unfortunately, there will be some victims in the quest for terminal board use on PCs. Hopefully we can reduce the effect so it is only unwanted extra hardware being victimized, not people's "daily driver" computers.

You have been warned - proceed with caution.

---


Hi all, new member here...keep finding myself returning here from Google results so I took that as a sign I should register :)

I have 4 IBM Model M keyboards...2 of them are somewhat odd, being that they are 3179 terminal keyboards, both born on the same day in 1986 (the other two are 1993 1391401's).

I'm seeking to convert those 3179 terminal 'boards over to the AT and PS/2 standard, most likely using the kbdbabel project (I'm sure plenty here are familiar with it, kbdbabel.org).

[strike]You can find the details of the keyboards and the conversion on my sort of mediocre website, http://kishy.comuf.com/. Projects -> Current -> IBM 3179 Terminal Keyboard Conversion to AT, PS/2. Since I don't have much of a discussion board, I'm kind of looking for a forum to act as a meeting ground for this.[/strike]

I've seen from Google results here that people have tried the 122-key conversion before, or at least wanted to...seems like we all might make more progress if we work together, so I'm more or less calling out to YOU, 122-key owners, for your help/cooperation. Any progress I make is yours, and hopefully vise-versa.

Of course, not all 122-key units are the same electrically...if you've found info saying yours will work on a 3179 then it is functionally the same as mine.

Cheers

edit Aug 13 09
Significant success has been attained by simply swapping the cord and using registry key remaps via the free program "Key Mapper".
I do plan to make a kbdbabel adapter in the future however, and will document that process here, since it seems like directions for making one are desired by at least a couple people. >> KBDBABEL DONGLE DELAYED INDEFINITELY because alternate methods of gaining compatibility have been so successful. I hope and plan to make one but don't have the time, motivation/reason, or money at the moment.



Edit Feb 13 2010: need to make note of this somewhere
Resources which have assisted me in this project:
(in no particular order)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ch_123 on Mon, 10 August 2009, 19:06:50
I think this (http://www.seasip.info/VintagePC/ibm_1390876.html) should have what you are looking for. There's also a thread about a similar Model M terminal keyboard here. (http://geekhack.org/showthread.php?t=6126)

I wonder how similar the electronics are to the old 3178 (http://cgi.ebay.com/IBM-5640987-3178-C2-0-Keyboard-ASM_W0QQitemZ200256086957QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item2ea03163ad&_trksid=p3286.c0.m14&_trkparms=65%3A1|66%3A2|39%3A1|293%3A1|294%3A50) keyboards... probably not alot considering the 3178 had a parallel connection.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 10 August 2009, 19:34:43
Mhmm, that's (one of?) the thread(s) I found in the past. I figured that a new thread would convey perhaps..."fresh interest", I guess (just checked and see the last post was fairly recent...making me look kind of foolish). Also, that page (on diff site) is in my bookmarks...I've been unsure of what to believe though since that page says it will work, yet kbdbabel suggests a "non-dumb" hardware adapter is needed (since they provide an assembly file for the 3179 adapter).

(either way a physical adapter is needed; the question is if a dumb one can work or not. I'll be answering that for myself once I've swapped the cable for a PS/2 one)

If you're interested in photographs of the PCB in the keyboard I can take a couple...doubt my camera will show any detail on any components so I'd be happy to answer questions about "what's that say on it".

I know nothing about terminals or terminal keyboards, except that I want this monster beast on my desk...though I'd have to put the 1391401 back in the closet until my PS/2 30-286 is back up and running (anyone have a 3.5" HH RLL hard drive?). Point being I can't offer any help with the 3178 question.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ch_123 on Mon, 10 August 2009, 19:42:00
I think the kbdbabel thing is based on two things -

1) You need a physical adaptor for the connector.
2) You need some sort of software component to interpret the keyboard's scancodes correctly.

I'm not familar with the exact model of keyboard that you have, but does it have a permanently attached cable, or a removable SDL cable like the regular Model Ms?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 10 August 2009, 19:49:24
The cord is built in and connects with pins similar to jumpers (same 2x3 connector I've seen used for some PS/2 mouse headers on socket 7 motherboards), some people call them Berg connectors but a "berg connector" is normally floppy power...so idk.

One must wonder...I've read somewhere (I've read a lot and always forget where it comes from) that the original PS/2 standard in some way incorporated scancode set 3, which supposedly is used by these keyboards...then wouldn't my IBM PS/2 systems support it out of the box, using the ps/2 cable?

Difficult to know since the 30-286 is nonoperational and the 56 SX is OS/2...so I wouldn't know if it was OS/2 supporting the board or the controller on the motherboard.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ch_123 on Mon, 10 August 2009, 20:02:50
Quote from: kishy;108771
some people call them Berg connectors but a "berg connector" is normally floppy power...so idk.


As far as I know, 'Berg connector' is the name for that style of connector, not just the floppy/IDE ones specifically. Same way you have DIN connectors for a bunch of stuff other than keyboards.

Quote
One must wonder...I've read somewhere (I've read a lot and always forget where it comes from) that the original PS/2 standard in some way incorporated scancode set 3, which supposedly is used by these keyboards...then wouldn't my IBM PS/2 systems support it out of the box, using the ps/2 cable?


IBM was going to implement it, but by the time that they had intended on doing it, they lost interest for some reason or another.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 10 August 2009, 20:11:49
Just looked on Wikipedia and you're right, it's all of the pin-type connectors.

Was going to? I'm guessing then that support is nonexistent because of them losing interest.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ch_123 on Mon, 10 August 2009, 20:36:46
Well, if your keyboard is like the one on John Elliot's site, the keyboard uses the standard AT protocol, it's just that some (ok, most) are not mapped correctly.

You could take a wire from a cheap keyboard, and hook the connectors up to the Berg connector, and try and copy what John Elliot did with his. He gave instructions on the linked thread about setting up the scancodes under Linux, which I'm sure would have an equivalent under Mac OS X. As for Windows, Im not sure of the exact process, but it should be doable.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 11 August 2009, 00:22:13
Wellllll,,,,,



I am     typingggggggggggg thisssssss onmyyyyyyyyy termiiiiiiiiiiiiiiiiiinalllll keyboooooooooooooooooooarddddd onaaaaaaaa cheaaaaap usbbbbb conveeeeeeeeeeeeeeeeeeeeeeeeeeerteeeeeeeeeerrrrr.....




As     you caaaaaaaaaaaan seeeeee, therrrrrrrrrrrre arrrrrrrrrrrre     repeattttt issueeeeeeeeeessss..... Moreeeeeeee detaiiiiiiiiiiiiiils     tomrrrrrrrrrrrrrrrrrow dayyyyytimeeeee.....
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: keyb_gr on Tue, 11 August 2009, 03:13:47
Looks like another usbbb conveerteeerrr might be worth a shot.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Tue, 11 August 2009, 05:15:16
Quote from: ch_123;108779
You could take a wire from a cheap keyboard, and hook the connectors up to the Berg connector, and try and copy what John Elliot did with his. He gave instructions on the linked thread about setting up the scancodes under Linux, which I'm sure would have an equivalent under Mac OS X. As for Windows, Im not sure of the exact process, but it should be doable.


I've updated that page (http://www.seasip.info/VintagePC/ibm_1390876.html) since, with my experiences under Windows 2000. I could get it to work, but I had to use a KVM switch to do it -- switch away during boot, and come back afterwards. It's then possible to use Windows's scancode remapper to get the function and cursor keys doing what they should.

Whether it's practical for daily use rather than one-off experiments is another matter...

(Oh, and I also made a PS/2-to-DIN adaptor lead for the keyboard so I didn't have to keep borrowing the cable from my Model F).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: lowpoly on Tue, 11 August 2009, 06:59:46
If someone builds a kbdbabel converter, please document it in the mod forum.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ch_123 on Tue, 11 August 2009, 07:12:53
Quote from: JohnElliott;108833
I've updated that page (http://www.seasip.info/VintagePC/ibm_1390876.html) since, with my experiences under Windows 2000. I could get it to work, but I had to use a KVM switch to do it -- switch away during boot, and come back afterwards. It's then possible to use Windows's scancode remapper to get the function and cursor keys doing what they should.


Was Linux affected by the same problems?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Tue, 11 August 2009, 11:22:22
Quote from: ch_123;108837
Was Linux affected by the same problems?


No, it worked straight away. I think something in the initialisation sequence that Windows sends makes the keyboard sulk; using the KVM means that that sequence never reaches the keyboard.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 11 August 2009, 11:24:37
(this entire post will be typed on the keyboard in question)

keyb_gr,

Correct, it was the USB converter (not a direct adapter; a converter with circuitry inside). Interestingly though, I was getting some of the Cmd keys at the top to DO THINGS while on the USB converter (Cmd 8 was the Standby button, Cmd 7 was the Power button, Cmd 6 context menu, Cmd 4/5 Windows keys). This functionality does not exist over a true PS/2 interface, apparently.

I am now using this connected via an AT-PS/2 adapter on my desktop (one keyboard will end in an AT plug, the other in PS/2, I decided to do the AT one first) and as you can see, no repeat issues, and it's just as lovely to type on as my more traditional Model Ms...though I'd say the keys feel nicer actually.

JohnElliott, You actually don't need a KVM switch...you can unplug and replug the keyboard and it works (but it must remain plugged in during boot for BIOS to keep the PS/2 port operational). I'm planning to put a momentary SPST normally closed button somewhere on this keyboard to interrupt the +5V wire...that should be functionally the same thing as unplugging and replugging it, right?

I've made my own cable for this, without chopping up the original. I collect berg connectors from things I throw out and it turns out my efforts paid off...I found two 2x3 connectors in that ziplock bag.

I'm planning to make this my "daily driver", so to speak. I've found the commercial software PassMark KeyboardTest very handy, as it reveals all sorts of info about the keys being pressed (including the fact that they NEVER SEND AN "UP CODE"...to the computer, the keys are permanently down once pressed. I think this contributed to the repeat issue.)

I'll be writing up a complete document of the WinXP-interpreted equivalents of each key. You've done a lot of the same in a more technical manner (scancode interpretation, etc.).
(edit aug 16 09 - this would be impractical and would take ages, so I've decided not to do it. if anyone has a specific need for this information I will do it by request in this thread)

lowpoly, I am planning to make one...unfortunately the information from Alexander (seems to own/manage the project) was not 100% helpful for someone with no knowledge of microcontroller programming. I will be making one eventually, but unless I get some help with it, it could be +10 years for all I know...a local store which manufactures their own hardware has said they'll help if they can but they need to see all the details to judge if they can.

That said...I think purely software based solutions will actually work on this, for the most part. My motherboard (ECS 755-A2) doesn't seem to have any issues with this keyboard and that's good enough for me. Obviously, remapping all the oddly-mapped keys is a priority, because I forget where I found CTRL hidden...it's on some random key and if I remember right it toggles on/off...

(did all the experiments last night at 3AM, I'm surprised I remember doing them at all)

Pics:
I apologize for the bad pictures; I'm still not 100% used to this camera yet (macro mode seems to be kind of tricky)
Those joints are soldered, the hot glue is for added strengh and short prevention.
The kbdbabel adapter, if made, would go inside the keyboard case itself, and would be a permanent part of the cable, which itself is still removable.

http://img190.imageshack.us/img190/4756/1386887freshaftermod.jpg
http://img17.imageshack.us/img17/1236/1386887newplug.jpg
http://img17.imageshack.us/img17/9937/1386887newplugguts.jpg
http://img40.imageshack.us/img40/9211/1386887newcordinside.jpg
http://img44.imageshack.us/img44/2713/1386887originallayoutcl.jpg
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 11 August 2009, 12:33:08
Quote from: ripster;108883
Same thing here on the Boscom.  I can't remember exactly WHAT keys did what but I was surprised how many of the extra keys were recognized.  I'd test more but my Boscom is "temporarily indisposed".


Hmm...is the Boscom an actual terminal keyboard, or a more modern terminal emulation board?

I suspect it's a feature of my particular "Hong-Kong-2-dollar-ebay-special" USB converter which is interpreting those keys and sending them off to the computer...Windows doesn't know what the heck they do unless it's on the adapter, and when it is, it also has the repeat issue.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: dw_junon on Tue, 11 August 2009, 13:00:00
Hey, this is great to see.  Good work!  I've rambled here about just how similar these are to regular PS/2 'boards of their time, but never did get as far as trying out anything.  I would do so now, though I've searched the place for my 5.5mm nutdriver and the 5.5mm socket bit and just can't find them.  Well Brandon, they are not "totally incompatible", but you really do need to know what you are doing...

From my understanding, I would speculate that the startup issue is related to the keyboard ID (0xBF 0xBF for the 1390876 (http://www.seasip.info/VintagePC/ibm_1390876.html) and the 6110344 (http://www.seasip.info/VintagePC/ibm_6110344.html)), which differs from the genericised 0xAB 0x83 [source (http://www.computer-engineering.org/index.php?title=PS/2_Keyboard_Interface)], though I think usually only the first byte is read during initialization.

[strike]Having thought about it, there may also issues with the BAT, which I will have to look up.[/strike]  Nope, my source (http://translate.google.com/translate?prev=hp&hl=en&u=http%3A%2F%2Fwww.geocities.jp%2Fkenjin_keyboard%2F1390876.htm&sl=ja&tl=en) says "Four. BAT completion code AA is the same, then the ID will send BFBF.", in reference to a 1390876.

I must also say, it's great to see you've got hold of a 6110344 for your 5271, John; your pages are great, I don't know of any better documentation of either of those.  I must admit though I thought that BT XT 'board you had looked interesting.

Before he so brutally murdered it, ripster's Boscom was indeed a terminal emulator board.  Unicomp presently offer at least three different layouts for these, I uploaded some time ago their PDF on the PC/5250 version (http://geekhack.org/attachment.php?attachmentid=2043&d=1233585054), along with an incomplete PassMark-made chart for a Greenock built 5250 emulator 'board P/N 1397003 (http://geekhack.org/attachment.php?attachmentid=2042&d=1233585016).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Tue, 11 August 2009, 14:46:04
Quote from: dw_junon;108904
Before he so brutally murdered it, ripster's Boscom was indeed a terminal emulator board.  Unicomp presently offer at least three different layouts for these, I uploaded some time ago their PDF on the PC/5250 version (http://geekhack.org/attachment.php?attachmentid=2043&d=1233585054), along with an incomplete PassMark-made chart for a Greenock built 5250 emulator 'board P/N 1397003 (http://geekhack.org/attachment.php?attachmentid=2042&d=1233585016).

I have the same keyboard. It's a terminal emulation board, but it's meant more for an AS400 than for a mainframe. Here's the original thread: http://geekhack.org/showthread.php?t=6080&highlight=boscom
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Tue, 11 August 2009, 14:47:10
Quote from: kishy;108878
Interestingly though, I was getting some of the Cmd keys at the top to DO THINGS while on the USB converter (Cmd 8 was the Standby button, Cmd 7 was the Power button, Cmd 6 context menu, Cmd 4/5 Windows keys). This functionality does not exist over a true PS/2 interface, apparently.


That'll be because the Set 2 codes for those keys are similar to the Set 3 codes for the function keys. For example, F4 in set 3 produces 5B, and Left-Windows in set 2 produces E05B. Sounds like the converter isn't making the distinction.

Quote
JohnElliott, You actually don't need a KVM switch...you can unplug and replug the keyboard and it works (but it must remain plugged in during boot for BIOS to keep the PS/2 port operational).


Yes, but you're not supposed to hotplug PS/2 equipment :smile:

Quote
(including the fact that they NEVER SEND AN "UP CODE"...to the computer, the keys are permanently down once pressed. I think this contributed to the repeat issue.)


It may be possible to change this by sending commands to the keyboard; if you put a 102-key keyboard such as the 1391406 into mode 3, it does the same. The problem is that to do that in Windows requires writing a new keyboard filter driver; that functionality isn't exposed by the standard driver, as I understand it.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Tue, 11 August 2009, 15:17:20
Quote from: dw_junon;108904
I must also say, it's great to see you've got hold of a 6110344 for your 5271, John; your pages are great, I don't know of any better documentation of either of those.
 

Thanks.

Quote
I must admit though I thought that BT XT 'board you had looked interesting.


The microcontroller in that has a Zenith copyright sticker. The PCB is marked "12KC397A / Alps Made in Japan / Heath P/N: 163-16". It also has all the keynumbers silkscreened onto it, and a "diode" symbol by each one. As well as the LEDs in the Num Lock and Caps Lock keys, it's also got a piezo speaker that simulates keyclicks.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: InSanCen on Tue, 11 August 2009, 15:53:13
Right, I'm buying one the second I find one on a uk site.

And as a bonus, I use Linux.

Yay, honking great Terminal keyboards forever!
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ch_123 on Tue, 11 August 2009, 16:17:12
The odds of you finding one on eBay UK is quite limited. On the other hand, you can get ones for America that are still reasonably cheap.

Example (http://cgi.ebay.ie/IBM-Workstation-Terminal-101-DIN5-Keyboard-1390702-G2_W0QQitemZ160206670627QQcmdZViewItemQQptZCOMP_EN_Networking_Components?hash=item254d0fcb23&_trksid=p3286.c0.m14#ShippingPayment)

Even taking the shipping into account, it will more than likely to be cheaper getting it from abroad anyway. Also, as the thing is only $12, you're not going to have that many problems with customs.

Speaking of terminals, one of these is definitely on my to get list -

(http://www.seasip.info/VintagePC/Images/6110344.jpg)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 11 August 2009, 22:45:53
Quote from: dw_junon;108904
Hey, this is great to see.  Good work!


I can't honestly take any credit for anything except my ability to put together a keyboard cord (a very mediocre one at that). All credit should go to John Elliott for those fantastically helpful webpages. Alexander at kbdbabel should get some credit too for the inspiration (and also for the pinouts; I like to check pinouts from multiple sources before I trust them, and indeed I did find an incorrect AT kb pinout somewhere in my travels of the net. beware, an inaccurate one IS OUT THERE)

Quote from: dw_junon;108904
From my understanding, I would speculate that the startup issue is related to the keyboard ID (0xBF 0xBF for the 1390876 (http://www.seasip.info/VintagePC/ibm_1390876.html) and the 6110344 (http://www.seasip.info/VintagePC/ibm_6110344.html)), which differs from the genericised 0xAB 0x83 [source (http://www.computer-engineering.org/index.php?title=PS/2_Keyboard_Interface)], though I think usually only the first byte is read during initialization.


I'll be straight-up honest and say I don't really understand how this causes issues; it seems to me that it would work anyway (but I don't understand how these signals work, what interprets them, etc. I'd greatly appreciate a lesson in keyboard signalling from someone here). Also on "BAT", not sure what that refers to (I'd take a stab and say it's the keyboard identifier sent during initialization).

Quote from: dw_junon;108904
ripster's Boscom was indeed a terminal emulator board.


I then presume that it is USB, and possibly has a similar integrated conversion circuitry to my lame PS/2 -> USB converter, which might explain the Cmd keys functioning for (him?) as well.

Quote from: JohnElliott;108921
Sounds like the converter isn't making the distinction.


I figured as much...seemed to be a "lucky glitch" to me. At, of course, the expense of the repeating keys (which do not repeat if you immediately press another key after, but that turns into an endless cycle of neverending typing). None of those functions exist when it's going direct to a PS/2 port so it's definitely something to do with the adapter like you said.


Quote from: JohnElliott;108921
Yes, but you're not supposed to hotplug PS/2 equipment :smile:


I know, but I've done it on many computers many times with many keyboards (also with AT)...never had a problem...YET. I forget what post I put it in but I mentioned installing a momentary normally-closed button to interrupt the +5V wire...would this be an equivalent, and if so, does it reduce the risk for damage that comes with hotplugging?

Quote from: JohnElliott;108921
It may be possible to change this by sending commands to the keyboard ..... The problem is that to do that in Windows requires writing a new keyboard filter driver


That's of course about the "sticking" keys...some of them stick, some do not. It's weird. Also...about that USB converter...haha. The keys don't stick when I use it, but they do hold down for it to repeat. When it is not on the adapter, they go down and electrically stay down. When it's on the adapter, they go down, stay down for a rather precise period of time, then go up. I imagine this is the adapter compensating in some way.

It does appear that (you?) have had more success in Linux than Windows (or simply focused on Linux since that's the system you prefer). Not to say I'm "pro-closed-source" exactly, but I would be...well...much less enthusiastic about technology without my Windows. Thus, I am working almost exclusively with Windows (XP 32-bit) for this, but will have a Win98 rig at my disposal if needed, as well as OS/2 2.1 on the PS/2.


Quote from: InSanCen;108936
Right, I'm buying one the second I find one on a uk site.

And as a bonus, I use Linux.

Yay, honking great Terminal keyboards forever!


Quote from: ch_123;108940
The odds of you finding one on eBay UK is quite limited.


Although Canada Post absolutely RAPES YOU for international postage, I definitely have to recommend the eBay seller who GAVE ME MY TWO KEYBOARDS. I explained it was in educational interest as somewhat of a learning experience / summer project and he dropped them off (lives locally to me). I asked for and expected only one, the second was an absolute bonus. Note that the other two he is still selling were made on the same day as my two, they were a matching set of 4 with close but not consecutive serial numbers.

http://cgi.ebay.ca/Vintage-IBM-KEYBOARD-Clicky-Model-M-1386887-Wow1986_W0QQitemZ280340022342QQcmdZViewItemQQptZLH_DefaultDomain_2?hash=item4145914446&_trksid=p3286.c0.m14

Don't expect condition to be optimal on those; both of mine were missing a couple keycaps but I was able to piece one complete one together out of the two. I don't know if he'll clean them before shipping (mine were not, but then again I didn't pay so I wouldn't expect that). They CLEARLY saw use in a machine shop or factory and were filthy before my cleaning (the bad one didn't get a before pic, sadly, I wish I had taken one).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: microsoft windows on Wed, 12 August 2009, 08:07:46
My keyboard is missing a few keycaps too but I never really got around to finding replacements (they're Esc and I).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Specter_57 on Wed, 12 August 2009, 10:31:42
kishy ...

You may want to take a look at this thread here on GeekHack:

http://geekhack.org/showthread.php?t=5264

...there is some discussion about 122-key terminal and emulator keyboards there...and some info related to what you are interested in doing, especially toward the end of the thread.

Hopefully you'll find the info there useful and interesting as related to your project.


Spec57
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 12 August 2009, 17:42:32
ripster,

Interesting then. Did you also find that the additional functions went away when you used it directly on PS/2?

I'd venture a guess that our USB converters possibly have the same (or extremely similar) circuitry inside if so.

Specter,

Thanks for that, I've actually seen it before though. The problem is, after reading it 3 times (more or less the second half, about the 122 key boards), I still don't see many parallels to my own situation...though I am going to try the remapping software mentioned in it. Let's remember that this keyboard is "working properly" using only a different cable, nothing more. Also, PassMark KeyboardTest indicates that Windows is in fact seeing the scancodes from the non-recognized keys, so they can (in theory) be assigned to stuff.

Though, that "always down" issue could prove problematic at some point. Fortunately the modifier keys don't stick (that would be miserable).



edit:
Looking for keycaps, just checked both boards to figure out which:

Cmd14
Blank keycap
Play / Test (play on top surface, test on front)
SetUp (blue text)
Roll (down arrow) (this is the cursor down arrow)

If anyone has some or all of these keys, I'm interested.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 12 August 2009, 22:57:23
"AutoHotKey" is going to be useless for this, it doesn't appear to actually do anything with scancodes. I say this because earlier I said I'd try it.

I have, however, just discovered something possibly helpful, which appears to have been mentioned on the site before but not often...the Microsoft Keyboard Layout Creator (http://msdn.microsoft.com/en-ca/goglobal/bb964665.aspx).

Haven't even touched it yet, but if it works by scancodes which it appears to (the claims it makes suggest it does, but I can't find info saying it actually does), this could be the thing. Will report on success if any.

-edit-
Forget that, it's pretty much useless.

-edit-
OMFG I FOUND IT
"Key Mapper 1.0.0.0"
http://justkeepswimming.net/keymapper/
It lets me have it watch for keys, then I can press a key (even the currently undetected ones!) and map them to pretty much any imaginable function.

The software solution is here!
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Rajagra on Wed, 12 August 2009, 23:45:04
Quote from: kishy;109357
"AutoHotKey" is going to be useless for this, it doesn't appear to actually do anything with scancodes. I say this because earlier I said I'd try it.


Didn't it show them at all in the key history screen?

I'll download that other app anyway, just in case.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 12 August 2009, 23:59:07
From my looking into it, it sounded so promising, but then I actually looked at how you write scripts for it and you don't reference scancodes, you reference a key by its function (like, E instead of the scancode for the E key). That's a problem here because the vast majority of the keys are either not performing any function or performing ones from various other keys.

Now, to work on getting those keys to "release". It's not proving to be problematic for the alphanumeric keys, but the lock keys are bad...also when I start assigning stuff to the Cmd keys it could be a problem since they do stick.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Rajagra on Thu, 13 August 2009, 00:15:07
AHK can use virtual key or scan code references, but that Key Mapper looks good - when I loaded it up it knew I had remapped 3 keys in the registry and was using Colemak!...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 00:25:02
It does use registry entries, but does include a way to clear them out again after.

That said, if you were to export a reg file from it, then use that on a computer lacking the program, removing those remaps would involve deleting a ton of registry entries.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Rajagra on Thu, 13 August 2009, 00:38:06
I think KeyTweak would reset the registry key mappings easily.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 03:18:08
As a side note, KeyTweak is one of the few apps I tried in the quest for one which works by reading scancodes; it does not. But of course it would accomplish that purpose just fine I'm sure also (unmapping).

Hate to be a bother, but does anyone have an answer to the question about putting a normally-closed button on the +5V wire? I'm starting to get paranoid about the hotplugging thing.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: keyb_gr on Thu, 13 August 2009, 03:28:10
Quote from: kishy;109383
Hate to be a bother, but does anyone have an answer to the question about putting a normally-closed button on the +5V wire? I'm starting to get paranoid about the hotplugging thing.

Is your KVM switch purely mechanical? Otherwise it wouldn't matter.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Rajagra on Thu, 13 August 2009, 04:00:11
Quote from: kishy;109383
Hate to be a bother, but does anyone have an answer to the question about putting a normally-closed button on the +5V wire? I'm starting to get paranoid about the hotplugging thing.


It would be safer putting the switch on the data line, as that's how hot-plug connections work. It wouldn't reset the keyboard however, just stop it from communicating.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 10:03:45
Quote from: keyb_gr;109385
Is your KVM switch purely mechanical? Otherwise it wouldn't matter.


I'm not using a KVM switch; currently I am booting with the keyboard connected, then unplugging it once at the login screen and plugging it back in. In other words, it's pretty much exactly like a mechanical KVM switch.

Quote from: Rajagra;109388
It would be safer putting the switch on the data line, as that's how hot-plug connections work. It wouldn't reset the keyboard however, just stop it from communicating.


I wonder if this would have the same effect...because in theory it seems like it's safer (not violently taking away and re-applying power to it). The idea is that I'm looking for a momentary button I can hit after Windows boots to fix it not working.

I'd probably mount said button in the little pop-out section for the DIP switches on the 3270 PC's keyboard (or whatever model is the one that has DIPs, I think it's that).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 13:13:32
Attached you can find some photos regarding the layout. Because the Lock keys do not respond well to being "stuck down", I removed Scroll Lock entirely (since I've never once used it), and put Num Lock on the right Alt key (since I never use Right Alt, and the Right Alt key doesn't have the "sticking" problem). Caps Lock is fortunately one of the keys that sends an up code so it can stay where it is.

I used my "poorer condition" 1391401 (have two) to donate the keycaps. The current layout photo demonstrates how I have it mapped right now (except Cmd1-10, and the left block, I don't know what to do with those yet). I'm having few if any problems with the layout as shown in that photo.

(numpad + and Enter are for show, after photo I swapped back on the 1386887 keys because the 1391401 ones don't fit properly, but the keys in those positions are mapped to + and Enter)

Oh, and Home in the middle of the cursor keys is mapped to Enter (so I can for example navigate a folder and then hit the middle key to open something)


Update RE keyboard stops working after Windows boots:
(if anyone read what was here before I removed it, ignore it...it was wrong, I forgot something else I did first)

http://img34.imageshack.us/img34/2844/1386887removedkeycaps.jpg
http://img33.imageshack.us/img33/7894/1386887donor1391401.jpg
http://img42.imageshack.us/img42/5164/1386887currentlayout.jpg
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: dw_junon on Thu, 13 August 2009, 13:25:13
Quote from: JohnElliott;108927
The microcontroller in that has a Zenith copyright sticker. The PCB is marked "12KC397A / Alps Made in Japan / Heath P/N: 163-16". It also has all the keynumbers silkscreened onto it, and a "diode" symbol by each one. As well as the LEDs in the Num Lock and Caps Lock keys, it's also got a piezo speaker that simulates keyclicks.

Ah, so it's a OEM Zenith that was made by Alps, wouldn't have guessed that.  I love the idea of having keynumbers on the PCB, every 'board with a PCB should have them.  Added keyclicks though can be annoying or fun, depending on the individual user.


Quote from: ShawnStanford
I have the same keyboard. It's a terminal emulation board, but it's meant more for an AS400 than for a mainframe.

Hm, hence 3270 / 5250 surely?  Or have I inflamed some sort of Poughkeepsie vs Rochester thing (yikes...)?


Quote from: kishy
I can't honestly take any credit for anything except my ability to put together a keyboard cord (a very mediocre one at that). All credit should go to John Elliott for those fantastically helpful webpages. Alexander at kbdbabel should get some credit too for the inspiration (and also for the pinouts; I like to check pinouts from multiple sources before I trust them, and indeed I did find an incorrect AT kb pinout somewhere in my travels of the net. beware, an inaccurate one IS OUT THERE)

Well, you seem to have instigated something.  Fresh interest indeed!  (You woke me up, anyway...)  Certainly no denying John and Alexander's brilliant work in this area, though.


Quote from: kishy
I'll be straight-up honest and say I don't really understand how this causes issues; it seems to me that it would work anyway (but I don't understand how these signals work, what interprets them, etc. I'd greatly appreciate a lesson in keyboard signalling from someone here). Also on "BAT", not sure what that refers to (I'd take a stab and say it's the keyboard identifier sent during initialization).

I was under the impression that the ID was intended to provide a means of classifying different keyboard types, so in theory systems would complain when they come across something they know that they can't support.  As the evidence seems to be here that many modern controllers and/or software don't actually care, this may not be such an issue but could still crop up (have you tried one on a PS/2?  Perhaps I should do that myself...).

BAT is not an issue, it's the Basic Assurance Test.  I thought that the terminal keyboard might return a different value to the accepted norm, but it doesn't.

In any case, bear in mind that personally I was looking at all the potential theoretical issues rather than actually trying anything out, because I was relying on making up a 5-pin 240 DIN socket to 6-pin min DIN plug adapter but never did thanks to other events.

Probably the best grounding in how keyboards operate in relation to their host device can be found at the site I quoted: http://www.computer-engineering.org/


~~~

For interested Brits, these are pretty difficult to find over here...  Permanent eagle eyes on the 'Bay might find something, but expect a long wait.  All my terminal 'boards have come from the US, with the expection of this 1397003 emulator board from Germany.

UK postal strikes aside, USPS Priority Mail has generally been trouble free, with 'boards getting through customs without any charges and taking about a week, as opposed to anything I've had sent by UPS who never fail to add on charges with comparable delivery times due to the customs delays despite the rapidity of UPS itself.

Also, watch out for the weight difference on the capacitive bucklers ["F"] as opposed to the membrane bucklers ["M"].


~~~

Hi Spec57!  Thanks for linking to that, I never did get to doing so.

Rereading that, I see my 5.5mm nutdriver has been lost since April...  So long as the hardware store still has them, I will be able to buy a new one on Saturday and will take some pics of the 1397003 PCB :)


Quote from: kishy
Looking for keycaps

I'm not going to part with any at the moment since I haven't decided what I'm doing, but there may be some available from a 1389260 (http://www.9999hp.net/keyboard/temp/1389260-big.jpg) (also for the 3179) in future.


Quote from: kishy
the DIP switches on the 3270 PC's keyboard (or whatever model is the one that has DIPs, I think it's that).

Yes, the 6110344 has the DIPs (not to be confused with P/N 6110345 which was for the 3180 and has no DIPs).  Sandy took some great pics of the PCB of his 6110344 (see A little bit of keyboards (http://sandy55.fc2web.com/keyboard/keyboard.html)), which suggest that the DIP switches are involved with adjusting the keyboard ID:
(http://sandy55.fc2web.com/keyboard/6110344/ctrlpcb_13s.jpg) (http://sandy55.fc2web.com/keyboard/6110344/ctrlpcb_13.jpg)
(click for bigger version)

Though this image poses more questions that it answers....
There are 8 switches, the connector according to Sandy attaches directly next to the keyboard cable connector and so only allows setting of "KBDID A" 2-7 to and "KBDID B" 2 and 3.  Supposing that these are the two bytes of the keyboard ID... the typical byte has eight bits, not six.  And is there a 0?  Whether the series starts at 0 or 1, is it the least significant or most significant bit?  Note also the extra pins beyond the end, are these for another bit or some other purpose?  Do the switches set the bits or just flip existing states?  Are the PCB markings even relevant to the purpose of the switches anyway?  Also note that some of the pins seem to be tied high or low, having attempted to follow the traces.

John, as you have one of these 'boards and seem to have the ability to read reported keyboard IDs, might you be interested in playing with the DIPs?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Thu, 13 August 2009, 13:32:55
Quote from: kishy;109494
Attached you can find some photos regarding the layout.

Wow, that's... Different.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 14:31:37
Silly me, watching Pg 3 for replies when a half hour ago they happened on Pg4...

Quote from: dw_junon;109497
Well, you seem to have instigated something.  Fresh interest indeed!  (You woke me up, anyway...)  Certainly no denying John and Alexander's brilliant work in this area, though.

Well, instigated perhaps...but I'll be sticking with this 100% through to the end, including a kbdbabel adapter (unless something ridiculously impossible gets in my way of doing that, I am going to do it). I'm interested to see how much of my annoying remapping (and possibly the key up code problems) is canceled out by using one.

Quote from: dw_junon;109497
PS/2?

Right, doing that later today. Thanks for the reminder.
Mind you, it'll be a 56 SX with OS/2 2.1, but a PS/2 nonetheless.

Quote from: dw_junon;109497
5-pin 240 DIN socket to 6-pin min DIN plug adapter

Would be interested in this myself except for the relative rarity of that socket, and the fact that any kbdbabel adapter I make will be built into the keyboard case, and permanently attached to the cable I constructed myself.

Quote from: dw_junon;109497
http://www.computer-engineering.org/

Thank you, bookmarked for investigation later on.

Quote from: dw_junon;109497
5.5mm nutdriver

Quoting this as a reminder to myself to buy one; I've never been able to open my good 1391401 because of not having one. (at least not thin walled)

Note that the terminal boards of this case design do not need a thin walled one, and I use a 7/32 socket.

Quote from: dw_junon;109497
PCB stuff

I thought I'd read somewhere (possibly John's site, not to discredit Sandy but I didn't find any of those pages until the last day or two) that there were DIPs on it. I wonder, if the DIP module was put in for example my board, would it do the same function it does in the 3270 PC one? If so, it could theoretically be possible to in some way improve "out of the box compatibility" by throwing jumpers on some of those pins (but I'd need someone to guide me in exactly which to short to achieve anything useful).

Quote from: Shawn Stanford;109500
Wow, that's... Different.

I know...but it's about the best I've been able to manage, seeing as Lock keys cannot be on the keys that stick, otherwise I need to reboot after pressing one.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 15:07:09
As an FYI, here's my PCB. Best of 3 shots for the top, best of 3 shots for bottom. Can clarify anything anyone wants to know; since I have 2 of them one just sits around with the screws out anyway.

http://img34.imageshack.us/img34/9127/1386887pcbtop.jpg
http://img29.imageshack.us/img29/1883/1386887pcbbottom.jpg
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Thu, 13 August 2009, 17:01:16
Quote from: dw_junon;109497
There are 8 switches, the connector according to Sandy attaches directly next to the keyboard cable connector and so only allows setting of "KBDID A" 2-7 to and "KBDID B" 2 and 3.  Supposing that these are the two bytes of the keyboard ID... the typical byte has eight bits, not six.  And is there a 0?  Whether the series starts at 0 or 1, is it the least significant or most significant bit?  Note also the extra pins beyond the end, are these for another bit or some other purpose?  Do the switches set the bits or just flip existing states?  Are the PCB markings even relevant to the purpose of the switches anyway?  Also note that some of the pins seem to be tied high or low, having attempted to follow the traces.

John, as you have one of these 'boards and seem to have the ability to read reported keyboard IDs, might you be interested in playing with the DIPs?


OK. I'll write it up on my website, but in brief:



Note also that that area of the PCB looks identical on the 84-key Model F, down to the "KBDID A" and "KBDID B" markings, and the extra pair of pins beyond them. But on that model, the schematic (http://www.kbdbabel.org/schematic/kbdbabel_doc_ibmat_kbd.pdf) at kbdbabel.org shows that pins B5, B6 and B7 are now used to drive the LED panel.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: dw_junon on Thu, 13 August 2009, 17:03:19
Quote from: kishy;109519
I'm interested to see how much of my annoying remapping (and possibly the key up code problems) is canceled out by using one.

Your desired mapping could be incorporated into the code for your kbdbabel µcontroller, so that could be solved forever, at least until you want to change your layout.  As for the lack of scancodes on key up, I don't know how the kbdbabel code deals with this.  Checking the comments in the code, I can see that the typematic repeat rate command is not implemented, however this doesn't really address the matter.


Quote from: kishy
a 56 SX with OS/2 2.1

What's wrong with a Model 56?  I guess they're more common than some, but hey, they're MCA.  It's not like it was a 30 or a E.

Quote from: kishy

Note that the terminal boards of this case design do not need a thin walled one, and I use a 7/32 socket.

Indeed, though I couldn't even find one of those, just my "integer" metric sockets, and our half-decent socket set that just doesn't quite go down to that size...  ISTR that 5.5mm is the "proper" size, though indeed 7/32" is just fine.  Cheap sockets will probably vary a bit anyway... as you point out, it's how thick the thing is that is the usual showstopper.

Note also that the later design (http://www.9999hp.net/keyboard/temp/1397003.jpg) does have the same recesses as a '401 and so will need a deep/thin one or a nutdriver.


Quote from: kishy
I thought I'd read somewhere (possibly John's site, not to discredit Sandy but I didn't find any of those pages until the last day or two) that there were DIPs on it.

Sandy is one of my heroes...
Quote from: kishy
I wonder, if the DIP module was put in for example my board, would it do the same function it does in the 3270 PC one?

"Module" is a bit of a glorification, that could be read to imply an extra PCB.  AFAIK it's just a bank of 8 DIP switches, one side of which is shorted together to a common input, the other side providing eight outputs.

Here is the link to Sandy's 6113044 page (http://sandy55.fc2web.com/keyboard/model_f_6110344.html) which I should have posted before.

As to what they might do, it's very hard to say.  It might help if we knew what they did on the 6113044, if anything...

Quote from: kishy
If so, it could theoretically be possible to in some way improve "out of the box compatibility" by throwing jumpers on some of those pins (but I'd need someone to guide me in exactly which to short to achieve anything useful).

Exactly, I was thinking along the same lines before.  Too hard to say what might happen, but if anything would I expect jumpers would do the trick.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 17:21:56
Well, in general, my current issue is the key-up thing. I tried to play a game (Garry's Mod) with it and completely failed...just kept walking everywhere after I pressed W, because the game was looking for the up code and never got it. Also one of my mapped keys (ESC, mapped to Cmd13's normal spot) didn't register so getting out of the game was kind of interesting.

Priority 1 in my mind at this time is getting the key-up thing resolved.
As a side note, the second keyboard will get its PS/2 cord either tonight or tomorrow, hopefully. Like this one, it will be going to a berg connector so it will be a completely reversible "mod".

Model 56, well, IDK. Something about 386s, I just don't like them. 286, sure, 486, why not...but a 386, despite having been a relatively significant chip, historically...just bores me. This one does have a 486SLC card though, so maybe I should call it a 486...a half-assed one, but still a 486.

First time I saw that Model F page I missed the fact that the actual back is entirely metal...odd. See, the plastic casing for mine has a removable (and replaceable, it doesn't break off) panel which is in the general area of the large berg connector. Difficult to say for sure but it looks like the same little "DIP module" (that is, the switch bank and the small plastic bracket) would fit perfectly, but then that's just eyeballing it. I imagine the switches short top to bottom pins (hopefully) so jumpers would be the way to do it, aside from obtaining a DIP block and wiring that mess.

I believe John said something earlier in the thread about how the key-up thing could potentially be solved by sending something to the keyboard, but that the Windows keyboard driver(s) didn't allow it. John, did you have any success with that in Linux? If it could successfully be accomplished "at all" then that means it could most likely be done in Windows.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Thu, 13 August 2009, 17:32:57
I've now checked my 1390876 as well. The B2-B7 headers correspond to the low 6 bits of the second ID byte in the same way, and I'm sure if my board had headers on A2-A7 they'd affect the first byte too.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Thu, 13 August 2009, 17:43:53
Quote from: kishy;109581
I believe John said something earlier in the thread about how the key-up thing could potentially be solved by sending something to the keyboard, but that the Windows keyboard driver(s) didn't allow it. John, did you have any success with that in Linux? If it could successfully be accomplished "at all" then that means it could most likely be done in Windows.


Send command 0xF8 to the keyboard, and all keys then send make and break codes. I've only tried that under DOS, which is what my homebrew keyboard tester program runs under. Works on both the 6110344 and the 1390876.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 17:51:28
Hmm...I can't see any logical reason why it wouldn't work in Windows (the act of sending the command, that is, not your program).

I don't have a clue, however, how to "send command ____ to the keyboard". Is it possible to do this via a DOS command, or perhaps via DEBUG? Or is there something about your program which I'd be missing (sorry, not very knowledgeable in the software -> hardware interaction area).

Unfortunately, the software I'm using to view if the keys have come back up or not is Windows-dependent, and on the same machine I cannot run true DOS (and I doubt XP's command prompt would do the trick).

I have a system, if you can call it that, set up on a tray table...motherboard, PSU, floppy drive. Has a Windows ME boot floppy in the drive, I boot it up and run EDIT to work with the keyboard on it. In that environment, I have no means to see if the keys actually did send their "break code" though.



edit: you've specified:
Quote
Send command 0xF8 to the keyboard, and all keys then send make and break codes.

"ALL" keys send make and break codes? Wouldn't this then result in every key on the board first performing its function, then "turning off"?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Thu, 13 August 2009, 18:19:41
Quote from: kishy;109585
I don't have a clue, however, how to "send command ____ to the keyboard".


In principle, all you do is output 0xF8 to port 0x60, and wait for the keyboard to return 0xFA. In practice you have to do irritating housekeeping tasks to make sure the keyboard doesn't try to send a keystroke to you at the wrong time. Here's how I'd do it in my DOS program:

Code: [Select]

di();
waitempty();
kwait();
outp(0x64, 0xAD);   /* disable keyboard */
kwait();
outp(0x60, 0xF8);   /* send command */
kwait();
result = inp(0x60);  /* result, should be 0xFA */
kwait();
outp(0x64, 0xAE);   /* enable keyboard */
ei();

where kwait() and waitempty() are helper functions in assembly:
Code: [Select]

_kwait:
        push    cx
        push    ax
        xor     cx, cx
kw1:    in      al, 0x64
        test    al, 2
        loopnz  kw1
        pop     ax
        pop     cx
        retf

_waitempty:
        push    cx
        push    ax
        xor     cx, cx
kw2:    in      al, 0x64
        test    al, 1
        loopnz  kw2
        pop     ax
        pop     cx
        retf



Under an NT-based Windows system, with I/O privileges locked down, it gets harder. You have to ask the keyboard driver to do it for you, which is done with an IOCTL_INTERNAL_I8042_KEYBOARD_WRITE_BUFFER request. The problem is that (as I understand it; I haven't tried) that request can't be made by normal programs, so you need to write a so-called 'filter driver' to make the request... we could really do with someone who's got experience with kernel-mode Windows programming at this point.

Quote

edit: you've specified:

"ALL" keys send make and break codes? Wouldn't this then result in every key on the board first performing its function, then "turning off"?


It would make each key send a code when pressed, and another one when released -- just as 102-key keyboards do when not using scancode set 3.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 18:29:01
Ohhhkay gotcha then on the make/break thing...you're saying if you send the command to the keyboard, it will then send both make and break codes for keys from that point on. That makes more sense than my initial interpretation (that you'd need to send this command after each keystroke).

I definitely appreciate the time and presumably research that went into that post, but I don't understand a) how to actually send the command(s) or b) how to verify that it is working (despite never sending a break code, they do not repeat if connected via the AT interface, so I wouldn't see a difference in a DOS environment).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 13 August 2009, 19:17:20
Regarding 1386887 usage on a PS/2 56SX:

Code 301 on POST (keyboard not responding or stuck key)
So I plugged in the 1391401, booted into OS/2 then fired up Note Pad.

Typed a sentence "This sentence is being typed on a 1993 1391401."

Then, I swapped out the keyboard for the terminal board, and proceeded to type "This sentence is being typed on a 1986 1386887."

The problem was that the sentence came out looking something similar to "#R@#$T$^^*&^%*$&^&^%::::"'';;;';,..,,<>$#%", at which point it crashed (see blurry attachment).

This suggests to me that PS/2s might not support set 3 at all (perhaps designed not to), and that we just happen to be lucky that modern equipment does by some odd fluke.

http://img40.imageshack.us/img40/5034/1386887onps256sx.jpg
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: quadibloc on Thu, 13 August 2009, 21:50:46
Quote from: kishy;109609
This suggests to me that PS/2s might not support set 3 at all (perhaps designed not to),


That sounds really weird to me, because my understanding is that the first PS/2 computers actually came with keyboards that only handled Scan Code Set 3, and it was only later that IBM made 101-key keyboards that were compatible with their older computers like the AT after intense popular demand.

So really old computers would not support Scan Code Set 3. Also, some cheaper off-brand keyboards don't handle Scan Code Set 3 properly, which causes problems in Linux, because it tries to use Scan Code Set 3 by default (because it works more simply with a 101-key keyboard, without extra codes because the keyboard is pretending to be an 84-key AT keyboard).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Fri, 14 August 2009, 02:06:34
Quote from: kishy;109609
This suggests to me that PS/2s might not support set 3 at all (perhaps designed not to), and that we just happen to be lucky that modern equipment does by some odd fluke.


The thing is that the set 2 and set 3 codes are the same for all the alphanumeric keys. So unless OS/2 had switched the previous keyboard into set 1, I don't think that could account for the problems you were experiencing.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: quadibloc on Fri, 14 August 2009, 06:00:39
Quote from: JohnElliott;109673
The thing is that the set 2 and set 3 codes are the same for all the alphanumeric keys.


Surprisingly enough, on a 122-key keyboard, they're the same for all keys. But that doesn't necessarily help, because if a computer doesn't recognize Scan Code Set 3, it isn't going to attempt to understand the codes - it would just give up on the basis that the attempt to get the keyboard to use a set it could recognize failed. The problem would not be giving the keyboard more codes, it would be getting it to acknowledge a request to change to Set 2.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Fri, 14 August 2009, 09:04:22
Quote from: quadibloc;109684
Surprisingly enough, on a 122-key keyboard, they're the same for all keys. But that doesn't necessarily help, because if a computer doesn't recognize Scan Code Set 3, it isn't going to attempt to understand the codes - it would just give up on the basis that the attempt to get the keyboard to use a set it could recognize failed. The problem would not be giving the keyboard more codes, it would be getting it to acknowledge a request to change to Set 2.


That wouldn't explain the phenomenon as reported (disconnect a working 102-key keyboard, connect a 122-key keyboard, keystrokes produce gibberish). The computer would have had to detect that the keyboard had been hotplugged, tried to reinitialise the keyboard and select set 2, failed, and decided to produce random characters in a fit of pique (rather than disabling the keyboard or reporting an error).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: o2dazone on Fri, 14 August 2009, 09:10:36
Just an FYI, on Windows based machines, I use KeyTweak and use ctrl+alt+del to login (on a 64 bit system). Because the scancodes were done via registry, I have no problems (for example, on a normal layout I rebound capslock to ctrl, logging in would require I hit capslock+alt+delete). I know you're referring to Key Mapper, but I thought I would share my experience :)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 14 August 2009, 11:19:46
o2dazone, I'm more or less just preventing POSSIBLE issues (and sort of saying "you've been warned if it doesn't work")...the map I've provided is supposed to be applied during login so at the login screen it shouldn't be in effect (meaning your hopefully-also-connected USB keyboard will still work).

The pre-remap key combo for CTRL ALT DEL on this board is CapsLock + LeftCTRL + Numpad decimal. Though, since numpad decimal is one of the keys that does not send a break code, this might be problematic for some people (it isn't for me, but could be depending on variables that I don't even know about).


JohnElliott and quadibloc
The gibberish I typed was, just to be clear, not in any way accurate (so don't try to follow a pattern). It appeared on the screen for a very short time before it crashed so I couldn't see in detail what anything was. There were however several accented characters.

I don't know the technical details of...well...almost anything we're dealing with here. I guess I'll leave it to you guys to figure out exactly what it means when I discover something, lol.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: dw_junon on Fri, 14 August 2009, 16:55:18
Quote from: JohnElliott;109572
OK. I'll write it up on my website, but in brief:

  • Switches 1-6 control bits 5-0 of the first keyboard ID byte (bits 7-6 are always 1,0). So in their default position where they're all open, the first ID byte is 10111111 (0xBF). If you close one or more, the corresponding bit goes to 0. Close switch 1 and you get an ID of 0x9F 0xBF, and so on.
  • Similarly, Switches 7 and 8 control bits 5 and 4 of the second keyboard ID byte.
  • And therefore I'd guess that, with 12 sets of pins and 8 switches, the remaining four sets of pins are used to set the low 4 bits of the second ID byte.
Quote from: JohnElliott
I've now checked my 1390876 as well. The B2-B7 headers correspond to the low 6 bits of the second ID byte in the same way, and I'm sure if my board had headers on A2-A7 they'd affect the first byte too.

I had to leave abruptly last night, hence my previous silence.

Thank you so much, I've been wondering about this for some time.  So it should therefore be possible to set the "normal" ID of 0xAB 0x83 [10101011 10000011] with the following settings:
Code: [Select]
KBD ID A 2 - NO JUMPER [SW 1 OFF]
KBD ID A 3 - JUMPER    [SW 2 ON ]
KBD ID A 4 - NO JUMPER [SW 3 OFF]
KBD ID A 5 - JUMPER    [SW 4 ON ]
KBD ID A 6 - NO JUMPER [SW 5 OFF]
KBD ID A 7 - NO JUMPER [SW 6 OFF]

KBD ID B 2 - JUMPER    [SW 7 ON ]
KBD ID B 3 - JUMPER    [SW 8 ON ]
KBD ID B 4 - JUMPER
KBD ID B 5 - JUMPER
KBD ID B 6 - NO JUMPER
KBD ID B 7 - NO JUMPER

I will test various behaviours of the 1389260 and the 1387033 (any regulars with good memory and eagle eyes, yes it is that one) with this configuration versus without (I will have to borrow the cable from my AT as John E. did).

Quote from: JohnElliott
Note also that that area of the PCB looks identical on the 84-key Model F, down to the "KBDID A" and "KBDID B" markings, and the extra pair of pins beyond them. But on that model, the schematic (http://www.kbdbabel.org/schematic/kbdbabel_doc_ibmat_kbd.pdf) at kbdbabel.org shows that pins B5, B6 and B7 are now used to drive the LED panel.
This is an interesting detail, I do recall seeing that on the PCB of my 6450225 but never considered this comparison.  I will have a play with that too since I will have to open the case.


~~~


For the record, I don't have low-level Windows programming experience.


~~~

Quote from: kishy
Regarding 1386887 usage on a PS/2 56SX:

Code 301 on POST (keyboard not responding or stuck key)
I would consider blaming the 301 on the keyboard ID the 1386887 reports, particularly if both it and the Model 56 are otherwise working well.  See above...


Quote from: kishy
Then, I swapped out the keyboard for the terminal board, and proceeded to type "This sentence is being typed on a 1986 1386887."

The problem was that the sentence came out looking something similar to "#R@#$T$^^*&^%*$&^&^%::::"'';;;';,..,,<>$#%", at which point it crashed (see blurry attachment).

This suggests to me that PS/2s might not support set 3 at all (perhaps designed not to), and that we just happen to be lucky that modern equipment does by some odd fluke.
I'm not sure that that's a logical conclusion.  From the evidence I don't see how we can tell for sure whether the gibberish is a hardware or software problem, never mind exactly what is failing, complaining or just plain going mad.  A comparison using a basic DOS boot disk with added EDIT.COM might help.  This said, I'm not sure I would recommend hotplugging the keyboard on a real PS/2.

There is also the history which suggests otherwise.  As we have been discussing, set 3 was already in use in terminal products prior to the PS/2 launch in '87; according to the "IBM 7531/7532 Industrial Computer Technical Reference System Unit", first edition July 1985, set 3 was supported by their 101 and 102 key 'boards, the design of which was then used on the 5170 AT proper, and then became the standard for the PS/2.  Not to say that there were definitely no changes; at some point the additional mode providing XT support was dropped from the 101/102s, whether this was with the introduction of the '401 or later is unclear.


Quote from: quadibloc
That sounds really weird to me, because my understanding is that the first PS/2 computers actually came with keyboards that only handled Scan Code Set 3, and it was only later that IBM made 101-key keyboards that were compatible with their older computers like the AT after intense popular demand.
John Savard, wow, is that really you?

That's particularly interesting, I've never seen anything to suggest this with IBM 'boards.  I do however recall speaking someone in possession of two apparently non-working Compaq Enhanced II 'boards, which I believe were for the second generation of Compaq Deskpros; this may well have been the first machines to clone the PS/2 keyboard/mouse interface on-board (though they use the ISA bus and Compaq proprietary memory expansion).  If I remember correctly, when connected to a modern PC (possibly via USB) the LEDs would light but they would not function at all: that they used only scan code set 3 was my suggested explanation.  Unfortunately, I never did get my hands on one to test with my Deskpro 386s...


~~~

Reading through the above mentioned 7531/7532 tech ref's keyboard information, I have noticed something that may be significant: using the system-end command Select Alternate Scan Codes [0xF0] it is apparently "not possible to switch to set 3 from another set".  It may be possible for this event to occur when the 1386887 is hotplugged (as it likely supports only set 3) if set 2 was previously in use.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 14 August 2009, 18:37:01
dw_junon

I will try those jumper settings; now that I know both keyboards are operational it wouldn't be the complete end of the world if something were to go wrong (but I doubt it would, since shorting those pins is the intention behind them existing to begin with). I don't imagine I would notice any difference on my Windows XP machine, but it is possible the PS/2 will detect it properly (with the right ID) so that'd be on the list of tests.

Logical conclusion it may not be, but like I said, it's how **I** took it...let's do please remember that I know nothing about this stuff except that which I'm learning via this thread. BTW I have now read at least one section on the link from a few posts back about keyboard signalling...while very helpful it doesn't correct my core lack of understanding of how the data actually gets sent and all that.

Will get back to you shortly about results with jumpers.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Fri, 14 August 2009, 18:43:57
Making the keyboard return a different ID may not help, if the PS/2 BIOS is (eg) testing the ability to select scancode sets...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 14 August 2009, 18:49:55
Well, PS/2 POSTed just fine:)

Problem is, well, it's still typing gibberish.

XP desktop: no noticeable differences whatsoever, but it certainly doesn't hurt to be using "the correct" ID for the job so I'll put the jumpers on the second one as well.

http://img190.imageshack.us/img190/8563/1386887ps2gibberish.jpg

retrospective edit:
the find menu is open because a key combo opened it, for the record
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Sat, 15 August 2009, 05:28:43
Quote from: kishy;109794
Problem is, well, it's still typing gibberish.


Is there any consistent pattern between what you type and what appears? For example, if you press Q does it always come out as (say) Y?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: quadibloc on Sat, 15 August 2009, 06:24:25
Quote from: JohnElliott;109705
That wouldn't explain the phenomenon as reported


You're quite right. I should have reviewed the earlier posts more carefully.

However, it should be noted that hot-swapping a keyboard with a PS/2 connector is generally viewed as a good way to fry motherboards - and so it is very much not recommended.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 15 August 2009, 18:55:52
Quote from: JohnElliott;109840
Is there any consistent pattern between what you type and what appears? For example, if you press Q does it always come out as (say) Y?

There is a pattern, but the machine still hangs after hitting certain keys...determining a key-by-key map would be very difficult and time consuming. That said, I will do it if you think it will help in some way.

Quote from: quadibloc;109845
However, it should be noted that hot-swapping a keyboard with a PS/2 connector is generally viewed as a good way to fry motherboards - and so it is very much not recommended.

I'm very well aware of this, but until this "not working after boot" issue is resolved, it is impossible to use it otherwise.

I don't want to do anything with a switch/button like I've previously suggested until someone gives their opinion of interrupting the DATA line instead of the 5V line, pros and cons of either, etc. If it's functionally the same as hotplugging and still carries the risk of damage I see no point in modifying the keyboard case to accommodate it (yet).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Sat, 15 August 2009, 20:22:24
Quote from: kishy;109959
There is a pattern, but the machine still hangs after hitting certain keys...determining a key-by-key map would be very difficult and time consuming. That said, I will do it if you think it will help in some way.


It's mainly for curiosity's sake. My example, Q -> Y, is what you might get if the computer was expecting Set 1 codes and receiving Set 2 or Set 3.

I did manage to get Windows 2000 working with the 1390876 today, with no KVM switch. It involved building a custom version of the keyboard driver. Not ready for prime time yet, but who knows?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 15 August 2009, 20:26:37
I'd be very interested in trying that driver (XP and 2k use identical driver models as I understand it).

Would you be willing to let me try it?

(as a result of your, in my opinion, HUGE success from that post I will not be attempting anything with any kind of button or switch because my goal has always been for this to be completely undoable and drilling a hole in the keyboard is certainly not undoable...I'll wait to see my own successes with your driver, assuming you will let me try it)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Sun, 16 August 2009, 06:17:09
PM sent.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: quadibloc on Sun, 16 August 2009, 12:48:49
I would just like to note that my 122-key keyboard, which worked with older versions of Windows, does work normally with Windows XP (I'm typing with it now), even though it is no longer possible, apparently, to replace the 101/102-key keyboard driver with a 122-key keyboard driver for it. So the problem is indeed with the conversion, and isn't a fundamental incompatibility between a normal 122-key keyboard and Windows XP.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 16 August 2009, 14:18:03
I've been using John's modified driver for a couple hours now and...well...he might be a little mad about me releasing this info, but IT IS PERFECT.

(edit: actually, it's not perfect, since making the post I've learned from John exactly what the remaining issues are)

John, if you want this edited out for now, I will...just say the word.

(I suspect John knows about a bug I haven't discovered yet which is why he doesn't want to put it out there)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: dw_junon on Sun, 16 August 2009, 17:23:29
Quote from: JohnElliott
Making the keyboard return a different ID may not help, if the PS/2 BIOS is (eg) testing the ability to select scancode sets...

Indeed not, it could be considered analogous to be lying only to be found out (and in worse trouble) later.  This said, it has since occurred that it might be worth examining the effects of using of using IDs as used by compatible 122 keyboards such as 0xAB 0x85 and 0xAB 0x86 [source (http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-7.html#ss7.3)]; this may be helpful PS/2-wise since the Host Connected 'boards were supported products, though obviously there may be sufficient differences in the keyboards that this is in no way beneficial.


Quote from: JohnElliott
I did manage to get Windows 2000 working with the 1390876 today, with no KVM switch. It involved building a custom version of the keyboard driver. Not ready for prime time yet, but who knows?

That's fantastic.  Perhaps I am naive, but I'd suspect that this would ultimately be appreciated very much more widely than this forum topic.  Great news, thank you for your efforts!

Amusingly perhaps, I don't actually possess a machine running a Win NT family OS at the moment...


~~~

Here is an interesting piece from the Ardent Tool (http://www.ibmmuseum.com/OhlandL/keyboard/Keyboard.html#Socket_Sizes) from which speculative conclusions could be drawn regarding scan code set 3:
Quote
Incompatible IBM Keyboard
From Charles Lasitter
   Part 84G2524 / FRU 84G2529, mfg date 09/28/99, vendor: Unicomp; IBM has managed to do the unthinkable.  It now makes PS/2 input devices that can't stand the sight of real PS/2 equipment.
   Specifically, keyboards made by this vendor for IBM work great in crAptivas, but don't like Model 77s, 95s, and so on.  Generates the "301" keyboard error right away in the Model 95 computers, and generates nonsense keyboard output attached to a Model 77.

Original source (http://groups.google.com/group/comp.sys.ibm.ps2.hardware/browse_thread/thread/e860c3879e5c6bcd/b93e10b1c0da1cce) alas offers no further detail.


~~~


My testing has been somewhat limited due to some sort of protocol that requires the house not to be covered with bits of keyboard when visitors are present.

Here follows the results of the limited testing, which involved an elderly Dell Dimension XPS T-xxx, with a Dell version of the Intel 440BX chipset IIRC.  The machine was set up with a choice of xubuntu and Win 98SE selectable via grub, though the 98SE setup CD-ROM was used for the DOS testing.

Code: [Select]
P/N KBD ID Interface grub xubuntu login DOS 7
1387033 0xBF 0xBF * PS/2 ok?ą did not function˛ goodł
1387033 0xAB 0x8F § PS/2 ok?ą did not function˛ goodł
1387033 0xAB 0x8F § USB / PS/2 ¤ ok?ą did not function˛ goodł
1389260 0xAB 0x83 PS/2 good key up issue good
1389260 0xAB 0x83 USB / PS/2 ¤ good key up issue good
1389260 0xBF 0xBF PS/2 good key up issue good


* All DIP switches were off; ID is supposed from convention and in no way
tested or confirmed.

§ DIP switches were set as described [url=http://geekhack.org/showpost.php?p=109782&postcount=67]here[/url].  The remaining two pins were not
jumpered as they were very difficult to reach.

¤ Neither terminal keyboard would function via USB when the computer's
QuietKey 'board was also connected via PS/2, though the PS/2 connected
'board would function.  USB results therefore are for the terminal 'board
being the sole keyboard attached.

ą Could not reach the grub command prompt due to lack of escape key for
complete character testing, however single keys command for the grub menu
functioned successfully.

˛ No response at all from any keypresses.

ł Ctrl, Alt and Caps Lock keys did not seem to function, though this may
be due only to layout / scan code differences.  Alphanumeric, shift and
function keys functioned as US 84 key AT.


The key up issue is the infinite repeat of characters from keystrokes as a result of lack of key up scan codes as previously described in this topic.

Testing on PS/2 models 70 and 95 will follow, I hope.  Testing on the 7531 AT is possible too.  All perfectly possible with sufficient spare time and moving of stuff.

I took some pics, mostly useless but at the very least serve as a personal reminder.
A source of jumpers... (http://www.9999hp.net/keyboard/IBM/terminal-testing/00_jumper-source.jpg)
Cable detached from the 6540225 (http://www.9999hp.net/keyboard/IBM/terminal-testing/01_at-cable-removed.jpg)
Opening the 1389260 (http://www.9999hp.net/keyboard/IBM/terminal-testing/02_1389260inside.jpg)
The AT's cable isn't going to fit through the cable hole on the 1389260... (http://www.9999hp.net/keyboard/IBM/terminal-testing/03_1389260-cable-clearance.jpg)
...so I ran it through the blanked hole for the DIP switches. (http://www.9999hp.net/keyboard/IBM/terminal-testing/04_1389260_cable_exit.jpg)
1389260 okay at grub prompt... (http://www.9999hp.net/keyboard/IBM/terminal-testing/05_1389260-grub.jpg)
..and in DOS EDIT.COM. (http://www.9999hp.net/keyboard/IBM/terminal-testing/06_1389260-edit.jpg)
The chassis of the 1387033 is riveted... (http://www.9999hp.net/keyboard/IBM/terminal-testing/09_1387033-rivet.jpg)
...check the other side to be sure... (http://www.9999hp.net/keyboard/IBM/terminal-testing/10_1387033-rivet2.jpg)
...so the PCB is effectively stuck, making the Berg strip difficult to reach. (http://www.9999hp.net/keyboard/IBM/terminal-testing/11_1387033-inaccessible-pcb.jpg)
1387033 in EDIT.COM (http://www.9999hp.net/keyboard/IBM/terminal-testing/12_1387033-edit.jpg)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 16 August 2009, 17:55:31
I would test with Win95 on my 56 SX if it weren't for the following complications:
-no easily accessible SCSI hard drive
-PITA to swap hard drives on a PS/2
-PITA to install Win95 from floppies
That would either solidify the "machine does not support Set 3" thing, or alternatively it could reveal that it is simply OS/2 which doesn't support it (not definitively, but close enough for our purposes I'd say).

Without any remapping, I found the following (going from memory, I didn't end up writing these down):
-caps lock functions as CTRL
-Left CTRL (aka Reset) functions as Left ALT
-Right CTRL (aka Enter) functions as Caps Lock
-Num Lock (aka no label) functions as Esc
-Numpad / (aka no label) functions as Num Lock
-Numpad . is the only delete key on the board
-Cursor can only be moved with numpad cursor keys;
    (and of course, left arrow is same as yours, backslash)

Seeing as yours is the, uh, "space saver" (if ever there was one) you obviously can't check out the numpad-related stuff, but I'd expect it to be the same (though again I don't know a whole lot in this area).

Yay, someone still has a VLB card out there.



Edit: hey John, I noticed something...you identify your keyboard(s) as being for a 3197, whereas mine are 3179. Is that a typo of yours or do 3197 and 3179 both use the same keyboard type?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Sun, 16 August 2009, 19:10:30
Quote from: kishy;110116
hey John, I noticed something...you identify your keyboard(s) as being for a 3197, whereas mine are 3179. Is that a typo of yours or do 3197 and 3179 both use the same keyboard type?


The page (http://www.geocities.jp/kenjin_keyboard/1390876.htm) I got the pinout from says 3197. Google Images appears to think that both types of terminal exist, and look quite similar. At the moment, I'm inclined to believe that a lot of IBM's terminal keyboards are interchangeable at the electrical level, with the differences being restricted to things like the keyboard ID and keycaps.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: dw_junon on Sun, 16 August 2009, 19:10:59
Quote from: kishy;110116
I would test with Win95 on my 56 SX if it weren't for the following complications:
-no easily accessible SCSI hard drive
-PITA to swap hard drives on a PS/2
-PITA to install Win95 from floppies
That would either solidify the "machine does not support Set 3" thing, or alternatively it could reveal that it is simply OS/2 which doesn't support it (not definitively, but close enough for our purposes I'd say).

What about a DOS ("Windows 95") floppy?  That said, those aren't so trivial to make these days.

Another possible scan code set 3 test might be an SGI, IIRC.  Does any one reading this have any SGI boxes?


Quote from: kishy
Without any remapping, I found the following (going from memory, I didn't end up writing these down):
-caps lock functions as CTRL
-Left CTRL (aka Reset) functions as Left ALT
-Right CTRL (aka Enter) functions as Caps Lock
-Num Lock (aka no label) functions as Esc
-Numpad / (aka no label) functions as Num Lock
-Numpad . is the only delete key on the board
-Cursor can only be moved with numpad cursor keys;
    (and of course, left arrow is same as yours, backslash)

Yeah, as I think has been mentioned, this mostly follows the layout of the 84 key AT keyboard (http://www.9999hp.net/keyboard/temp/6540225-big.jpg) (I'm afraid my picture is of the UK variant, though it is similar enough that your list is consistent).


Quote from: kishy
Seeing as yours is the, uh, "space saver" (if ever there was one) you obviously can't check out the numpad-related stuff, but I'd expect it to be the same (though again I don't know a whole lot in this area).

I should have better clarified what I was using.  The "space saver" is the 104 key, part number 1387033 (http://www.9999hp.net/keyboard/temp/1387033.jpg), which is for the 3290 terminal.  The other keyboard I tested is the 122 key 1389260 (http://www.9999hp.net/keyboard/temp/1389260.jpg), for the 3179 terminal (though I believe it was used with the compatible 3180).  For what it's worth, there is a list of what I have available to test with here (http://www.9999hp.net/keyboard/temp/).

Indeed, not having the number pad on the 1387033 was very limiting in this case, however as I mentioned, the behaviour of other modifier keys was not consistent with either your, John E's, or my 122 key 'boards or consequently the 84 key AT layout.


Quote from: kishy
Yay, someone still has a VLB card out there.

I was kindly offered that by a chap who sold me some 5Ľ" floppies.  I hope to be able to put it to its intended use some day...


Quote from: kishy
Edit: hey John, I noticed something...you identify your keyboard(s) as being for a 3197, whereas mine are 3179. Is that a typo of yours or do 3197 and 3179 both use the same keyboard type?

The 3179 and 3197 are both real IBM system type numbers, I think this is correct.  Certainly confusing numbering though.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: dw_junon on Sun, 16 August 2009, 19:20:36
Quote from: JohnElliott;110122
At the moment, I'm inclined to believe that a lot of IBM's terminal keyboards are interchangeable at the electrical level, with the differences being restricted to things like the keyboard ID and keycaps.

I have to agree.  The extensive list of types for the relevant kbdbabel (http://www.kbdbabel.org/) adapter ["IBM 3151-3153/3179/318x/319x/34xx ---> PS2 (http://kbdbabel.cvs.sourceforge.net/viewvc/kbdbabel/kbdbabel/kbdbabel-ibm3151/)"] agrees more emphatically, though.

On reflection it seems like IBM was benefitting from standardised keyboards (in production) though the customers were not so much.

I will have to make time to go through the announcement letters (http://www.ibm.com/news/usalet/) one by one and make a record of exactly what exists (hopefully sooner rather than later while they still keep this old information on-line).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 16 August 2009, 19:36:05
Quote from: JohnElliott;110122
The page (http://www.geocities.jp/kenjin_keyboard/1390876.htm) I got the pinout from says 3197. Google Images appears to think that both types of terminal exist, and look quite similar. At the moment, I'm inclined to believe that a lot of IBM's terminal keyboards are interchangeable at the electrical level, with the differences being restricted to things like the keyboard ID and keycaps.


Be sure to save that page for later reference if desired, Geocities is going byebye. Although your site might not be the best place for the info (since your pages focus on your hardware, not "compatible hardware") it would be nice ultimately to end up with some Google-accessible page somewhere that clearly indicates what is compatible with what and what is necessary to accomplish conversion.

Quote from: dw_junon;110124
What about a DOS ("Windows 95") floppy?  That said, those aren't so trivial to make these days.


Do you mean a boot floppy disk, or full bootable OS on floppies? (in the case of the second I didn't know they existed at all, the first is easy though...bootdisk.com)

Quote from: dw_junon;110124
Another possible scan code set 3 test might be an SGI, IIRC.  Does any one reading this have any SGI boxes?


I saw an SGI system on the local Kijiji classifieds sometime recently but didn't have IO making it appropriate for my hobbyist purposes so I passed on it.

Quote from: dw_junon;110124
Yeah, as I think has been mentioned, this mostly follows the layout of the 84 key AT keyboard (http://www.9999hp.net/keyboard/temp/6540225-big.jpg) (I'm afraid my picture is of the UK variant, though it is similar enough that your list is consistent).


That's my understanding, it does overlap very much. I figured instead of saying "well, it's a lot like the original AT board" and making you go reference the two together I'd just tell you some equivalent keys I found though :)

Quote from: dw_junon;110124
"space saver"


I've seen photos of that floating around the forum in my past looking around; I figured it was the one in question based on how short it looked in one or two photos from that list. I would LOVE that keyboard...I'd end up mapping numpad keys to the top cmd keys though, because a game I play frequently (Garry's Mod, check it out if you don't know it, fantastic fun physics game) uses numpad keys extensively for automated things you make in it (to some gamers, it's obscene...but I love buckling spring boards for gaming).


Quote from: dw_junon;110124
I was kindly offered that by a chap who sold me some 5Ľ" floppies.  I hope to be able to put it to its intended use some day...
If you need a VLB motherboard, I have one somewhere. Last I tried I couldn't get the jumpers set right, tricky to find info for, but I'll tell ya what...it's yours for the cost of shipping if you want it.


I have a pack of never opened 5.25" floppies with a lifetime replacement guarantee...I wonder if the manufacturer, Fujifilm, is prepared to follow through with that?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Hak Foo on Mon, 17 August 2009, 00:44:12
Quote from: dw_junon;110124
What about a DOS ("Windows 95") floppy?  That said, those aren't so trivial to make these days.


Vista makes a WinME boot floppy, very easy.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Rajagra on Mon, 17 August 2009, 03:20:32
Quote from: Hak Foo;110153
Vista makes a WinME boot floppy, very easy.


Who says MS doesn't have a sense of humour?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: dw_junon on Mon, 17 August 2009, 15:03:06
Quote from: kishy;110128
Do you mean a boot floppy disk, or full bootable OS on floppies? (in the case of the second I didn't know they existed at all, the first is easy though...bootdisk.com)

The former; I neglected to include the word "boot".  Oops.  A whole DOS is feasible enough on multiple floppies with swapping on demand... a whole Win95 probably less so.

I was thinking more along the lines of "sys A:", and my concern was that most people probably don't have a 3.5" floppy drive and the requisite media any more.  Not that we count as most people in this respect...


Quote from: kishy
That's my understanding, it does overlap very much. I figured instead of saying "well, it's a lot like the original AT board" and making you go reference the two together I'd just tell you some equivalent keys I found though :)

Ah, righto.


Quote from: kisky
I've seen photos of that floating around the forum in my past looking around; I figured it was the one in question based on how short it looked in one or two photos from that list. I would LOVE that keyboard...

Yes, it is that exact same one I think, the seller reduced the price by 50%, I couldn't resist...  To think I only mentioned it here in the first place as an example of a weird obscure variant...  If you really want one, Argecy (http://www.argecy.com/index.php?product=14389) has them, fully refurbished with warranty, unlike mine; untested with cracks to the upper casing and two springs requiring reseating (though with all that said, it's fine).


Quote from: kishy
(Garry's Mod, check it out if you don't know it, fantastic fun physics game)

Will do.


Quote from: kishy
If you need a VLB motherboard, I have one somewhere. Last I tried I couldn't get the jumpers set right, tricky to find info for, but I'll tell ya what...it's yours for the cost of shipping if you want it.

That's very kind, but I think will have to pass.  If you have any spare time or space for sale, I might consider.


Quote from: kishy
I have a pack of never opened 5.25" floppies with a lifetime replacement guarantee...I wonder if the manufacturer, Fujifilm, is prepared to follow through with that?

I think there should be a web site for this sort of thing.  I think I have some Inmac floppies with a similar guarantee.  Various antique warranty cards to send in...  I do recall someone on the PS/2 newsgroup trying to get such a warranty honoured on something or another, but as you can tell I can't remember the details.


Quote from: Hak Foo
Vista makes a WinME boot floppy, very easy.

As above, my concern is whether the typical Vista user has the floppy drive.


Quote from: Rajagra
Who says MS doesn't have a sense of humour?

I expect we all know about this, but anyway: compare the output of ver in XP's command with command/c ver.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 17 August 2009, 19:59:07
Quote from: Hak Foo;110153
Vista makes a WinME boot floppy, very easy.


Eh...do we know how well Vista-generated boot floppies work? I for one have never messed with one.

Quote from: Rajagra;110163
Who says MS doesn't have a sense of humour?


Would be nice if Windows Fundamentals for Legacy PCs would actually work on legacy PCs...

Humourous in a sort of cynical way.

Quote from: dw_junon;110244
The former; I neglected to include the word "boot".  Oops.  A whole DOS is feasible enough on multiple floppies with swapping on demand... a whole Win95 probably less so.

I was thinking more along the lines of "sys A:", and my concern was that most people probably don't have a 3.5" floppy drive and the requisite media any more.  Not that we count as most people in this respect...


I didn't think such a thing as "bootable Windows 95 on floppies" existed, but of course I'd want it if it did.

3.5"? I hope you don't doubt me...
I have a stockpile of 5.25" drives ready for the future when they become incredibly rare...and a stack of disks as well. Never know where a hobby will take you, and some day I hope to track down an XT.

Quote from: dw_junon;110244
If you really want one


Well...generally speaking, my ideal price to pay is free. As you can see, that's a problem. I'm quite content with my two full sizers though.

In all seriousness, what do we think about painting the case black, putting silver paint in the little molded-in line that goes around the outside of the key area, putting blue backlighting under all the keys and then red backlighting for the lock keys (assuming I/we figure out how to get LEDs connected to the locks)?

Quote from: dw_junon;110244
That's very kind, but I think will have to pass.  If you have any spare time or space for sale, I might consider.


Two things I'm short on...well, tons of time, no patience, so the equivalent of no free time haha.

Quote from: dw_junon;110244
I think there should be a web site for this sort of thing.  I think I have some Inmac floppies with a similar guarantee.  Various antique warranty cards to send in...  I do recall someone on the PS/2 newsgroup trying to get such a warranty honoured on something or another, but as you can tell I can't remember the details.


More or less, I guess I'm wondering...is there a factory anywhere in the world that still produces 5.25" floppies?

If so, to what lengths would Fujifilm go to obtain those disks for me? lol.

Quote from: dw_junon;110244
As above, my concern is whether the typical Vista user has the floppy drive.


Valid concern; the majority of computers that ship with Vista do not have them. They either have a card reader or nothing; some don't even have externally accessible 3.5" bays. Tsk tsk; what if you had a Zip drive? Those aren't completely outdated, yet.

Quote from: dw_junon;110244
I expect we all know about this, but anyway: compare the output of ver in XP's command with command/c ver.


I don't know about it, but perhaps I've missed something / fallen for a prank: command /c automatically closes upon opening, thus you can't type a command in it.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Tue, 18 August 2009, 02:13:08
Spent some time experimenting with the 1390876 last night when I should have been sleeping.

I think what's making it hang with the standard Windows driver is that when it's reset, it sends AA like a standard keyboard, and then a little later sends BF BF.

The other thing, which is something of a nuisance: it looks as if it allows any given key to repeat, or send make/break codes, but not both at the same time.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 18 August 2009, 12:38:50
Quote from: JohnElliott;110326
Spent some time experimenting with the 1390876 last night when I should have been sleeping.

I think what's making it hang with the standard Windows driver is that when it's reset, it sends AA like a standard keyboard, and then a little later sends BF BF.

The other thing, which is something of a nuisance: it looks as if it allows any given key to repeat, or send make/break codes, but not both at the same time.


"Somewhat of a nuisance" seems to be an understatement; it seems to me there's no way to counteract that unless there was a way to make the computer interpret all keys as being typematic until it receives a break code (which apparently is not how it works already, otherwise typematic repeat would be working).

Problem with what I just proposed is that you would likely end up with accidentally repeated keys everywhere because it would instantly repeat with no real delay (at least so it seems to me).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Tue, 18 August 2009, 12:45:36
Quote from: kishy;110377
"Somewhat of a nuisance" seems to be an understatement; it seems to me there's no way to counteract that unless there was a way to make the computer interpret all keys as being typematic until it receives a break code (which apparently is not how it works already, otherwise typematic repeat would be working).

Problem with what I just proposed is that you would likely end up with accidentally repeated keys everywhere because it would instantly repeat with no real delay (at least so it seems to me).


You'd have to set all the keys to send make/break codes, and do typematic in software. Maintain a counter for each key, which gets set to a delay when a key is pressed. Every so often, subtract 1 from all the counters, and when one hits zero simulate another keypress and reset the counter.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: InSanCen on Tue, 18 August 2009, 13:24:46
Quote from: kishy;110293
I didn't think such a thing as "bootable Windows 95 on floppies" existed, but of course I'd want it if it did.


It does...

I'll see if I still have mine stashed away somewhere.

If I do, you're welcome to it, just pay shipping.

The Windows 1 (MS-DOS Executive!) however, is all mine! mwahahahaha...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 18 August 2009, 14:27:04
Quote from: JohnElliott;110380
You'd have to set all the keys to send make/break codes, and do typematic in software. Maintain a counter for each key, which gets set to a delay when a key is pressed. Every so often, subtract 1 from all the counters, and when one hits zero simulate another keypress and reset the counter.


It does sound to me like it'd work, doing it like that, but embarrassingly the only languages I really know are VB and Turing...the first being rather high-level (and I don't really know the hardware interaction part of it) and the second being rather useless.

Quote from: InSanCen about bootable Win95 on floppies
It does...

I'll see if I still have mine stashed away somewhere.

If I do, you're welcome to it, just pay shipping.

The Windows 1 (MS-DOS Executive!) however, is all mine! mwahahahaha...


Are you sure we're talking about the same thing? I'm referring to somewhat of a RAMdrive-based Win95, no hard drive needed.

Would disk images be a possibility? I have tons and tons of floppy disks.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JBert on Tue, 18 August 2009, 15:14:48
The more I read here, the more I start to think that a protocol converter could work more reliably. At least you could then let the uC handle all the weird protocol stuff instead of messing around with faulty Windows drivers.

It takes some guts and time to build one though...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 18 August 2009, 15:20:11
Quote from: JBert;110406
The more I read here, the more I start to think that a protocol converter could work more reliably. At least you could then let the uC handle all the weird protocol stuff instead of messing around with faulty Windows drivers.

It takes some guts and time to build one though...


At some unknown point in the future I will be making a kbdbabel protocol converter, but before that is possible I need someone who knows about uC programming and all that...and of course parts.

I have a very low budget and while I'm completely willing (and wanting) to make one, I need to know every single step before I buy anything for it...I won't even try it until I'm confident I can do it.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: dw_junon on Tue, 18 August 2009, 15:53:55
Quote from: kishy
In all seriousness, what do we think about painting the case black, putting silver paint in the little molded-in line that goes around the outside of the key area, putting blue backlighting under all the keys and then red backlighting for the lock keys (assuming I/we figure out how to get LEDs connected to the locks)?

Personally that sort of style doesn't appeal, but go for it.  You would have something unique even by this forum's standards.


Quote from: kishy
More or less, I guess I'm wondering...is there a factory anywhere in the world that still produces 5.25" floppies?

Athana (http://www.athana.com/) still manufacture 8" floppies.


Quote from: kishy
Tsk tsk; what if you had a Zip drive? Those aren't completely outdated, yet.

I have an external Zip 250 from University only a few years ago, where the vast majority of PCs had the internal drives.  This was a useful method of data transfer between my account and my own PC which was not on the network.  I haven't used Zip since, though.


Quote from: kishy
perhaps I've missed something / fallen for a prank: command /c automatically closes upon opening, thus you can't type a command in it.

It really wasn't intended as a prank (at least, not that sort of a prank).  In the command window you've just checked the output of ver in, command/c ver will open a secondary instance of command just to output ver and indeed, immediately exit.  This way the comparison is easy to make, too.


Quote from: JohnElliott
I think what's making it hang with the standard Windows driver is that when it's reset, it sends AA like a standard keyboard, and then a little later sends BF BF.

Thank you again for your investigative work.  Could this behaviour be upsetting the PS/2 perhaps?


Quote from: JohnElliott
Quote from: kishy
"Somewhat of a nuisance" seems to be an understatement; it seems to me there's no way to counteract that unless there was a way to make the computer interpret all keys as being typematic until it receives a break code (which apparently is not how it works already, otherwise typematic repeat would be working).

Problem with what I just proposed is that you would likely end up with accidentally repeated keys everywhere because it would instantly repeat with no real delay (at least so it seems to me).
You'd have to set all the keys to send make/break codes, and do typematic in software. Maintain a counter for each key, which gets set to a delay when a key is pressed. Every so often, subtract 1 from all the counters, and when one hits zero simulate another keypress and reset the counter.

I wonder why nested quotes don't work with the automatic quote function...

Putting the typematic functionality into software is intruiging (and hey, you could really play with the repeat rate...).  On the face of it, it sounds like it could work to me, though alas I could not currently implement this myself either.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: keyb_gr on Tue, 18 August 2009, 16:13:40
Quote from: dw_junon;110421
I wonder why nested quotes don't work with the automatic quote function...

This is probably done to avoid quoting clutter, under the basic assumption that most people wouldn't be able to handle multiple quoting levels in a sensible way. Makes me wonder how I got along on Usenet then.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 18 August 2009, 16:17:59
Quote from: dw_junon;110421
Personally that sort of style doesn't appeal, but go for it.  You would have something unique even by this forum's standards.


That's what I was aiming for :)
Black/silver would go with my desktop PC and monitor (as I am now using the monster keyboard as my main desktop keyboard; the lack of typematic repeat doesn't bother me).

Backlighting is just to make it competent with mods other people have done to boring rubber dome keyboards.

Quote from: dw_junon;110421
Athana (http://www.athana.com/) still manufacture 8" floppies.


Oh my...

Quote from: dw_junon;110421
useful method of data transfer


Indeed, until the advent of large capacity cheap USB storage of course. Zip still has a valid use in certain legacy situations I think, but almost anything that can use a Zip drive could also use USB, so that I suppose is why it faded into obscurity. I have a Zip 100 drive, no disks, would sell it but I keep getting this weird feeling like someone is going to ask me to recover files from zip disks.

Quote from: dw_junon;110421
It really wasn't intended as a prank (at least, not that sort of a prank).  In the command window you've just checked the output of ver in, command/c ver will open a secondary instance of command just to output ver and indeed, immediately exit.  This way the comparison is easy to make, too.


OH I SEE WHAT YOU MEAN
Why did they do that; did they seriously not update command.com since MS-DOS 5?

Quote from: dw_junon @ JohnElliott
Thank you again for your investigative work.


I second that; John you've been an amazing and I strongly suspect we'd have made very little progress without you (at least I would have been stuck clueless; I probably would have just opted to go head first into a kbdbabel build and say screw it halfway through).

Quote from: dw_junon;110421
I wonder why nested quotes don't work with the automatic quote function...

I've noticed this also, it's terribly annoying.

Quote from: dw_junon;110421

Putting the typematic functionality into software is intruiging (and hey, you could really play with the repeat rate...).  On the face of it, it sounds like it could work to me, though alas I could not currently implement this myself either.


I'll put it on the list of things to try at an unknown time in the future; anybody else who feels confident they can should by all means do it because I won't be trying any time soon (don't even have visual studio installed).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: quadibloc on Tue, 18 August 2009, 22:43:27
Quote from: InSanCen;110387
It does...

I'll see if I still have mine stashed away somewhere.


Bootable, not installable. Yes, Windows 95 could be installed from floppy disks (formatted in a nonstandard way which got more on the floppy, as well as preventing copying).

But Windows cannot be installed _to_ removable media so that you could actually run it from the floppies themselves instead of from a hard drive. (You click on "solitare", and the computer says "insert disk 7" so it can load and run solitaire.) That's what the other poster was talking about.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 18 August 2009, 22:52:08
Quote from: quadibloc;110492
Bootable, not installable. Yes, Windows 95 could be installed from floppy disks (formatted in a nonstandard way which got more on the floppy, as well as preventing copying).

But Windows cannot be installed _to_ removable media so that you could actually run it from the floppies themselves instead of from a hard drive. (You click on "solitare", and the computer says "insert disk 7" so it can load and run solitaire.) That's what the other poster was talking about.


Other poster, sheesh, it's my thread :(

I did know there was a set of installation floppies; I have the disk images. Very irritating though because of the somewhat proprietary format. The disks I used for a Win95 install became pretty much useless upon being formatted back to 1.44 after; they just couldn't stand up to it.

Unrelated to terminal boards and win95:

My 1993 USA-built 1391401 has drainage channels and holes. It was not made by Lexmark. I've read some things floating around the forum which suggest drainage holes and channels were a Lexmark-introduced idea...but then why doesn't my keyboard say Lexmark?

My 1993 Mexican-built 1391401 has drainage channels but is in a case without holes (the bottom part of the channels were sliced off, apparently), and has a Lexmark sticker on the PCB. What gives?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 19 August 2009, 01:18:10
Quote from: ripster;110506
1993 seems to be the year IBM decided to add drainage channels and holes to the Model M.  I also have a 1391401 with them.

Awesome, so I have just the right year then...my USA unit is still pre-Lexmark but has drainage channels. I don't plan to use them, of course, but I've been seriously tempted to pour a cup of water on it ever since discovering them...

Quote from: ripster;110506
The Mexican one not having holes is weird - I saw one with channels AND holes on clickykeyboards.

I called Unicomp before I got my 1386887s and asked if they had any info (I spoke with Jim, apparently that name is known around here)...he could find info on almost every terminal board there was but 1386887 was not in the list of part numbers (no record of it even existing, according to the documentation that got passed down to Unicomp).

During that call, I asked if there was anything special about Mexican Ms, and was told there wasn't...but that he believed the majority of units stamped as being from Mexico were probably factory refurbished since the bulk of the manufacturing was in the US.

The guts of my Mexican model M have a Lexmark sticker on them, but also a date indicating 1993 somewhere, I forget exactly what. I wonder if my unit was factory refurbished and they had to modify the guts to fit in the case because a case with holes was not available (keep in mind case itself is dated 1993 as well, so it would have to be pre-drainage-holes-introduction unless a new sticker was put on it).

Then again, it could be the school board who owned it before me, but I can't see why they would have done that.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 19 August 2009, 12:31:32
Quote from: ripster;110516
Here's the link (http://geekhack.org/showpost.php?p=104583&postcount=39) to the Mexican one.

Frankly, I find the Unicomp guys tend to talk down those "furriner" boards.  The one in the link looked mighty pretty to me.


At the point of bringing it up, he did kind of sound like "well why the hell would you care about those, just buy one from us" by his tone (did NOT say that directly and that is how I interpreted his tone; he easily could have not meant it that way).

Nice keyboard, nice nice. It doesn't look like the drainage channel design allows for very much liquid to be spilled all at the same time...let's say you slowly poured a cup of water on it, it would be fine...but if you just outright dumped it on it (as would happen if you knocked over a drink on your desk), it seems the water would come up and over the plastic tubes the keys fit in.

I've derailed my own thread.
Now about those mods...
For backlighting, what do we think works better:
a big EL strip run through the entire thing, or a piece of clear acrylic with holes drilled out for the keys covering the entire board then with LEDs along the sides?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Wed, 19 August 2009, 13:41:18
Just for the record, I've uploaded the source code for my driver patch to my 1390876 page (http://www.seasip.info/VintagePC/ibm_1390876.html). If you have a copy of the Windows 2000 DDK, this should let you build the modified driver.

There are no changes in functionality from the version kishy tested.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 19 August 2009, 13:53:04
Quote from: JohnElliott;110643
Just for the record, I've uploaded the source code for my driver patch to my 1390876 page (http://www.seasip.info/VintagePC/ibm_1390876.html). If you have a copy of the Windows 2000 DDK, this should let you build the modified driver.

There are no changes in functionality from the version kishy tested.

Thanks John, both for uploading it and for giving a hint at how to implement it.

Also for the record, the only issue I am finding (using XP Professional SP3 32-bit) is the lack of typematic repeat.

Then again, some people will consider the oddly-mapped keys an issue...I don't, because software remaps work fine. I'll be uploading (to this thread initially) my latest remap; it's much improved over the last one (someone somewhere might benefit from it being provided, so it will be).



edit:
Alright, I lied. There are other issues. I made some quick notes in notepad++ while testing all keys, found some things John might be interested in if he hasn't discovered them himself yet:
Quote
cmd24 = no break code

pressing cmd9 then cmd8 in that order is registered as "sleep" power key (by keyboardtest; windows doesnt react to it)

cmd9, 10, 11 behave oddly depending on the order you press them in - sometimes do not send break codes, sometimes do

"dup" key causes system beep; does not send break code
"ins" no break code

Please note - these were identified while using my remap
But the key names refer to the terminal layout
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Wed, 19 August 2009, 14:43:32
F9 and F10 have scancodes 60 and 61, so on key-up they send E0 and E1. Windows is going to interpret those as extended keycodes. So:

F9-up F7 = E0 5E = power
F9-up F8 = E0 5F = sleep
F9-up F12 = E0 63 = wake

The solution (short of a wholesale rewrite of the keyboard driver) would be to have those keys not return break codes.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 20 August 2009, 11:10:11
Quote from: JohnElliott;110661
F9 and F10 have scancodes 60 and 61, so on key-up they send E0 and E1. Windows is going to interpret those as extended keycodes. So:

F9-up F7 = E0 5E = power
F9-up F8 = E0 5F = sleep
F9-up F12 = E0 63 = wake

The solution (short of a wholesale rewrite of the keyboard driver) would be to have those keys not return break codes.

Erm...don't you mean have them send break codes? I would expect that if they don't send a break code first they act like modifier keys, as you've described, but since they actually are not sending break codes as it stands that is why they behave like they do.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Thu, 20 August 2009, 13:34:55
I'd love to get a full set of those CMD (PF) keycaps if you have a set you will part with. PM me if interested.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Thu, 20 August 2009, 15:36:32
Quote from: kishy;110792
Erm...don't you mean have them send break codes? I would expect that if they don't send a break code first they act like modifier keys, as you've described, but since they actually are not sending break codes as it stands that is why they behave like they do.


No; it's the break code from F9 (and probably F10 as well) that's causing the trouble. Have them send make codes only and that particular conflict doesn't arise.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 20 August 2009, 15:49:23
Quote from: Shawn Stanford;110830
I'd love to get a full set of those CMD (PF) keycaps if you have a set you will part with. PM me if interested.


I don't even have two complete sets unfortunately (2 keyboards = desire for 2 sets) so I don't have any extras to spare. I'm sure somewhere out there someone does have some though.

Quote from: JohnElliott;110874
No; it's the break code from F9 (and probably F10 as well) that's causing the trouble. Have them send make codes only and that particular conflict doesn't arise.


Odd...I believe you, but I find it odd. Those keys do not currently send break codes (intermittently, sometimes they do, it depends on the order you press the keys in) and it is when they don't send break codes that they serve the power functions.

Perhaps an example of theory not matching practice? idk.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Thu, 20 August 2009, 17:05:02
Quote from: kishy;110880
Odd...I believe you, but I find it odd. Those keys do not currently send break codes (intermittently, sometimes they do, it depends on the order you press the keys in) and it is when they don't send break codes that they serve the power functions.


They're sending the break codes, but Windows is getting to them before whatever program you're using does.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 20 August 2009, 18:01:57
Quote from: JohnElliott;110900
They're sending the break codes, but Windows is getting to them before whatever program you're using does.


Aha, that makes sense.

I suppose if I want to be one with my hardware I should probably get a little closer with Linux, but the few distributions I've tried drive me up the wall with silly little irritating things. In the end, everything always comes back to XP with me.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Rajagra on Fri, 21 August 2009, 05:34:29
Quote from: JohnElliott;110874
No; it's the break code from F9 (and probably F10 as well) that's causing the trouble. Have them send make codes only and that particular conflict doesn't arise.


Sounds like the problem mentioned here (http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-6.html).
Quote
the F9 and F10 keys send out 60 and 61, respectively, so their key release events send out e0 and e1, confusing the keyboard driver.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Fri, 21 August 2009, 14:37:34
Quote from: Rajagra;110986
Sounds like the problem mentioned here (http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-6.html).


That's an old copy of the site - the latest one splits that page into two:

http://www.win.tue.nl/~aeb/linux/kbd/scancodes-7.html
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-8.html
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Fri, 21 August 2009, 14:48:20
I've updated the driver patch on my site so that it treats E0 and E1 as normal scancodes; so the break codes from Cmd9 and Cmd10 can now be seen.

As for Dup and Ins, they have translated scancodes 7F and 7A, so their translated key-up codes are FF and FA. The Windows driver treats FA (ACKNOWLEDGE) specially; I'm not sure what its beef is with FF.

The solution to this would be to turn off scancode translation at the hardware level and do it in the driver; then the driver could distinguish between F07A (key 7A up) and FA (Acknowledge). But, as with typematic, that's rather a big thing to try.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 21 August 2009, 22:22:45
Quote from: JohnElliott;111144
I've updated the driver patch on my site so that it treats E0 and E1 as normal scancodes; so the break codes from Cmd9 and Cmd10 can now be seen.

As for Dup and Ins, they have translated scancodes 7F and 7A, so their translated key-up codes are FF and FA. The Windows driver treats FA (ACKNOWLEDGE) specially; I'm not sure what its beef is with FF.

The solution to this would be to turn off scancode translation at the hardware level and do it in the driver; then the driver could distinguish between F07A (key 7A up) and FA (Acknowledge). But, as with typematic, that's rather a big thing to try.


Thanks for continuing your work on this; I know Windows isn't your primary platform or certainly seems not to be so the Windows users certainly appreciate your efforts. It seems to me you're pretty much eliminating the need for a kbdbabel adapter.

Will be testing new version of patch once I find the Win2k DDK...to save some time, do you think the current Windows Driver Kit (which appears to contain the current DDK) would suffice? Seems they haven't changed the driver model much since 2k so in theory it'd be fine...

You can note on your site that driver replacement can be done in Safe Mode; this is arguably easier for most people than messing with disabling WFP or booting into a different OS (mainly because of DL times on a liveCD).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 22 September 2009, 20:03:29
Well, I just noticed one of the contributors to this thread online, and it sparked my interest...anyone made further progress of any kind? Any new info to add?

I've been happily pounding away on the beast. I never did figure out how to use the diff file for the driver mod; oh well, it's been working fine for me.

Now missing only one keycap btw: Cmd14.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Fri, 25 September 2009, 21:36:50
I'm pleased to say I registered for this forum and am posting this reply from my new 1386887 on Windows 7.

I've run into a few issues so far, but I'm working on them.. For one, any key remapping programs seem to want to write to HKCU/Keyboard Layout, whereas Win7 wants things to be in HKLM/system/currentcontrolset/control/keyboard layout... Also for some reason I can't get certain keys to remap, like ALT, the "CMD" keys, and for some reason, the down arrow key. I'm not sure if this is me or "Key Mapper" failing to use the correct scancode, or if it's a limitation of Win7.
I can't seem to use the KVM trick, nor can I get it to work with a PS2-to-USB adapter, I have to wait till I get to the login screen, then physically unplug and replug the cable.

Naturally, I'm also having issues trying to map things to the windows key (doesn't send a "up" code, acts as if the key is depressed till I reboot), and I'm having problems toggling numlock (again, doesn't send an "up" code, so once I hit numlock I have to reboot to use the numpad again)

All in all, I'm pretty happy with how smooth this has gone, and once I can start mapping keys properly I think I'm going to really enjoy using this keyboard.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 25 September 2009, 21:48:54
Quote from: pseudolobster;120640
I'm pleased to say I registered for this forum and am posting this reply from my new 1386887 on Windows 7.

I've run into a few issues so far, but I'm working on them.. For one, any key remapping programs seem to want to write to HKCU/Keyboard Layout, whereas Win7 wants things to be in HKLM/system/currentcontrolset/control/keyboard layout... Also for some reason I can't get certain keys to remap, like ALT, the "CMD" keys, and for some reason, the down arrow key. I'm not sure if this is me or "Key Mapper" failing to use the correct scancode, or if it's a limitation of Win7.
I can't seem to use the KVM trick, nor can I get it to work with a PS2-to-USB adapter, I have to wait till I get to the login screen, then physically unplug and replug the cable.

Naturally, I'm also having issues trying to map things to the windows key (doesn't send a "up" code, acts as if the key is depressed till I reboot), and I'm having problems toggling numlock (again, doesn't send an "up" code, so once I hit numlock I have to reboot to use the numpad again)

All in all, I'm pretty happy with how smooth this has gone, and once I can start mapping keys properly I think I'm going to really enjoy using this keyboard.

Awesome...obviously the bugs you have still are an annoyance but I'm sure they can be resolved.

I'm curious to see if John's modified keyboard driver (which is natively for 2000/XP) will work for Vista/7. Of course, if it doesn't, you could end up with no PS/2 port functionality until you got the original driver restored...which is less than optimal. This fixes, at least in 2000/XP, the key up/"break" code issue and the unplugging/replugging...I never got his latest update to it to work (the details visible a few posts up).

As for some keys not being remappable, it may actually depend on the order in which you remap them. I don't know for sure, just throwing an idea out there.

Search for i8042prt.sys...if you find one in C:\WINDOWS\system32\drivers then it's quite possible the driver may not have changed (much if at all) from XP, meaning the modified one would probably work.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Fri, 25 September 2009, 22:07:13
Yes, windows 7 does in fact have the i8048prt.sys driver, and it's loaded as an active service for keyboards... I have every reason to believe the win2k driver will work in windows7.

Interestingly, typematic repeat does seem to be working, though I think that's an artifact of the keyboard *not* sending the "up" codes, and if the driver ends up changing this to let all keys send an up code, it'd probably break the repeat function... That's not a big deal for me, I'd rather map one of my 24 extra buttons to a windows key than be able to hold a key down to repeat.

I'm not going to be able to test much more till monday when I'm at work again, but I have high hopes of being able to remap the AT84 "F-keys" on the left to useful features, and map the "CMD" keys on the top to actual F-keys.

I've also been able to map the down arrow key to the blank key in the centre of the arrow keys, but for one reason or another I can't use the actual "Roll" down key.

Also, in case anyone's wondering, I bought my keyboard from the ebay seller "puravida1881" mentioned earlier in this thread, and I'm quite happy with the condition of the keyboard.. It looks brand new, there's no cruft between the keys, no engine grease or whatnot on the chassis; it seems the seller went to the trouble of dishwashering the keyboard or something, since the only evidence of dirt is under the keycaps.

Anyways, if anyone could send me a copy of the compiled version of the win2k driver, I'd be happy to test it on Win7... I do have a valid license for Win2k, but I don't have the DDK or visual studio to compile it.

(edit) - I've also attached my current reg file to map the keyboard as best as I can... I went through every non-responsive key in "Key Mapper" I could find, and remapped them the best I could, but it's still a work in progress... Ctrl is now Ctrl, Capslock is now capslock, the INS, DEL, PGUP etc work, but there's still no ALT key and the CMD buttons at the top still refuse to act as F-keys... I'll work on that on monday. (edit again) - Oh and also, there's no backslash key, I'm really going to have to do something about that... Also, I use the DVORAK layout, so I'm not entirely sure if this reg file will work as expected under the QWERTY layout.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 25 September 2009, 22:36:49
Quote from: pseudolobster;120648
Yes, windows 7 does in fact have the i8048prt.sys driver, and it's loaded as an active service for keyboards... I have every reason to believe the win2k driver will work in windows7.

Interestingly, typematic repeat does seem to be working, though I think that's an artifact of the keyboard *not* sending the "up" codes, and if the driver ends up changing this to let all keys send an up code, it'd probably break the repeat function... That's not a big deal for me, I'd rather map one of my 24 extra buttons to a windows key than be able to hold a key down to repeat.

I'm not going to be able to test much more till monday when I'm at work again, but I have high hopes of being able to remap the AT84 "F-keys" on the left to useful features, and map the "CMD" keys on the top to actual F-keys.

I've also been able to map the down arrow key to the blank key in the centre of the arrow keys, but for one reason or another I can't use the actual "Roll" down key.

Also, in case anyone's wondering, I bought my keyboard from the ebay seller "puravida1881" mentioned earlier in this thread, and I'm quite happy with the condition of the keyboard.. It looks brand new, there's no cruft between the keys, no engine grease or whatnot on the chassis; it seems the seller went to the trouble of dishwashering the keyboard or something, since the only evidence of dirt is under the keycaps.

Anyways, if anyone could send me a copy of the compiled version of the win2k driver, I'd be happy to test it on Win7... I do have a valid license for Win2k, but I don't have the DDK or visual studio to compile it.

(edit) - I've also attached my current reg file to map the keyboard as best as I can... I went through every non-responsive key in "Key Mapper" I could find, and remapped them the best I could, but it's still a work in progress... Ctrl is now Ctrl, Capslock is now capslock, the INS, DEL, PGUP etc work, but there's still no ALT key and the CMD buttons at the top still refuse to act as F-keys... I'll work on that on monday. (edit again) - Oh and also, there's no backslash key, I'm really going to have to do something about that... Also, I use the DVORAK layout, so I'm not entirely sure if this reg file will work as expected under the QWERTY layout.


Then you got your keyboard from the same place I got mine - from the same city I live in - and it was made on the same day as both of my 2 :) 16 Oct 1986?

It would indeed be quite neat if the Win2k driver works out for you. Since I haven't figured out the DDK thing myself either, watch your PM inbox.

I doubt typematic repeat is working for you in the proper sense; for example I found keys would repeat if I was on a USB converter (cooonnnveeerteeerr or something like that) but not when plugged into PS/2 directly. I think it's a feature the keyboard just doesn't have, probably because of a limitation on the terminals they were designed for, so the feature was never implemented on either the terminal or the keyboard.

Very strange about not being able to map the Roll down key; I had no problem with either of my 2 units before or after the driver swap. Does Key Mapper reflect you pressing any key at all when you press it, or does it not respond in any way? I wouldn't jump to this conclusion normally but if it was heavily used (which I suspect it was, like my 2) the membrane traces may be worn out. Hopefully not the case.

A good place to put backslash is the } { key above right shift, unless you've found another use for it already.

Since I'm a QWERTY guy I won't toy around with your remap reg file.

I'm heading to bed shortly, completely exhausted. I may have missed something or a couple somethings in this reply; if I did I'll figure it out tomorrow.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Sat, 26 September 2009, 13:03:36
I'll have to check the manufacture date on monday, but that date does sound familiar... I know it's from 86 anyway.

As for the typematic thing, I'm not really sure how/why it's repeating, though when I hold a key down it waits about two seconds then starts repeating the letter.. This isn't a windows thing as far as I can tell, it does it in DOS 6.0 as well as windows 3.1. Not all keys repeat though, for instance I remapped the keys that were acting as F11 and F12 to be volume up and down, but they won't repeat if I hold them down.

As for some keys refusing to remap (like the roll down button), I'm pretty convinced it's either a windows 7 thing or a KeyMapper thing... I think I'll try my hand at making a reg file by hand to remap those keys and see if it works... KeyMapper does see the keys and it does act like it's going to let me remap them, but when I reboot nothing's changed. If I recall correctly the "roll down" key was interpreted as "Unknown", and a few of the CMD buttons were showing up as F-buttons, others were unknown, but none were unresponsive.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Mon, 28 September 2009, 14:35:00
I've had a bit of time to play with my new keyboard today, though not long enough to troubleshoot why I can't get the alt keys to remap... I've installed the patched i8048prt driver and I'm pleased to say it works well under Win7, though as I predicted it broke the typematic functionality. It now sends keyup signals, so I can turn numlock on and off etc, and I no longer have unplug and replug it at the login screen, though there's still some issues that I need to work on.

I can't remap the "roll down" key to down arrow, either through Key Mapper or the reg file patches in this thread, nor can I use the alt keys... I try to remap them in Key Mapper, they're detected as "Unknown" and it acts like it's going to let me map them to alt, but when I reboot I still have no alt key. My CMD3 and CMD4 keys won't remap to F3 and F4, though all the other CMD keys do.. Home and End don't seem to send up codes, Passmark KeyboardTest shows them as red when I press them, and the home key, while it works, makes a windows "blip" noise when I press it. I wonder if my keyboard is somehow electrically different than others in this thread or if windows 7 just doesn't like you remapping certain keys.

Anyways, my manufacturing date is Oct 30th, 1986 in case anyone's curious. I'll have some time later (hopefully) to take another stab at getting the remaining bugs worked out.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: quadibloc on Mon, 28 September 2009, 14:53:42
I recall that it was noted for one of the conversions of this nature that the keyboard sent break codes only for the shift keys, and only make codes for all other keys.

This is different from the way a normal IBM PC keyboard behaves; only one key (I think it is Break, but I don't remember for certain) does not send a break code. When the keys were remapped for the 101-key keyboard, the other shift of the key was made to send the break code immediately after the break code so as to avoid problems as shift keys are pressed and released.

I think that in Scan Code Set 3 break codes are still used on the PC for keys other than the shift keys (Shift, Alt, Ctrl... and the Windows Shift, to which Windows has not deigned to assign a Scan Code Set 3 code) and so it isn't surprising that even if the keyboard sends an electrically compatible signal with the right serial data format and clock signal, it won't really work there.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Mon, 28 September 2009, 15:10:30
Thanks to Kevin (Kishy), I'm now the proud owner of a very clean 1390572 dated 26SEP87 with a 5-pin DIN connector. At first blush, it has about the same feel as my 101-key Model M and a much less 'springy' feel than my 122-key Boscom. It's a true terminal keyboard: it has the the Cmd1-24 keys, the exclam and cents-sign are outboard of the 'P', the 1 key has the vertical bar (logical 'and' or 'not', I forget), the six has that funny bar doohicky, instead of the caret (^) and there are no brackets ([ ]).

Awesome!

Kevin's route involved putting in a different cable and connector, so I guess that's where I'll start. Since Ripster just destroyed a Boscom 122, I guess I'll see if he still has the circuit board and cable to spare...

Edit: Has anyone tried one of these before? http://cgi.ebay.com/PS-2-6-Pin-Mini-DIN-Female-to-5-Pin-DIN-Male-Adapter_W0QQitemZ180411348870QQcmdZViewItemQQptZPCA_Cables_Adapters?hash=item2a015ab786&_trksid=p3286.c0.m14? I have to assume if it was that easy, we'd all be using these things...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: msiegel on Mon, 28 September 2009, 15:16:08
cool! :D

| = "or"
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 28 September 2009, 18:08:22
Quote from: quadibloc;121223
I recall that it was noted for one of the conversions of this nature that the keyboard sent break codes only for the shift keys, and only make codes for all other keys.

This is different from the way a normal IBM PC keyboard behaves; only one key (I think it is Break, but I don't remember for certain) does not send a break code. When the keys were remapped for the 101-key keyboard, the other shift of the key was made to send the break code immediately after the break code so as to avoid problems as shift keys are pressed and released.

I think that in Scan Code Set 3 break codes are still used on the PC for keys other than the shift keys (Shift, Alt, Ctrl... and the Windows Shift, to which Windows has not deigned to assign a Scan Code Set 3 code) and so it isn't surprising that even if the keyboard sends an electrically compatible signal with the right serial data format and clock signal, it won't really work there.

This is 100% true, but after the entire mod process it is a non-issue - John's driver modification fixed it so the keyboard sends break codes on all keys.

Since the concept of a diff file is almost impossible for Windows users like myself, PM me for an older but still mostly functional replacement driver for NT-like Windows operating systems (2k, XP, probably Vista and 7). No guarantees on actual NT though...

For use in Linux for example an equivalent driver modification would be needed. Now recruiting Linux driver experts!

Mac, no clue.

Pre-2000 Windows: supposedly 98 included a native driver for these, which is weird because they never once came with an actual PC-compatible plug. Will verify this at a later date.

Quote from: Shawn Stanford;121230
Thanks to Kevin (Kishy), I'm now the proud owner of a very clean 1390572 dated 26SEP87 with a 5-pin DIN connector. At first blush, it has about the same feel as my 101-key Model M and a much less 'springy' feel than my 122-key Boscom. It's a true terminal keyboard: it has the the Cmd1-24 keys, the exclam and cents-sign are outboard of the 'P', the 1 key has the vertical bar (logical 'and' or 'not', I forget), the six has that funny bar doohicky, instead of the caret (^) and there are no brackets ([ ]).

Awesome!

Kevin's route involved putting in a different cable and connector, so I guess that's where I'll start. Since Ripster just destroyed a Boscom 122, I guess I'll see if he still has the circuit board and cable to spare...

Edit: Has anyone tried one of these before? http://cgi.ebay.com/PS-2-6-Pin-Mini-DIN-Female-to-5-Pin-DIN-Male-Adapter_W0QQitemZ180411348870QQcmdZViewItemQQptZPCA_Cables_Adapters?hash=item2a015ab786&_trksid=p3286.c0.m14? I have to assume if it was that easy, we'd all be using these things...

There is a problem; the keyboard I sent you is RJ45 like a network plug...
As well I believe it had PF keys, not Cmd.

Please verify the keyboard you got is the same one I sent, 1394167 built by IBM UK on 24-05-99. Thanks. If you got a different one...apparently customs decided they wanted to trade you for it.

Keyboard overall (before I harvested the keycaps I needed):
http://img121.imageshack.us/img121/6342/1394167top.jpg

Sticker:
http://img17.imageshack.us/img17/3112/1394167sticker.jpg

Plug:
http://img17.imageshack.us/img17/9137/1394167plug.jpg

In any event, glad you're enjoying it so far :)

If it was DIN 5, the DIN plug on these keyboards is not the same as an AT or XT DIN plus (the pins are spaced wider and shell design is different). As a result, those adapters would not work (but they would work on a finished conversion with an AT plug that you wanted to plug into PS/2 or vice versa, but never a pre-mod keyboard...cord or at least end plug must always be swapped since those 240-degree DIN plugs are useless on their own)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Mon, 28 September 2009, 18:14:39
Quote from: quadibloc;121223
I recall that it was noted for one of the conversions of this nature that the keyboard sent break codes only for the shift keys, and only make codes for all other keys.


That's the default behaviour. You can send commands to the keyboard making all keys (or just some) send make and break codes. The problem is that on these keyboards, each key can send make/break codes, or do typematic repeat, but not both.

Some keys also have weird effects on Windows because their translated key-up codes get mistaken for protocol scancodes. The likely ones here are Dup and Ins (corresponding to Home and End on a 102-key keyboard) and Cmd10 and Cmd11. Dup and Ins have key-up codes of FF (error) and FA (acknowledge); Cmd10 and Cmd11 have key-up codes of E0 and E1 (extended keypress). The latest version of my patch removes the special significance from E0 and E1.

Windows uses E05B, E05C and E05D for its Windows and Menu keys. A terminal keyboard uses 5B, 5C and 5D for Cmd3, Cmd4 and Cmd5. This may explain what's going on with Windows 7 and these keys.

(According to this table (http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.6), the proper Set 3 scancodes for the Windows/menu keys are 8B, 8C and 8D. )
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: microsoft windows on Mon, 28 September 2009, 18:29:57
Does this conversion work with old Model F terminal keyboards?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ch_123 on Mon, 28 September 2009, 18:31:18
Yep. JohnElliot and Kishy have working conversions.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 28 September 2009, 18:42:16
Quote from: ch_123;121286
Yep. JohnElliot and Kishy have working conversions.


Mine are Model M boards; I believe John has a Model F, so no substantial changes happened between the 2 apparently. Makes sense since they had to maintain compatibility with the same terminal hardware.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 28 September 2009, 19:05:58
Worth noting; you can use any cheap old AT or PS/2 keyboard cord, but since they probably used different wire colours (or worse, same colours on wrong pins) you'll have to use a continuity tester to figure out the pinout of the cable.

Not the end of the world; I did that for BOTH of my two...bit of a headache after but it took no time at all.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Mon, 28 September 2009, 19:10:30
Quote from: JohnElliott;121281
[...]
Some keys also have weird effects on Windows because their translated key-up codes get mistaken for protocol scancodes. The likely ones here are Dup and Ins (corresponding to Home and End on a 102-key keyboard) and Cmd10 and Cmd11. Dup and Ins have key-up codes of FF (error) and FA (acknowledge); Cmd10 and Cmd11 have key-up codes of E0 and E1 (extended keypress). The latest version of my patch removes the special significance from E0 and E1.

Windows uses E05B, E05C and E05D for its Windows and Menu keys. A terminal keyboard uses 5B, 5C and 5D for Cmd3, Cmd4 and Cmd5. This may explain what's going on with Windows 7 and these keys.[...]


Yes, I can absolutely confirm this. I just finished pressingc CMD9, then CMD5 and Passmark Keyboardtest claimed it was the R-Win key, which didn't transmit an up code, leaving me minimizing all windows any time I pressed M and opening explorer any time I pressed E.

So, out of curiosity, what's required to compile that driver? The Win2k DDK, visual studio, and diff? I think if I go looking I can find a copy of VS05 from back when I had an MSDN technet subscription, will that work?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 28 September 2009, 19:16:20
Quote from: pseudolobster;121293
Yes, I can absolutely confirm this. I just finished pressingc CMD9, then CMD5 and Passmark Keyboardtest claimed it was the R-Win key, which didn't transmit an up code, leaving me minimizing all windows any time I pressed M and opening explorer any time I pressed E.

So, out of curiosity, what's required to compile that driver? The Win2k DDK, visual studio, and diff? I think if I go looking I can find a copy of VS05 from back when I had an MSDN technet subscription, will that work?

The Win Key thing sounds to me like you're using the beast on a PS/2 to USB converter. A big no-no, it will never be possible to make it work on that without extensive mods to software that I don't think anyone will ever work on...

too bad, because I have wishes to do the same.

If you're actually using it on real PS/2, well, that's both weird and cool that it did that. I only had that happen while on my USB converter though.

About driver compilation - I've PM'd him already today about that so if he doesn't post it publicly I may if it's alright with him. My eventual goal would be providing the finished file for download anyway, but there are legal concerns.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Mon, 28 September 2009, 19:41:18
I'm actually not using any kind of USB adapter, just plugging straight into PS2. Strange, eh?

If I can figure out how to compile this, I'd like to try a few changes, such as disabling the "key up" code for backspace, and seeing if that will allow typematic to work the way it did before I patched the file... Backspace is probably the only key where I'd actually like it to have repeat.

Once I have the binary files compiled I can make a diff of the two files, release a patch of the difference as an IPS file or something, then have the user patch their own copy of i8048prt.sys, that way no MS copyrighted stuff is used... Throw it on a boot floppy image with freedos and away you go... On the other hand, I'm pretty sure the EULA of the DDK specifically allows this sort of thing... I'm no lawyer, but I recall the guys from ReactOS including NT DDK source and while they found it was technically legal, they decided against it just to be as "clean room" as possible.. Here's a discussion thread that includes the full EULA, in case anyone here actually IS a lawyer and can provide a more definitive answer: http://www.tech-archive.net/Archive/Development/microsoft.public.development.device.drivers/2005-11/msg00474.html
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 28 September 2009, 20:48:19
Quote from: pseudolobster;121304
I'm actually not using any kind of USB adapter, just plugging straight into PS2. Strange, eh?


Indeed...rather cool though. If you don't mind could you throw me the part number of that keyboard again, I'm sure you mentioned it but things get buried quickly here.

Quote from: pseudolobster;121304
If I can figure out how to compile this, I'd like to try a few changes, such as disabling the "key up" code for backspace, and seeing if that will allow typematic to work the way it did before I patched the file... Backspace is probably the only key where I'd actually like it to have repeat.


While I agree with your motives wholeheartedly, I think that may create issues in certain software (notably games if you play any). The sticking keys, if assigned to any function in a Source engine game for example, do not release until the next key is received...you can see how that would be problematic if you mapped backspace to something.

Nonetheless I'm interested in trying whatever results you get.

Quote from: pseudolobster;121304
Once I have the binary files compiled I can make a diff of the two files, release a patch of the difference as an IPS file or something, then have the user patch their own copy of i8048prt.sys, that way no MS copyrighted stuff is used... Throw it on a boot floppy image with freedos and away you go...


Something fairly automatic is best...I'd go for that. However, be warned that windows file protection may still replace the file on next login...I forget exactly how that works.

Quote from: pseudolobster;121304
(info regarding legality)


Makes sense to me that files you could create through a freely available tool for use with an operating system which you (presumably) own a license for...would be freely distributable.

My rationale for thinking this: in order to use the file in its finished state, you must have the operating system (which in theory was paid for). Through using the file in its normal way, it is impossible to see copyrighted code. If anything, it seems to me a diff file or similar concept would be more illegal on the basis of it making the source code easier to access...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Mon, 28 September 2009, 22:15:48
Quote from: kishy;121315
Indeed...rather cool though. If you don't mind could you throw me the part number of that keyboard again, I'm sure you mentioned it but things get buried quickly here.

A regular old 1386887. *shrug*... I wonder if the ps2 port has anything to do with it.. I suppose I could try it on another motherboard, though I only have win7 on one machine right now, so it wouldn't really narrow things down any.

Quote from: kishy;121315
While I agree with your motives wholeheartedly, I think that may create issues in certain software (notably games if you play any). The sticking keys, if assigned to any function in a Source engine game for example, do not release until the next key is received...you can see how that would be problematic if you mapped backspace to something.

Nonetheless I'm interested in trying whatever results you get.

Personally, I wouldn't mind not being able to map backspace in a game if it meant being able to hold down backspace to delete a line of text. My left hand never strays farther than "T" when I'm gaming.

Quote from: kishy;121315
Something fairly automatic is best...I'd go for that. However, be warned that windows file protection may still replace the file on next login...I forget exactly how that works.
Makes sense to me that files you could create through a freely available tool for use with an operating system which you (presumably) own a license for...would be freely distributable.


I didn't have any problems with windows file protection in the slightest. I suppose time will tell, it may want to revert the file later if windows figures out what I've done.

It'll be pretty automatic, if you have a floppy drive that is... I've made self-exrtacting boot disks before and it's not hard to include a patching program in autoexec.bat and have it all run automatically.

Quote from: kishy;121315
My rationale for thinking this [...] it seems to me a diff file or similar concept would be more illegal on the basis of it making the source code easier to access...


I'd be making a file that includes the difference between the unpatched and patched binary files, not the source code.. The differences would be entirely unique code, including zero microsoft copyrighted code, and it'd be unreadable to humans.

That is, of course, the worst case scenario... If we can find out for sure that it's legal for John to redistribute the modified driver, we could just write an inf file for it and have it install like any other driver. It'd be unsigned, but there'd be no messing around with safe mode or dos boot disks or linux or whatnot.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Tue, 29 September 2009, 05:16:43
Quote from: kishy;121279
There is a problem; the keyboard I sent you is RJ45 like a network plug... As well I believe it had PF keys, not Cmd. Please verify the keyboard you got is the same one I sent, 1394167 built by IBM UK on 24-05-99. Thanks. If you got a different one...apparently customs decided they wanted to trade you for it.

Woops!

It turns out your keyboard isn't here yet; this is the one I won on eBay for $12 a few days ago. That's kind of scary...

I pulled the connector and circuit board out of an old Dell. Here are the two circuit boards and the ends of the connectors:
(http://i267.photobucket.com/albums/ii309/ShawnStanford/PICT0120.jpg)

It looks like I'm going to have to unlimber my multimeter to see if the wire colors correspond...
(http://1.bp.blogspot.com/_iHD7oZMEaas/Sor_yP9UJFI/AAAAAAAABWY/VBhyiB2HQww/s400/stand_back_square_0.png)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 29 September 2009, 08:09:51
Quote from: pseudolobster;121330
A regular old 1386887. *shrug*... I wonder if the ps2 port has anything to do with it.. I suppose I could try it on another motherboard, though I only have win7 on one machine right now, so it wouldn't really narrow things down any.

Geez, how the heck did I forget that...same keyboard as me, made on same day, sold by same seller.

I'm thinking it's something new in Vista and/or 7 which is causing those keys to do something...maybe a Microsoft keyboard product needed some additional support, who knows.


Quote from: pseudolobster;121330
Personally, I wouldn't mind not being able to map backspace in a game if it meant being able to hold down backspace to delete a line of text. My left hand never strays farther than "T" when I'm gaming.

Eh, makes sense to me. Definitely post with your progress!

Quote from: pseudolobster;121330
I didn't have any problems with windows file protection in the slightest. I suppose time will tell, it may want to revert the file later if windows figures out what I've done.

It'll be pretty automatic, if you have a floppy drive that is... I've made self-exrtacting boot disks before and it's not hard to include a patching program in autoexec.bat and have it all run automatically.

I imagine if WFP didn't catch it the first time, it never will. Nice to know 7 isn't quite as nazi-like I suppose.


Quote from: pseudolobster;121330
I'd be making a file that includes the difference between the unpatched and patched binary files, not the source code.. The differences would be entirely unique code, including zero microsoft copyrighted code, and it'd be unreadable to humans.

That is, of course, the worst case scenario... If we can find out for sure that it's legal for John to redistribute the modified driver, we could just write an inf file for it and have it install like any other driver. It'd be unsigned, but there'd be no messing around with safe mode or dos boot disks or linux or whatnot.

Hmm...good point about the patching method. Hopefully though it won't be needed; seems to me it adds extra steps to a process that is already capable of spinning some heads.

Quote from: Shawn Stanford;121369
Woops!

It turns out your keyboard isn't here yet; this is the one I won on eBay for $12 a few days ago. That's kind of scary...

(CP says package arrived; tracking link removed)

It's in the US so it shouldn't be long. That's funny though.

Quote from: Shawn Stanford;121369
I pulled the connector and circuit board out of an old Dell. Here are the two circuit boards and the ends of the connectors:
(image)

It looks like I'm going to have to unlimber my multimeter to see if the wire colors correspond...
(image)

Yeah, go with a meter, I certainly wouldn't trust colour alone.
Don't forget those goggles mister!
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Tue, 29 September 2009, 08:31:42
Quote from: ripster;121291
Sorry, saving those parts for other mods.  Especially if I ever get around to making a buckling spring numpad.

Ah, well, that's reasonable. Do you have any pics of the circuit board and ribbon cable connections? I don't want to take my Boscom apart (since it's in daily use), but I'm curious as to how well they correspond with what's in the terminal board. I suspect, since my understanding is that Unicomp just bought IBM's keyboard business lock-stock, that the circuit board in the Unicomp 122 is completely compatible with the old IBM boards. That means that any vintage IBM terminal board could be brought up to modern specs by implanting a Unicomp circuit board. Which, of course, begs the question: will Unicomp sell just the circuit boards to those interested in retrofitting?

Hey, don't I owe you a 'Rule Home' key? I think I still have it floating around my house somewhere...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Tue, 29 September 2009, 09:25:24
Quote from: ripster;121403
Pics are in the "Destroying Boscom For Science" post in the mods section.  

Cool, thanks.

Quote
I have two "Rule Home" keys now so I think I'm set.  Does yours work? - I keep pressing mine and my wife ignores it.

If it did, do you think I would have offered it to you..?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: itlnstln on Tue, 29 September 2009, 09:30:16
Quote from: ripster;121403
Does yours work? - I keep pressing mine and my wife ignores it.

But for some reason, you keep doing everything your wife says. Odd.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: itlnstln on Tue, 29 September 2009, 09:38:00
Quote from: ripster;121418
Anyone with Spotted **** for an avatar would appreciate the ancient Chinese saying,

That's why I own my house completely.  I can kick 'em out whenever I want.  I wouldn't do it, and I haven't, but it's always an option.  It keeps things even.  I am a very nice guy, but when the chips are down, I always have the winning card.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 29 September 2009, 10:45:47
Quote from: Shawn Stanford;121393
Ah, well, that's reasonable. Do you have any pics of the circuit board and ribbon cable connections? I don't want to take my Boscom apart (since it's in daily use), but I'm curious as to how well they correspond with what's in the terminal board. I suspect, since my understanding is that Unicomp just bought IBM's keyboard business lock-stock, that the circuit board in the Unicomp 122 is completely compatible with the old IBM boards. That means that any vintage IBM terminal board could be brought up to modern specs by implanting a Unicomp circuit board. Which, of course, begs the question: will Unicomp sell just the circuit boards to those interested in retrofitting?

Hey, don't I owe you a 'Rule Home' key? I think I still have it floating around my house somewhere...


I'll ignore the silliness that has taken over my thread.
The internet is serious business, guise.


I believe past discussions in other threads established that it should be possible to do the circuit board swap you suggested, but Unicomp is unwilling/unable to supply the boards individually (or at least at a reasonable price, perhaps understandably)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Tue, 29 September 2009, 13:52:45
Quote from: pseudolobster;121293
So, out of curiosity, what's required to compile that driver? The Win2k DDK, visual studio, and diff? I think if I go looking I can find a copy of VS05 from back when I had an MSDN technet subscription, will that work?

I used the Windows 2000 DDK and Visual Studio 6, and generated the diff file under Linux (though I'm sure I could have used Cygwin). The actual DDK build scripts run from inside a command prompt with a special environment.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: quadibloc on Tue, 29 September 2009, 15:43:06
Quote from: JohnElliott;121281
The problem is that on these keyboards, each key can send make/break codes, or do typematic repeat, but not both.


This is interesting, and I admit that I'm not an expert on this sort of thing. But there is one thing that surprises me about this statement, although I'm sure it derives from actual experience.

I would have guessed that since there are controls for setting the repeat delay and repeat rate in Control Panel in Windows, typematic behavior on a PC keyboard is performed in software by the computer - after a make code is received, and until a break code is received, subject to the selected delay and repeat rate, the operating system sends additional keypresses to the application program.

So you would want make/break codes only as a means of getting keys to auto-repeat. Having a key that is held down instead emit repeated make codes would be highly inappropriate behavior when connected to a normally-configured IBM PC.

What am I missing here this time?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Tue, 29 September 2009, 15:59:26
Quote from: quadibloc;121508
I would have guessed that since there are controls for setting the repeat delay and repeat rate in Control Panel in Windows, typematic behavior on a PC keyboard is performed in software by the computer - after a make code is received, and until a break code is received, subject to the selected delay and repeat rate, the operating system sends additional keypresses to the application program.


Not so. The keyboard does it. What Windows does is send a  IOCTL_KEYBOARD_SET_TYPEMATIC to the keyboard driver, and the driver sends the appropriate command to the keyboard (0xf3, followed by a byte giving the encoded delay and rate).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 29 September 2009, 20:35:03
Well, it happened. (http://geekhack.org/showwiki.php?title=Island:7306)
(the mod article, that is)

If anyone figured out how to make tables work here, by all means fix my hack job. Thanks

This thread is still the place to post questions/info about progress/etc, it's too long to let die now :)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Tue, 29 September 2009, 22:36:20
Nice work on the wiki entry! It's great to have a main info page for these keyboards anyone can contribute to.

kishy, could you check for me what scancodes you get for the left alt key? KeyboardTest is saying it's "windows key code 133", "bios key code 113"

No matter what I try I can't seem to get this mapped. I'm not so 100% sure anymore that it's a win7 thing, but I'm starting to wonder if maybe there's electrical differences between our keyboards, or if maybe my ps2 controller interprets things differently or something... I can map alt to any other key on the keyboard, but not to the key labeled alt.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 30 September 2009, 10:10:41
Quote from: pseudolobster;121584
Nice work on the wiki entry! It's great to have a main info page for these keyboards anyone can contribute to.

kishy, could you check for me what scancodes you get for the left alt key? KeyboardTest is saying it's "windows key code 133", "bios key code 113"

No matter what I try I can't seem to get this mapped. I'm not so 100% sure anymore that it's a win7 thing, but I'm starting to wonder if maybe there's electrical differences between our keyboards, or if maybe my ps2 controller interprets things differently or something... I can map alt to any other key on the keyboard, but not to the key labeled alt.


Thanks:)

You bet, I'll figure it out for you once I'm home again (sometime this evening).

I really doubt there's an electrical difference between our keyboards; they are identical in every way. Though, I won't rule it out until we see what scancode mine reports.

Did you apply jumpers to the pins in your keyboard? This could, in theory, be part of the issue if not done (nobody is 100% sure yet, at least that they've said, what consequences come from not jumpering the pins)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Thu, 01 October 2009, 07:47:31
Okay, science completed successfully. I ran a continuity test on those cables last night and got the following:
Code: [Select]

      5 PIN    6 PIN
      (3179)   (PS/2)
      ------   ------
+5v   1 (BL)   4 (YE)
GND   2 (WH)   3 (RE)
PE    3 (xx)   3 (xx)
DATA  4 (RE)   1 (GR)
CLOC  5 (YE)   5 (WH)
xx             6 (xx)

I had a few moments of confusion until I realized that the connector chart I snagged from KBDBABEL showed the females and I was working with the males. So, if I get a few minutes tonight, I'll try rewiring and we'll see how it goes.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Fri, 02 October 2009, 22:32:55
Quick update...

I can confirm the patched driver does NOT work on win2k3 server R2 64bit, I'm pretty sure this is a 64bit problem and not a windows server problem. If and when I install VS and get around to trying to compile the driver myself, I'll see if I can compile a 64bit version... The original version of i8048prt.sys is some 74kb for windows 7 (32bit) while it's something like 91kb on server 2k3 x64.

Also I can't for the life of me get windows 7 to remap the alt keys, and I still can't map the down arrow key ("roll down") to anything... I'll try again next week with WinXP 32bit or something.. Failing that I'll try a different motherboard.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 02 October 2009, 23:27:16
Quote from: pseudolobster;122469
Quick update...

I can confirm the patched driver does NOT work on win2k3 server R2 64bit, I'm pretty sure this is a 64bit problem and not a windows server problem. If and when I install VS and get around to trying to compile the driver myself, I'll see if I can compile a 64bit version... The original version of i8048prt.sys is some 74kb for windows 7 (32bit) while it's something like 91kb on server 2k3 x64.

Also I can't for the life of me get windows 7 to remap the alt keys, and I still can't map the down arrow key ("roll down") to anything... I'll try again next week with WinXP 32bit or something.. Failing that I'll try a different motherboard.

Whoa, the original is 74kb in 7? Original in XP was between 50 and 55...what on earth could they have added to a PS/2 port driver...

I really suspect it's a Win7 thing going on with the alt and roll down keys...if that's not the cause, then I'd suspect motherboard, and if that's not it then it's definitely the keyboard (no way around it in that case). Obviously I'm at a bit of an advantage having two of the things so I can verify whether issues are inside the boundaries of the computer case or not using only the one computer.

Who's examined the matrix in one of these? Is it possible for a broken trace in one specific location to take out those specific keys?

(actually, scratch that, I just remembered pseudolobster said that the keys were sending scancodes. since they're sending scancodes which software can see it's a windows 7 thing almost certainly)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: microsoft windows on Sat, 03 October 2009, 07:05:14
I have a question:
You know how the keyboard unit of a 122 key keyboard plugs into the keyboard's mainboard with a ribbon cable. What happens if you plug that into a Model M mainboard?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Sat, 03 October 2009, 07:43:29
One of the ribbon cables is wider on a 122 key keyboard. If my understanding is correct, a keyboard appears as a matrix to the controller chip. Each key generates an x,y coordinate by sending a signal on two channels. The controller chip looks at the intersection of these two channels and sends the code it has for that location.

A 101 key model M is 8x16, a 122 key is 8x20.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 03 October 2009, 11:35:22
Quote from: microsoft windows;122538
I have a question:
You know how the keyboard unit of a 122 key keyboard plugs into the keyboard's mainboard with a ribbon cable. What happens if you plug that into a Model M mainboard?


Quote from: Shawn Stanford;122540
One of the ribbon cables is wider on a 122 key keyboard. If my understanding is correct, a keyboard appears as a matrix to the controller chip. Each key generates an x,y coordinate by sending a signal on two channels. The controller chip looks at the intersection of these two channels and sends the code it has for that location.

A 101 key model M is 8x16, a 122 key is 8x20.


Oh I just had one of those dangerous ideas...

I wonder how similar the matrix is between the two...what would happen if one were to remove the end from the ribbon cable connector so the longer one could fit? Obviously some keys (perhaps many) would not work, but would the normal 1391401-style area work as expected of a normal M?

I imagine there's a lot more to it than that, but one of those neat ideas to throw out there.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 03 October 2009, 12:59:26
Whoa...those are quite different, actually seeing them beside each other.

Hmm...wonder which keys would be lost.

(I'm currently installing Windows 98 on a generic Pentium MMX system using a 1386887 to see how well or poorly the process goes...already had issues at the DOS prompt because I couldn't type backslash...will post with successes/failures when it's done)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 03 October 2009, 14:16:05
Windows 98 with a 1386887

Some background first:
At some point in my "adventure" with the terminal keyboards, I read that Windows 98 had built in support for these keyboards. This could have been a very handy thing, finding someone to examine the Win98 driver and figure out every last step necessary in a finished, perfect driver for NT+

So I built a Pentium MMX system (typical baby AT motherboard, P-MMX 200MHz, 32MB PC66 RAM, 1mb graphics card, 2.5GB hard drive, CD-ROM)

Installed Win98. My process for this differs from most people; I first use the DOS prompt to copy the contents of the CD to C: then install directly from C: to itself (wayyy faster and more reliable). First problem: "D:\>copy win98 c:\win98" involves a backslash which I forgot the location of on this board (hint: it's left arrow). Hotplugged for a different keyboard which resulted in a very curious system lockup and LEDs sticking on on the keyboard. Had to fully power cycle the system. Weird.

During setup, the following keyboard layouts were possible choices. As you can see, none directly correspond to this keyboard or anything useful:

Code: [Select]
Albanian
Belarusian
Belgian (Comma)
Belgian (Period)
British
Bulgarian
Canadian Multilingual
Canadian Standard
Croatian
Czech
Czech (Programmers)
Czech (Qwerty)
Danish
Dutch
Estonian
Finnish
French
French Canadian
German (IBM)
German (Standard)
Greek
Greek IBM 220
Greek IBM 319
Greek Latin
Greek Latin IBM 319
Hungarian
Hungarian (101 keys)
Icelandic
Irish
Italian 142
Latin American
Latin American (Bolivia)
Latin American (El Salvador)
Latin American (Honduras)
Latin American (Nicaragua)
Latin American (Puerto Rico)
Latvian
Lithuanian (IBM)
Macedonian (FYROM)
Norwegian
Norwegian (Nynorsk)
Polish
Polish (Programmers)
Portuguese (Brazilian ABNT2)
Portuguese (Brazilian standard)
Portuguese (Standard)
Romanian
Russian
Russian (Typewriter)
Serbian
Slovak
Slovak (Qwerty)
Slovenian
Spanish Modern
Spanish Traditional
Swedish
Swiss French
Swiss German
Turkish (F type)
Turkish (Q type)
Ukranian
United States 101
United States-Dvorak
United States-LH Dvorak
United States-RH Dvorak

While none are obvious matches, does anyone know one which may be closer than US 101?

The sticking key (no break code) problems are obvious when using spacebar to select things...the button you're "clicking" will get stuck down and not come back up (without doing the intended action either), so hitting Enter (in this case Field Exit) is the only option.

Other than that, install went flawlessly. Remembered the product key off the top of my head...bad sign.

Now, investigating the "update device driver wizard" for the installed keyboard ("Standard 101/102-Key or Microsoft Natural Keyboard", uses: hidvkd.sys vmm32.vxd hidparse.sys hidclass.sys), I see almost all options are USB and there is no IBM category.

Something that caught my eye was Maxi Switch, though. Options are:

Code: [Select]
Maxi Switch, Inc. #1101
Maxi Switch, Inc. #1102
Maxi Switch, Inc. #2101
Maxi Switch, Inc. #2102

Do any of these correspond to, for example, the Maxi Switch keyboard with an active thread somewhere on the forum which is like a 122-key "tenkeyless"?

Going to the (Standard keyboards) category, I see the current selection, and also:

Code: [Select]
Compaq Enhanced Keyboard
HID-compliant keyboard
Olivetti Keyboard (102-Key)
Olivetti Keyboard (83-Key)
Olivetti Keyboard (86-Key)
Olivetti Keyboard (A101/102-Key)
PC/AT Keyboard (84-Key)
PC/XT Keyboard (83-Key)
PC/XT Keyboard (84-Key)

Just for kicks, I decided to try the PC/AT 84-key driver.
Cmd7 and 8 both became sleep!
Key sticking issues do still exist (I expected that). No functional changes have happened except for Cmd 7 and 8 changing like that.

I would say then, "myth busted" with regards to Win98 supporting the keyboard out of the box. However, it does "work" which is itself good...I wonder if there are key remaps in the Win98 registry.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: quadibloc on Sat, 03 October 2009, 18:31:10
Quote from: kishy;122617
While none are obvious matches, does anyone know one which may be closer than US 101?


All those layouts are for the same two physical keyboards - U.S. 101 and international 102 - so I'm afraid you won't get "closer" to a 122-key keyboard that way.

I know that in Windows 3.1, I once saw an entry for a 122-key keyboard choice somewhere in the Control Panel, but I'm not sure of the details.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 03 October 2009, 20:03:23
Quote from: quadibloc;122711
All those layouts are for the same two physical keyboards - U.S. 101 and international 102 - so I'm afraid you won't get "closer" to a 122-key keyboard that way.

I know that in Windows 3.1, I once saw an entry for a 122-key keyboard choice somewhere in the Control Panel, but I'm not sure of the details.

Well you realize what you've done now, right?
Time for DOS 5 and Win3.1! (not right now, right now I'm making a layout file for Passmark KeyboardTest)

Oh, and it turns out my missing rivets ARE a problem.

Springs and hammers are coming completely out of alignment, in some cases can't even buckle without me rearranging them and holding board at an angle. Looks like it's time for screws and nuts...


Edit:

Not directed at any one in particular, just everyone:
PassMark KeyboardTest layout complete - get it while it's hot! (http://www.plunder.com/3179-rar-download-15bc651433.htm)
Extract files and put in KeyboardTest program directory. Fire it up and hammer away. This is post-driver-replacement, pre-remaps, so if you don't have the driver replaced yet most of the keys won't be sending break codes (meaning a lot of the green in that pic will be red for you).

Interestingly, what would normally be numpad '-' doesn't send a scancode, but instead acts like Alt+PrintScreen. It can easily be remapped using the registry (hint: do this remap LAST!!! otherwise it will become broken when you remap alt and assign a key to print screen), but cannot be tested in the program as a result of not sending a scancode. Because of that I made that key appear yellow in the layout which signifies "not testable".
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 04 October 2009, 11:38:37
Here's an idea...

Is it at all possible to pass commands to a PS/2 keyboard on a USB converter?
If so...is a USB HID driver mod a possibility?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 04 October 2009, 12:32:20
Quote from: ripster;122856
I was dinking around with my 1397000 and originally I though the Blue Cube was passing the nonstandard (not on a 102 key keyboard) scan codes but I must have been mistaken.  On a recheck it didn't pass them to Windows at least.

Doesn't mean the hardware isn't seeing it though so maybe a HID mod would work.  I haven't seen a HID mod.


Well, to be clear on my intentions...

Refresher: the keyboard, in order to be rather usable (basically make it send break codes and NOT require hotplugging) needed the PS/2 driver altered to send certain commands (or not send certain ones, I forget). My hopes would be to be able to pass those same commands along to a keyboard on a USB converter (recall my rrrrrreeeeeeppppppeeeeeeaaaaaatttttt issues)

In other news, another myth busted. Windows 3.1 does not include out-of-the-box support for 122-key keyboards of any sort, but does allow you to add your own third party driver of course like 98, so this makes me wonder...did such a driver exist? Since people have these memories of support existing I'm sure such a thing must have at some point.

Code: [Select]

All AT type keyboards (84-86 keys)
AT&T '301' keyboard
AT&T '302' keyboard
Enhanced 101 or 102 key US and Non US keyboards
Hewlett-Packard Vectra keyboard (DIN)
Olivetti 101/102 A keyboard
Olivetti 83 key keyboard
Olivetti 86 key keyboard
Olivetti M24 102 key keyboard
PC-XT 83 key keyboard
PC/XT - type keyboard (84 keys)
Other (Requires disk provided by a hardware manufacturer)


Hey, check this out:
http://img24.imageshack.us/img24/9166/geekhackwin98.jpg
http://img194.imageshack.us/img194/751/geekhackwin31.jpg
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Sun, 04 October 2009, 17:14:16
There's a fair number of 122 key drivers out there, has anyone tried them?

http://www.listserv.uga.edu/cgi-bin/wa?A2=ind0403a&L=sas-l&D=0&P=34336
http://www.brothersoft.com/free-122-key-keyboard-driver-138279.html
http://download.cnet.com/Free-122-Key-Keyboard/3000-2110_4-198745.html

etc
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 04 October 2009, 17:24:39
Quote from: pseudolobster;122952
There's a fair number of 122 key drivers out there, has anyone tried them?

http://www.listserv.uga.edu/cgi-bin/wa?A2=ind0403a&L=sas-l&D=0&P=34336
http://www.brothersoft.com/free-122-key-keyboard-driver-138279.html
http://download.cnet.com/Free-122-Key-Keyboard/3000-2110_4-198745.html

etc

Thank you for the bookwork, though I should have mentioned I've looked as well.

The problem is those, at least the second two, appear to be for terminal emulation boards which actually work very differently.

Worth trying, of course, but the emulation boards already have the issues at hand fixed.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Sun, 04 October 2009, 17:32:34
Okay, well, I rewired that biatch and plugged it into one of the kids' computers and got nothing. Then I tried to other of their computers and got nothing. And now one of them (the 8 year-old) is complaining that her keyboard doesn't work.

Uh oh...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: msiegel on Sun, 04 October 2009, 17:36:03
:(

maybe the other ports still work?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 04 October 2009, 18:00:24
Quote from: Shawn Stanford;122956
Okay, well, I rewired that biatch and plugged it into one of the kids' computers and got nothing. Then I tried to other of their computers and got nothing. And now one of them (the 8 year-old) is complaining that her keyboard doesn't work.

Uh oh...


:( that doesn't sound good...

Are we talking about the one I sent you or the other older one?

The one I sent you should be no problem; 3488 terminals are compatible...at least according to kbdbabel.

The only thing I can think that could damage the controller interface on the computer is having voltage shorted to another pin...100% sure you have it wired right with no shorts?

I think I'll add somewhere a big notice informing people to test with an unimportant motherboard/computer first.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Sun, 04 October 2009, 18:17:35
Quote from: kishy;122961
The only thing I can think that could damage the controller interface on the computer is having voltage shorted to another pin...100% sure you have it wired right with no shorts?

Well, I was, now I'm not so sure... I figured the worst that could happen was that I'd burn out he controller on the keyboard. After all, if I'd wired it wrong it should send the 5v down the wrong line and fry the keyboard's circuitry.

Quote from: kishy;122961
I think I'll add somewhere a big notice informing people to test with an unimportant motherboard/computer first.
I did. :laugh:
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 04 October 2009, 18:21:43
Quote from: Shawn Stanford;122963
Well, I was, now I'm not so sure...

I did. :laugh:


Lol, well, as long as it's not a big loss for you...
If you do find you did something wrong and it was because of my instruction please let me know how to fix it, I took notes as I did the conversion so it should all be right, though possibly confusing in places.

Please do post about what your findings are.

Let's not eliminate the chance that the keyboard blew the motherboard fuse (they draw a lot of power, sometimes I get graphics glitches because my 22 amp card is fighting for power with a keyboard...problem goes away if I switch to a more normal keyboard, even a typical Model M)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 04 October 2009, 18:26:24
Quote from: Shawn Stanford;122963
Well, I was, now I'm not so sure... I figured the worst that could happen was that I'd burn out he controller on the keyboard. After all, if I'd wired it wrong it should send the 5v down the wrong line and fry the keyboard's circuitry.

I did. :laugh:


Since I caught your post before the edit, I'll reply again.

I think the keyboard controller (or more specifically fuse) on the motherboard is more susceptible to damage, though I may be wrong on that. They're probably both pretty vulnerable (mobo and kb, that is).

In either case, putting 5V on something not intended for 5V isn't good. Specifically, any situation where +5V is going straight to ground is going to cause an overcurrent and burn (hopefully just) the fuse on the mobo.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 04 October 2009, 19:23:11
Quote from: ripster;122977
Bad Daddy!
Show Image
(http://geekhack.org/attachment.php?attachmentid=4999&stc=1&d=1254701645)


Now I know you make these on an as-needed basis. There's no way you had that stashed away for a 'rainy day'.

Oh, forgot to mention, about power draw:
when I hotplugged the keyboard to the Pentium 1 rig I built, the power supply audibly began stressing to supply enough juice. I'm going to be rigging up my multimeter at some point...hmmm, voltage in parallel, current in series...let's hope I remember that right.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 04 October 2009, 21:43:59
In response to pseudolobster's request for an Alt key scancode...

Quote from: kishy;121664
Thanks:)

You bet, I'll figure it out for you once I'm home again (sometime this evening).

I really doubt there's an electrical difference between our keyboards; they are identical in every way. Though, I won't rule it out until we see what scancode mine reports.

Did you apply jumpers to the pins in your keyboard? This could, in theory, be part of the issue if not done (nobody is 100% sure yet, at least that they've said, what consequences come from not jumpering the pins)

Sorry! I completely forgot to do that. It's first on the list for next time I have desktop running.

Edit: which, as it happens, is right now.

Passmark KeyboardTest reports the following information:

For left ALT:
Windows key code: 233 (0xe9)
BIOS key code: 113 (0x71)

For right ALT:
Windows key code: 255 (0xff)
BIOS key code: 114 (0x72)

Something that may be relevant: the Reset/Cancl key is, pre-remapping, the sole Alt key. Its info is as follows:
Windows key code: 18 (0x12)
BIOS key code: 56 (0x38)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Mon, 05 October 2009, 06:20:54
Quote from: ripster;122977
bad daddy!
Show Image
(http://geekhack.org/attachment.php?attachmentid=4999&stc=1&d=1254701645)

bwahahahahahaha!
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Mon, 05 October 2009, 06:22:31
Quote from: kishy;122965
Since I caught your post before the edit, I'll reply again.

I think the keyboard controller (or more specifically fuse) on the motherboard is more susceptible to damage, though I may be wrong on that. They're probably both pretty vulnerable (mobo and kb, that is).

In either case, putting 5V on something not intended for 5V isn't good. Specifically, any situation where +5V is going straight to ground is going to cause an overcurrent and burn (hopefully just) the fuse on the mobo.


I think what I might try is swapping the controller board out of the Boscom and into the IBM.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 05 October 2009, 06:38:45
Quote from: Shawn Stanford;123067
I think what I might try is swapping the controller board out of the Boscom and into the IBM.

Argh, too many keyboards floating around my head.

Good luck with future science endeavours Shawn!

------------

Keyboard power info:

Voltage: around 4.6 in my test
Current: moves around a lot, but is typically around 196mA. Hit 200+ at high point, 193 at low point. No distinct change when pressing keys.

I'm pretty sure PS/2 spec is limited to 200mA, but I forget where I read that. If so, that means a lot of "poorly compliant" or simply "new" motherboards probably just can't do it. 200mA isn't a lot of power but if the mobo can't supply it, it may as well be.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Mon, 05 October 2009, 14:17:27
OH-KAY... Now we're getting somewhere...

This morning I installed a 32bit copy of WinXP and I'm pleased as punch to say I now have the use of my ALT keys!

I suppose it's bad news that we can't get things sorted out in Win7, I'm guessing that means all future versions of windows will have this problem.

I'm still getting used to this direction pad... It's a bit weird stretching your finger down for the down arrow key, and I find myself hitting the "enter" key by mistake.. Unfortunately if I try and remap this in KeyMapper, it decides to remap the actual enter key instead. I think I'm going to need to start over with the remapped layout since it does seem to make a difference what order you do things in.

Oh, and the home key ("dup") still gives a system beep. Odd.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 05 October 2009, 14:57:25
Quote from: ripster;123092
Just don't mess up your kid's computer.  I also don't experiment with my wife's computer - that's REALLY asking for trouble.


Fortunately I have neither problem, being only 19 and all.

Quote from: pseudolobster;123174
OH-KAY... Now we're getting somewhere...

This morning I installed a 32bit copy of WinXP and I'm pleased as punch to say I now have the use of my ALT keys!

I suppose it's bad news that we can't get things sorted out in Win7, I'm guessing that means all future versions of windows will have this problem.

I'm still getting used to this direction pad... It's a bit weird stretching your finger down for the down arrow key, and I find myself hitting the "enter" key by mistake.. Unfortunately if I try and remap this in KeyMapper, it decides to remap the actual enter key instead. I think I'm going to need to start over with the remapped layout since it does seem to make a difference what order you do things in.

Oh, and the home key ("dup") still gives a system beep. Odd.


That key will always give a beep because, as JohnElliott explained it to me (maybe publicly in thread, I forget) it sends the "error" key sequence as its break code (you may also notice it doesn't send a break code, and stays permanently "down"). Not easy to fix but if anyone can it's him...last I heard he was looking into it but didn't think it would be easy enough to be worth it.

Glad to hear it's working in XP...that means we have a fundamental Win7 compatibility issue to make note of. Probably the same for Vista...I can check when I have time.

On a side note, I now legally own Windows 7 both 32 and 64 bit versions courtesy of the MSDN Academic Alliance program my college now subscribes to. I have the ISOs and keys ready...testing time will come soon enough on my aging-but-still-competent computers. Of course, with OS testing also comes keyboard testing.

About that layout: yeah, it can be a bit of a mess sometimes, particularly if you position your hands properly on a keyboard (I never, ever do...I type with 2 fingers per hand (plus thumbs for space) and still manage to type quite quickly and with very few errors. When on the terminal board, I usually have one hand over the cursor keys anyway, so it ends up working out for me (I don't use a mouse for anything unless necessary).

I will at some point be integrating a facility for showcasing and providing remap files in the big mod article...still need to do the write-up on driver replacement though.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: msiegel on Mon, 05 October 2009, 15:05:35
hey kishy, speaking of terminal keyboard conversions... what do you make of this thing:
http://geekhack.org/showthread.php?p=123099#post123099
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 06 October 2009, 21:33:56
Quote from: msiegel;123196
hey kishy, speaking of terminal keyboard conversions... what do you make of this thing:
http://geekhack.org/showthread.php?p=123099#post123099


Was that just mentioned here for completeness, or did you post it before I mentioned it in that thread (and you acknowledged it)?

In any event I did reply there, but just to summarize the info here (for completeness):

Keyboard is for a 319x terminal; 319x terminal keyboards theoretically can be converted; conversion is possible

------------

HEY, LOOK AT ME!

If you use Passmark KeyboardTest, you may find this enjoyable:
http://passmark.com/download/keyboards.htm

Scroll down and find my layout :)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Wed, 07 October 2009, 20:43:13
Posting a pic of my layout for ****s and giggles... I need more clear keycaps for all the wonderful shortcut keys I intend to map to all these extra keys... I've started to think of this board as the poor man's optimus maximus in a way.

One of my ambitions is to figure out how to hook up status LED's to this, mount one under a key, add a clear keycap, figure out how to remap windows' "Change keyboard layout" hotkey to scrolllock, then make myself a "dvorak-lock" key so other people can use my computer without fiddling around with alt+shift and whatnot.

(http://geekhack.org/attachment.php?attachmentid=5053&d=1254965892)

The only things that've consistently bugged me about this keyboard so far is the lack of an escape key in the familiar location, and the lack of the distinctive "model M shelf" behind the F-keys where I normally stash pens and whatnot. It's nice that it has a beer coaster tray, but it's at a weird angle.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Rajagra on Thu, 08 October 2009, 07:01:36
Quote from: pseudolobster;123809
It's nice that it has a beer coaster tray, but it's at a weird angle.


We need more keyboards with cup holders. I think IBM were heading this way when they put drainage channels in the Model M, but never followed through.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ironcoder on Thu, 08 October 2009, 08:09:41
Quote from: pseudolobster;123809
The only things that've consistently bugged me about this keyboard so far is the lack of an escape key in the familiar location


Esc is a key that has no meaning in IBM-land. It's only on PCs that it's used so in one way it's amazing that any IBM keyboard has one at all.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Thu, 08 October 2009, 10:09:43
Quote
Esc is a key that has no meaning in IBM-land. It's only on PCs that it's used so in one way it's amazing that any IBM keyboard has one at all.

Yep, used to be 'Attn', but it was useless under VTAM. The PA1 key was more useful; which is why it's more closely tied to the main typing area.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 14 October 2009, 20:35:43
Hey pseudolobster, could use your help...

I'm trying to do the driver swap on Win7.

Even if I don't use the keyboard in Win7, it's necessary because the Win7 bootloader comes before the XP bootloader meaning Win7 kills the keyboard (necessitates a hot plug).

Booted into safe mode, took ownership of the necessary files, swapped it, rebooted. It might have worked because the keyboard was working at the 7 bootloader screen, but after booting into Windows nothing, it was dead. Checked device manager and I have a:

Quote

The software for this device has been blocked from starting because it is known to have problems with Windows. Contact the hardware vendor for a new driver. (Code 48)


I'm almost tempted to believe that's because of the lack of support for unsigned drivers. How did you go about it? Did you just use that utility that's floating around to "fake sign" the file or what?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Wed, 14 October 2009, 20:47:54
Hmm. That's odd.
You're using the 32bit version?

All I did is boot into a linux livecd and simply copy the file over, I didn't reset any permissions or anything, I didn't do anything to sign the file... It simply just started working after the first reboot.

I wasn't dual-booting, so I never ran into the bootloader issue, but if I'm not mistaken, I don't think that driver is loaded at that point, so it shouldn't make a difference.

I'm not sure if it matters, but I was using the release candidate, not the RTM version. In either case I'll give it another try on one of the Win7 machines at work tomorrow.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 14 October 2009, 21:10:47
Quote from: pseudolobster;125479
Hmm. That's odd.
You're using the 32bit version?

All I did is boot into a linux livecd and simply copy the file over, I didn't reset any permissions or anything, I didn't do anything to sign the file... It simply just started working after the first reboot.

I wasn't dual-booting, so I never ran into the bootloader issue, but if I'm not mistaken, I don't think that driver is loaded at that point, so it shouldn't make a difference.

I'm not sure if it matters, but I was using the release candidate, not the RTM version. In either case I'll give it another try on one of the Win7 machines at work tomorrow.

64 bit, but apparently that shouldn't make a difference anymore (it seems they also applied that same "no unsigned drivers" rule to 32 bit, but that was probably after RC)

Since it can't hurt I'll try a swap from a liveCD, I have Ubuntu stashed somewhere around here.

I also thought the driver wouldn't be loaded yet at the bootloader but I had at least a few times where it didn't work on that screen (may just be because the keyboard was "killed" during a session in xp x64 during the same power-on session, I've been rebooting and switching operating systems multiple times per hour today)

Edit: it appears you're right, the bootloader doesn't care about the driver.

And I can't access my hard drive with Ubuntu 8.10. "Unable to mount location", "Internal error: No mount object for mounted volume"

Not the end of the world; in reality it shouldn't make a difference, it's still the same file either way.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Wed, 14 October 2009, 23:18:44
Yeah, I'm 99% sure it's a 64bit problem then... A 64bit OS is good at running 32bit programs in userland, but any kernel stuff like drivers needs to be compiled for 64bit.

I'll try the driver on a 32bit copy of the RTM version at work tomorrow and I'll keep you posted.. I'm cautiously optimistic it'll work fine.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Fri, 16 October 2009, 13:41:54
Quote from: Shawn Stanford;123067
I think what I might try is swapping the controller board out of the Boscom and into the IBM.

Okay, when we last left Our Hero, he had rewired an IBM Model M 1390572 with a PS/2 connector from a defunct keyboard and - on testing - succeeded in causing a seemingly-permanent crippling of the keyboard port on his younger daughter's PC (she is now using Rip's 'Bad Daddy' vignette as her desktop).

I have since received an IBM Model M 1394167 from Kishy and I have the following report:

1. I've heard the Model M called a 'battleship' and the 122-key terminal emulation Model M's 'aircraft carriers'. If that's the case, then the 1390572 is a super carrier, since it has a full inch in width and length on the 1394167.

2. The 1394167 is the 'father' of the Boscom 122 BO40B56 that I've been using for a few weeks. The internals on those two are very similar, while the guts of the 1390572 are different. The biggest difference between the Bos and the IBM is that the plastic keywell on the Bos has the 'drainage channels', where the IBM doesn't. Both cases, however, have the 'drainage holes' at the front.

3. I pulled apart the 1394167 and while the controller was completely different, it had the same ribbon inputs and the same six-pin cable connector. Since Kishy had said that the conversion of his keyboard amounted to splicing in a new cable, I decided to swap the controller from the 4167 into the 0572, along with the cable I'd cobbled together. I confirmed that the cable pinouts matched what I had written down for the six-pin connector on the board and put everything together.

The question of course was: where to test it? I didn't want to risk one of the adult's computers (mine, my wife's, my son's) and Trinity's computer was already broken (Bad Daddy!). That left Shelby's computer. I hemmed and hawed for a minute; but reasoning that I could always plug in a USB keyboard (such as that now sported by Trinity's computer), I gave it a try. I plugged it in, booted, launched NotePad and experimentally whacked at a couple alpha keys.

IT FREAKIN' WORKS!

I was able to use all the alphanumeric keys (and without any of the odd repeating that Kishy had). The function and special keys are different, so they'll need investigated and remapped. But, I think we've got a winner!

For the curious, the dimensions of the keyboards in question are:

Model M 101 Key: 19.25 x 8.25 x 1.75
Model M 1394167: 20.75 x 8.5 x 2.25
Model M 1390527: 22 x 9 x 2.25

For the morbidly curious: I'll post the remapping results when I get that done.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: itlnstln on Fri, 16 October 2009, 13:43:55
Congrats!  Good Daddy.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 16 October 2009, 16:55:25
Awesome Shawn, glad to hear it worked. The repeat issues by the way were only when attached to a USB converter; Windows was smart enough (for once) to identify I didn't want to repeat the keystrokes when on PS/2 alone.

Yeah, the old-style ones are way bigger. In a sense that's part of the appeal to me; it's so ridiculously impractical I just had to use it lol.

Did you figure out exactly what went wrong the first time Shawn?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Sat, 17 October 2009, 05:33:33
No, I'm not sure what when wrong the first time. Maybe the keyboard wasn't sending the right scancodes?

I have it plugged in to my son's computer now that it has been proven safe and the scancodes are completely freaking Windows out. I've just started looking at it, but I can tell that the left hand keybank are scanning as F1 through F10 (and they send make codes, but no break codes) and that the top row CMD keys throw unknown scan codes. The Ctl, Alt, Shift and CapsLock keys are also seemingly mixed up. This could definitely take some screwing around to get right, and I'm not sure it's worth the effort.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: quadibloc on Sat, 17 October 2009, 06:37:58
Quote from: Shawn Stanford;126112
succeeded in causing a seemingly-permanent crippling of the keyboard port on his younger daughter's PC (she is now using Rip's 'Bad Daddy' vignette as her desktop).


If she is still able to use the computer... ah, she is probably limping along with one of those newfangled USB keyboards.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 17 October 2009, 09:18:46
Quote from: Shawn Stanford;126313
No, I'm not sure what when wrong the first time. Maybe the keyboard wasn't sending the right scancodes?

I have it plugged in to my son's computer now that it has been proven safe and the scancodes are completely freaking Windows out. I've just started looking at it, but I can tell that the left hand keybank are scanning as F1 through F10 (and they send make codes, but no break codes) and that the top row CMD keys throw unknown scan codes. The Ctl, Alt, Shift and CapsLock keys are also seemingly mixed up. This could definitely take some screwing around to get right, and I'm not sure it's worth the effort.


Everything you described there is quite normal; the keyboard functions like an 84-key AT keyboard by design (consider what keyboard design existed when the original design was being worked out in the 80s).

The break codes are resolved by using John's modified keyboard driver, (his website) (http://www.seasip.info/VintagePC/ibm_1390876.html) or you could go check out the article I wrote in the mods area (I believe, if I'm not mistaken, I threw a download link in there).

Swapping said driver into place, well, I'm still half asleep so let's not go there yet. Expect to be putting that info in the mod article this coming week, but no promises.

(all that assumes Windows XP or 2000, previous will probably be a no-go, and newer will probably not cooperate as much as we'd like)

As for keys being all mixed up, that's where you've got to remap keys via the Windows registry (or your preferred method). The registry-based mappings are certainly more permanent than some methods, but can still be undone later. Keep in mind they apply globally to all keyboards so if you plug in a normal keyboard after, it will be all mixed up because of the remaps you did for the terminal board.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ch_123 on Sat, 17 October 2009, 09:23:40
I was thinking the other day - would it be possible to design some kind of microcontroller to interface between the keyboards controller and the computer that would do all the scancode translation?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: pseudolobster on Sat, 17 October 2009, 11:05:22
Sorry kishy, I meant to test that driver with win7 on a different computer at work, but never got around to it, incredibly busy. I might just go in tomorrow to catch up on some work, so I might give it a shot then. Still, I do think it's a 64 bit problem you were having.

Quote from: ch_123;126338
I was thinking the other day - would it be possible to design some kind of microcontroller to interface between the keyboards controller and the computer that would do all the scancode translation?

Yep, that's a work in progress.. http://www.kbdbabel.org/
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 17 October 2009, 13:36:01
Quote from: ch_123;126338
I was thinking the other day - would it be possible to design some kind of microcontroller to interface between the keyboards controller and the computer that would do all the scancode translation?


See pseudolobster's reply. I intend to make one of those actually; the problem is I don't have the resources to at this time.

Quote from: pseudolobster;126353
Sorry kishy, I meant to test that driver with win7 on a different computer at work, but never got around to it, incredibly busy. I might just go in tomorrow to catch up on some work, so I might give it a shot then. Still, I do think it's a 64 bit problem you were having.


Do it at your convenience, please.
It very well may be a 64 bit problem, but it doesn't make sense if it is...a keyboard driver is so low-level it should be identical for either 32 or 64 bit versions. Silly Microsoft.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Mon, 19 October 2009, 10:14:45
So, I lugged the IBM Model M 1390572 into work to plug it into the PS2-USB adapter and, sure enough, the repeat problem reared its head. So, the supercarrier is relegated to a corner of my cube for now, and I'm back to a 'plain' Model M (Not so plain: it's sporting a hot rod red case. Ha!).

I read back through the thread and if I understood correctly, Ripster had fewer or no problems while using the Blue Cube adapter. I've ordered one from Amazon and we'll make another assessment when it arrives.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 19 October 2009, 12:45:20
Quote from: Shawn Stanford;126854
So, I lugged the IBM Model M 1390572 into work to plug it into the PS2-USB adapter and, sure enough, the repeat problem reared its head. So, the supercarrier is relegated to a corner of my cube for now, and I'm back to a 'plain' Model M (Not so plain: it's sporting a hot rod red case. Ha!).

I read back through the thread and if I understood correctly, Ripster had fewer or no problems while using the Blue Cube adapter. I've ordered one from Amazon and we'll make another assessment when it arrives.


The fundamental problem is of course that the keyboard, at least with the software configuration you are using, is not sending break codes for its keys. For some reason I don't entirely understand, Windows does not interpret the "held down keys" as being repeating if it's connected to a PS/2 port. However, something about those cheapo PS/2-USB converters causes the keys to repeat for a certain number of times (if you don't interrupt it, it always repeats the same number of times and stops after...the USB converter then sends a break code for the key after the repeating finishes).

The problem is the keyboard...but if these "blue cube" adapters somehow correct the problem, I may get one and do a "USB mod" on a terminal board lol.

Quote from: ripster;126856
My 1397000 review has all the detailed scancodes for what I got.  Each had a make and break.


Did you have ANY repeat issues, where there was some sort of delay in the break code showing up? I could probably go and read it there but it's probably something useful to have in this thread as well.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 19 October 2009, 13:01:41
Quote from: ripster;126912
If you have a suggestion for a test I'm more than willing to try it.  I think all I did was hold down a sampling of keys and make sure they repeated.  Then I made sure the next keypress on another key registered.


Hmm...it seems that was probably extensive enough to figure out it works.

The problems I had with my converter were quite obvious...if you hit a key, just any random one, that key would repeat something like 8 times (roughly, I forget). You could prevent the repeating by typing fluently with no delay between key presses, but as soon as you stopped typing for even the slightest delay, it would repeat the last key pressed.

So I guess no further testing needed...but if you have some time to mess with it I'd say to make note of any problems you do find that maybe were overlooked before.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Mon, 19 October 2009, 14:32:31
I'm guessing that the Blue Cube is a little brighter than the average PS2-USB converter (I think Rip said as much in a thread somewhere). It would be interesting to see the source code.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ironcoder on Tue, 20 October 2009, 02:54:48
Source code!? We don't need no stinkin' source code!

(sorry, that's what came to mind!)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: IBMMuseum on Wed, 21 October 2009, 22:04:53
Ok, I´m jumping in on the thread, Kishy made me aware of it from another forum. I´m also had a little correspondence with John about the 3270 PC system, where these keyboards came in to connect up to the PC. My interests are still vintage, and my focus for now is about connecting the terminal keyboards (even though I do have an IBM ¨Host Connect¨ 122-key keyboard) to the IBM PS/2s.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ironcoder on Thu, 22 October 2009, 02:40:40
Lemme be the first to welcome you to this awesome forum!
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 23 October 2009, 17:50:17
Quote from: IBMMuseum;127526
Ok, I´m jumping in on the thread, Kishy made me aware of it from another forum. I´m also had a little correspondence with John about the 3270 PC system, where these keyboards came in to connect up to the PC. My interests are still vintage, and my focus for now is about connecting the terminal keyboards (even though I do have an IBM ¨Host Connect¨ 122-key keyboard) to the IBM PS/2s.

First let me apologize for not acknowledging your great information on the other site (http://www.vintage-computer.com/vcforum/showthread.php?t=17788) yet; I've been a bit busy and trying to keep track of a lot of stuff so it's best to keep one idea at a time in mind.

Regarding PS/2s, that's something I'm interested in, though my Model 56 is going to be leaving me at some time in the future. The 30-286 will remain.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: IBMMuseum on Sat, 24 October 2009, 01:56:24
Quote from: kishy;127959
First let me apologize for not acknowledging your great information on the other site (http://www.vintage-computer.com/vcforum/showthread.php?t=17788) yet; I've been a bit busy and trying to keep track of a lot of stuff so it's best to keep one idea at a time in mind.

Regarding PS/2s, that's something I'm interested in, though my Model 56 is going to be leaving me at some time in the future. The 30-286 will remain.


Before the Model 56SX leaves your hands, I need you to run a DOS program for me if possible (it has the 122-key keyboard support, the Model 30 286 does not). I´m having some roadblocks come up with the terminal keyboard types I have, and have to study all the variables more. But the information I am learning (understand that I was looking at a small part of this more than four years ago, to put information about the Keyboard IDs online) is great.

One very amazing thing to me is that the keyboard PCB for my part number 6110345 Model F terminal keyboard (screwing cylinder shield on the plug for a 3270PC or 3180 terminal) is exactly the same as the keyboard PCB in the 84-key AT keyboard. There are rows for jumpers to apparently set the Keyboard ID, but the last (of the B-row) seems like it is also associated with the lock lights. I´ll connect it to one of my ATs tomorrow to see how things work.

The 1389162 keyboards I have look like a very similiar keyboard PCB to your 1386887 model. I still get errors (currently a 306) that doesn´t let me test further though. I have far more 1390876 (right-angle plug) and 1395660 (RJ-45, which may end up being the easiest cable to work with for that reason) to run through for tests.

Ultimately I hope for some sort of compilation of models for what works...

I haven´t had much time in this last week either...

Now that the weekend has arrived I hope to devote more attention to it...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 24 October 2009, 10:24:28
Quote from: IBMMuseum;127985
Before the Model 56SX leaves your hands, I need you to run a DOS program for me if possible (it has the 122-key keyboard support, the Model 30 286 does not).


Well...no, the Model 56SX has support for 122-key host connect keyboards which are quite different from real terminal keyboards that have had their cord swapped. I'm 100% positive that I'll get an equal level of compatibility on the 30-286 because the keyboard will function like an 84-key AT keyboard, exactly like it does on my Athlon64 system.

It's important not to lump all of these things together as just "122-key" because there are significant differences between the host connect boards and the "real thing", which is what I have.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Sat, 24 October 2009, 12:56:50
Quote from: IBMMuseum;127985
One very amazing thing to me is that the keyboard PCB for my part number 6110345 Model F terminal keyboard (screwing cylinder shield on the plug for a 3270PC or 3180 terminal) is exactly the same as the keyboard PCB in the 84-key AT keyboard. There are rows for jumpers to apparently set the Keyboard ID, but the last (of the B-row) seems like it is also associated with the lock lights. I´ll connect it to one of my ATs tomorrow to see how things work.


My guess is that the difference comes in the microcontroller programming -- in the 122-key version, those lines are configured as input lines for the keyboard ID jumpers, and in the 84-key version they're configured as output lines for the LEDs. What we'd need is dumps of the keyboard microcontroller ROM, if anyone's got the knowledge to obtain that and then interpret it.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 24 October 2009, 14:18:57
Quote from: kishy;128008
Well...no, the Model 56SX has support for 122-key host connect keyboards which are quite different from real terminal keyboards that have had their cord swapped. I'm 100% positive that I'll get an equal level of compatibility on the 30-286 because the keyboard will function like an 84-key AT keyboard, exactly like it does on my Athlon64 system.

It's important not to lump all of these things together as just "122-key" because there are significant differences between the host connect boards and the "real thing", which is what I have.


I've since tried the board on my 30-286 and was surprised to find it works the same as it does on my Athlon64 desktop, quite probably because the 30-286 was never designed to support 122-key keyboards (therefore the keyboard can function, unlike a properly supporting computer would expect, as an 84-key AT)

On the 56SX (this time with Win95) it still types garbage, apparently because the 56SX by design supports 122-key keyboards, but this keyboard is of course behaving like an 84-key AT rather than a host-connect (there's probably more to it than that though).

Quote from: JohnElliott;128029
My guess is that the difference comes in the microcontroller programming -- in the 122-key version, those lines are configured as input lines for the keyboard ID jumpers, and in the 84-key version they're configured as output lines for the LEDs. What we'd need is dumps of the keyboard microcontroller ROM, if anyone's got the knowledge to obtain that and then interpret it.


I'm willing to send one of my PCBs to someone with this ability so long as they cover shipping there, I pay shipping back.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: IBMMuseum on Sat, 24 October 2009, 21:51:36
Quote from: JohnElliott;128029
My guess is that the difference comes in the microcontroller programming -- in the 122-key version, those lines are configured as input lines for the keyboard ID jumpers, and in the 84-key version they're configured as output lines for the LEDs. What we'd need is dumps of the keyboard microcontroller ROM, if anyone's got the knowledge to obtain that and then interpret it.


If I can have someone confirm my keyboard PCB berg connector - My 84-key AT keyboard isn´t working with the connection either (but 101s with an SDL and cable are). Here is what I have:

Shield (or unused)....o.....o...5 volts
.................Clock....o..o..o...Data
.................Ground on center pin

This is as it is on the PCB, and http://www.bbdsoft.com/keyboard.html for the AT keyboard connector...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 24 October 2009, 22:06:11
Looks right to me IBMMuseum.
http://geekhack.org/showwiki.php?title=Island:7306

Code: [Select]
NO CONN .   . +5VDC

  CLOCK . . . DATA    BETW/ CLK & DATA: GND
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: IBMMuseum on Sun, 25 October 2009, 00:08:14
I have figured out the Keyboard ID settings on the terminal keyboard PCB below - A reverse of the jumpers on other PCBs:

(http://www.ibmmuseum.com/OhlandL/keyboard/Terminal_PCB_1391329.jpg)

In the upper right-hand corner there is the metal piece inserted into the socket. Default ID (all pins in the socket) is 8080. The high order bits start on the right, and progress as you go to the left (A0 and A1 are set to ´10´, as you go left it is A2, A3, A4, etc.).

For instance, you leave the double-pin furthest right in the socket as the picture has it straight. Your first byte (8, as in 86AB) is already correct, so also leave the next two (single) pins down: 1000b, 8h.

The next byte of the ID would be 6h for the Host Connect keyboard. Leave the first pin (A4) of the byte straight, bend the next two out of the way (A5  = ´1´, A6 = ´1´), A7 is left straight.

To set the third byte of the Keyboard ID, bend B2 out of the way. B3 stays straight. Since B0 and B1 are ´10´, the byte comes out as 1010b, Ah.

Bend B4, B6, and B7 out of the way. That gives 1011b, Bh. All told we now have 86AB.

From the aspect of the picture (in reverse order from above) I will give a diagram. The double-pin on the right of the socket will be shown as ´II´ at the end of the sequence. Bent (or removed) pins will be shown as ´x´:

B7 -> B2, A7 -> A2
xxIxIxIxxIIII
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Shawn Stanford on Mon, 26 October 2009, 06:56:46
Well, the Blue Cube arrived over the weekend and I plugged it in first thing at work and the keys still repeat. I guess I'll take it home and mess with it there for now. I didn't set any jumpers on the controller - I'm not even sure there are any, so that's the first thing I'll look at when I get home.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Mon, 26 October 2009, 20:37:08
Quote from: Shawn Stanford;128297
Well, the Blue Cube arrived over the weekend and I plugged it in first thing at work and the keys still repeat. I guess I'll take it home and mess with it there for now. I didn't set any jumpers on the controller - I'm not even sure there are any, so that's the first thing I'll look at when I get home.


I'm inclined to believe it won't make a difference, but hopefully it will. As pointed out by IBMMuseum, possibly here or possibly on the vintage computer forum, where I have placed a jumper on B5, put it on B7 instead (all the others remain the same as I have shown however)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: IBMMuseum on Mon, 26 October 2009, 22:52:11
Quote from: kishy;128480
I'm inclined to believe it won't make a difference, but hopefully it will. As pointed out by IBMMuseum, possibly here or possibly on the vintage computer forum, where I have placed a jumper on B5, put it on B7 instead (all the others remain the same as I have shown however)


I´m more inclined to think John is most correct. IBM had jumpers in place for expansion of Keyboard IDs and lock LEDs, but never really followed through on implementation of the former (or it was directed at other markets, like the Japanese areas). The scancode set (and thus the reported Keyboard ID) is determined through some other method than the ID.

By some luck, your 56SX is partially satisfied (in the hardware identification) by the jumpers, but doesn´t get the scancode set correctly...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: microsoft windows on Sat, 14 November 2009, 19:41:23
I've got to get myself one of these 122-key terminal behemoths someday.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: sethstorm on Wed, 25 November 2009, 19:55:01
Quote from: kishy;132575
Lol, random. They're great fun though...it's like a 1391401 on crack.

Got one on order after seeing one favorably priced and seeing this guide.  Your documentation already seems to confirm that these boards are what you just said - 1391401's on crack.

I just hope for my sake that I get the wiring and pins right, despite it looking easy to wire up.

The only spare cable I have at the moment is attached to a sparsely documented and fitting NCR Decision Mate V keyboard(NCR H0150-STD1-01-17).  It has the ground and similar wire colors, just that it's soldered right on the board.  

I'd be using the metal AT->PS/2 barrel adapter that clickykeyboards sells, if that made any sense.  Would it do the right thing with the keys if I got the AT pins right?  Or would I be better off finding a proper PS/2 cable, even if it's horribly off in wire color?



sort of O/T note:
No, it's even more proprietary than your legendary terminal keyboards but has similar wire colors and labels right where it's soldered to the board.  But it has a nice AT-din style cable.  

Relevant pictures can be provided if wanted.  Yes, the circa 1983 NCR board looks surprisingly close to a Cherry in case format, but sadly has soldered low-profile spring switches and a proprietary controller that I've probably erased.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 25 November 2009, 20:22:17
Quote from: sethstorm;136331
Got one on order after seeing one favorably priced and seeing this guide.  Your documentation already seems to confirm that these boards are what you just said - 1391401's on crack.

I just hope for my sake that I get the wiring and pins right, despite it looking easy to wire up.

The only spare cable I have at the moment is attached to a sparsely documented and fitting NCR Decision Mate V keyboard(NCR H0150-STD1-01-17).  It has the ground and similar wire colors, just that it's soldered right on the board.  

I'd be using the metal AT->PS/2 barrel adapter that clickykeyboards sells, if that made any sense.  Would it do the right thing with the keys if I got the AT pins right?  Or would I be better off finding a proper PS/2 cable, even if it's horribly off in wire color?



sort of O/T note:
No, it's even more proprietary than your legendary terminal keyboards but has similar wire colors and labels right where it's soldered to the board.  But it has a nice AT-din style cable.  

Relevant pictures can be provided if wanted.  Yes, the circa 1983 NCR board looks surprisingly close to a Cherry in case format, but sadly has soldered low-profile spring switches and a proprietary controller that I've probably erased.


Hi there

What part number are you expecting to get? I imagine you mean 1386887, perhaps the one I show links to on ebay from time to time (they're certainly priced alright)

The wiring, I must just be bad at explaining it. It's really quite simple but it's easy to get confused and mess it up if you misunderstand the way I've presented it. If you have any doubts just post and I'll get to it the same day or next.

I think the adapter you mentioned will be fine since it's just a dumb adapter; electrically it is the same thing as using a PS/2 cable to begin with. One of my two is done that way and works fine. Of course, for convenience you may want to consider just doing a PS/2 cable entirely if you'll never try to use it on a machine with an AT port.

If I could recommend something, go to a local thrift store or similar and try to find a cheap $2 keyboard. This gives you a nice length of cable that wouldn't be a big loss if it became unusable somehow during the mod (I can't see how it would, but it doesn't hurt to be safe).

Search for your keyboard on the forum. If nobody has struck up a thread before, start one with photos. People here love photos :)
Plus, if you start a thread, it gives you a place to organize info about conversions and the like. Is it possible it's XT? (I don't know the machine)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: sethstorm on Thu, 26 November 2009, 01:51:52
Quote from: kishy;136333
Hi there
What part number are you expecting to get? I imagine you mean 1386887, perhaps the one I show links to on ebay from time to time (they're certainly priced alright)
That's the one, and it's from one of puravida1881's ebay sales.

Quote from: kishy;136333
The wiring, I must just be bad at explaining it. It's really quite simple but it's easy to get confused and mess it up if you misunderstand the way I've presented it. If you have any doubts just post and I'll get to it the same day
or next.
Well, it's more of the mappings between the connectors, which you have good references to.  If I end up having to create a diagram of it (from berg strip end to PS/2 or AT connector) just to be sure, so be it.

Quote from: kishy;136333
I think the adapter you mentioned will be fine since it's just a dumb adapter; electrically it is the same thing as using a PS/2 cable to begin with. One of my two is done that way and works fine. Of course, for convenience you may want to consider just doing a PS/2 cable entirely if you'll never try to use it on a machine with an AT port.

If I could recommend something, go to a local thrift store or similar and try to find a cheap $2 keyboard. This gives you a nice length of cable that wouldn't be a big loss if it became unusable somehow during the mod (I can't see how it would, but it doesn't hurt to be safe).
Then it sounds like there's no problem at all.  Besides, my locality has a good deal of electronics surplus, so no problem finding the proverbial cheap keyboard.  To think of it, I might have a lot of the spare parts on hand.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: sethstorm on Tue, 01 December 2009, 00:22:42
I've gotten another 1386887 to work and map out keys - only thing missing is repeat.

However, one might want to make sure other things that remap the keyboard are not in the way - as they were doing so w/ mine.  Uninstalled them (Logitech Setpoint, Razer[yes...]) and now get all the keys that should respond.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 01 December 2009, 06:40:19
Quote from: sethstorm;137682
I've gotten another 1386887 to work and map out keys - only thing missing is repeat.

However, one might want to make sure other things that remap the keyboard are not in the way - as they were doing so w/ mine.  Uninstalled them (Logitech Setpoint, Razer[yes...]) and now get all the keys that should respond.


Yay, another success story.

Interesting info about the "other software"...that's something we'll have to collectively work on (everyone active on this topic) documenting in detail. It's possible that the scancodes of funky extra keys don't get sent (at least not properly) when the software is running (that's what I would see the biggest issue being, at least).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: sethstorm on Tue, 01 December 2009, 18:11:33
Quote from: kishy;137701
Yay, another success story.

Interesting info about the "other software"...that's something we'll have to collectively work on (everyone active on this topic) documenting in detail. It's possible that the scancodes of funky extra keys don't get sent (at least not properly) when the software is running (that's what I would see the biggest issue being, at least).


I'd have to thank you for documenting the whole thing quite well.


I removed(as listed in Add/Remove Programs):
Logitech SetPoint
Razer Keyboard software

I'd mark both of those as suspect, especially setpoint, until there's further confirmation on how they affect layout.  Cmd15/16 and Cmd 11/12 required some strange keypresses to work if you want something of a known outcome for which to test that software.

As for good key remapping software:
You might want to try something like InputRemapper to bring back key repeat and better custom key bindings.  It does not interfere with Key Remapper afaik.  Installed it, rebooted, added a new(blank) remapping table, and it gave me repeating keys as well as not interfering with existing drivers/software.

Notes on the hardware conversion:
If berg strips/connector housings weren't so rare to have on hand at a moment's notice, things would be a bit better; I was able to find a substitute that works at the local electronics surplus store(2 3 pin low profile connectors).
At the worst, I can just cut an AT extension cable in half, put a strain relief on it, and then throw on the appropriate adapter.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: sethstorm on Tue, 08 December 2009, 11:49:00
While poking in the 2003 SP1 DDK to build the new driver, I noticed that there were a few differences in the API.  That is, to answer someone's question before, it is different - but not enough to result in a non-working

The diff did not apply cleanly, but I was able to hand-patch the pnpi8042 sample.  I ended up having to remove a lot of the (unused) reset code and the failedAllRepeat error check.

Attached is the resulting i8042prt.sys and the diff files for i8042prt.h and kbddep.c.  If there's any legal issues, I don't know of them (reading in this thread).  I merely wanted to prove that it is possible to get working results with a more recent DDK than the (now-unavailable) Windows 2000 DDK referred to by JohnElliott earlier in the thread.  

Aside from the modifications needed to get it to work, it is the same file with the same functionality.

I do plan to look further and see if things can be remapped around to their rightful places (and then some), perhaps to solve that Dup / Blank key issue.


Tested:
Vista x86 w/ InputRemapper (so you can get those nice key repeats).

Note:
As a bit of a recommendation, I'd grab the Windows 2003 SP1 DDK off of the Archive section of Windows Connect download section (for the newly named WDK) while it's still there.  It's the only one that has not dropped Windows 2000 support AFAIK.  It shouldn't require a subscription to MSDN to get it.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 08 December 2009, 17:03:47
Would love a direct link please (DDK). It wasn't anywhere on the entire internet, especially any MS website, last time I looked (and I spent about a week looking too).

Obviously I didn't look hard enough...but I looked very thoroughly I thought. No search engine is indexing it, that's for sure.
Title: Obtaining, modifying and building DDK items.
Post by: sethstorm on Tue, 08 December 2009, 22:54:43
Quote from: kishy;140243
Would love a direct link please (DDK). It wasn't anywhere on the entire internet, especially any MS website, last time I looked (and I spent about a week looking too).

Obviously I didn't look hard enough...but I looked very thoroughly I thought. No search engine is indexing it, that's for sure.

Here you go, a well-formatted guide to finding and using the DDK.  Let me know if it's too complicated, but it should have most if not all the necessary information to get from bare metal to working driver.

(A more recent version can be found here (http://geekhack.org/showwiki.php?title=The+Windows+DDK+Keyboard+driver+build+instructions))


Preliminary instructions:

Only thing you'll need to do is have a Windows Live ID(no charge) and be willing to add the Microsoft Connect service(no charge) to it.  Once you have that, you should be able to grab the SDK you need, which is named "1830_usa_ddk.iso".  You do not need to grab the other versions to use the DDK.

https://connect.microsoft.com/site148/Downloads/DownloadDetails.aspx?DownloadID=21028 (https://connect.microsoft.com/site148/Downloads/DownloadDetails.aspx?DownloadID=21028)

Further Instructions:


Install:
Select Custom install, go to samples -> input -> items relating to 8042 input sample and add those.  If you want to add the USB one, go right ahead - but the relevant sample is the 8042 one.
Install to the default directory it gives you: (e.g. C:\WINDDK\3790.1830)

Modification:
The files you need will be here if you installed with the default path.
Code: [Select]
C:\WINDDK\3790.1830\src\input\pnpi8042
Build:
Open a command prompt, go to C:\WINDDK\3790.1830\bin\
Run this at the command prompt to setup the build environment:
Code: [Select]
setenv.bat C:\WINDDK\3790.1830 fre halFrom there, change directory to ..\src\input\pnpi8042
run build.exe with no options (or if you wish, add options)

Result:
If build went through w/o error, it will be at:
Code: [Select]
C:\WINDDK\3790.1830\src\input\pnpi8042\daytona\objfre_wnet_x86\i8042prt.sys
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 19 December 2009, 14:33:39
I may have mentioned this, but yeah, I got another 1386887. I'm guessing there were a flood of them from some plant that closed because this is yet another made on the exact same day with a rather close serial number to my existing two.

When I got the 1394167 (w/RJ11 plug) I had taken a keycap I was missing, the SetUp key from the left block of 10 keys. The -4167 has that key in black letting however, so it wasn't "original spec" on the 1386887. I've now swapped the black one off of the one I'm using and put it on the new keyboard, while the blue lettering one off the new keyboard has gone onto the one I use.

Also, I've harvested the Cmd14 key, since I was missing it.

My intention at this point in time, assuming a reasonable number of rivets are still present, is to do the hardware conversion on the new keyboard and sell it to a geekhacker. I would sell it pre-conversion though, just PM me. Yes, I got it cheap (within my normal keyboard price limits) but will be seeking to make a profit on it. I will do my best to undercut prices on equivalent keyboards when that time comes.

(http://geekhack.org/attachment.php?attachmentid=6527&stc=1&d=1261254772)

(http://geekhack.org/attachment.php?attachmentid=6528&stc=1&d=1261254772)

Compare this sticker with the ones I provide in my signature. I wonder how many more are lurking around my city?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: sethstorm on Sun, 20 December 2009, 16:09:20
Quote from: kishy;143735
I may have mentioned this, but yeah, I got another 1386887. I'm guessing there were a flood of them from some plant that closed because this is yet another made on the exact same day with a rather close serial number to my existing two.

When I got the 1394167 (w/RJ11 plug) I had taken a keycap I was missing, the SetUp key from the left block of 10 keys. The -4167 has that key in black letting however, so it wasn't "original spec" on the 1386887. I've now swapped the black one off of the one I'm using and put it on the new keyboard, while the blue lettering one off the new keyboard has gone onto the one I use.

Also, I've harvested the Cmd14 key, since I was missing it.

My intention at this point in time, assuming a reasonable number of rivets are still present, is to do the hardware conversion on the new keyboard and sell it to a geekhacker. I would sell it pre-conversion though, just PM me. Yes, I got it cheap (within my normal keyboard price limits) but will be seeking to make a profit on it. I will do my best to undercut prices on equivalent keyboards when that time comes.

Compare this sticker with the ones I provide in my signature. I wonder how many more are lurking around my city?

My 1386887's quite close:
10 OCT 86/1015223, from puravida1881's auctions.  But then I'd bet you'd half expect it to be given the source.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 20 December 2009, 16:16:29
Quote from: sethstorm;144000
My 1386887's quite close:
10 OCT 86/1015223, from puravida1881's auctions.  But then I'd bet you'd half expect it to be given the source.


I think puravida1881 (who lives in my city) got the keyboards he has from the same place I just got this one. The shelf I pulled this from was bare except for this keyboard...it's entirely possible he couldn't fit it in whatever box he was using or car trunk or whatever it may be.

Either that or this was donated TO the place I got it FROM puravida1881.

Interestingly yours is 10 OCT rather than 16. I also see puravida1881's auctions (there are two, he's selling from two accounts, seems to use one during the holiday season for discounted items) are no longer saying what day.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: sethstorm on Mon, 21 December 2009, 00:42:42
Quote from: kishy;143735
When I got the 1394167 (w/RJ11 plug) I had taken a keycap I was missing, the SetUp key from the left block of 10 keys. The -4167 has that key in black letting however, so it wasn't "original spec" on the 1386887. I've now swapped the black one off of the one I'm using and put it on the new keyboard, while the blue lettering one off the new keyboard has gone onto the one I use.

Well, I've had to swap keycaps with my (incompletely keycapped) 1391401 to make my 1386887 complete but not at all correct.  Enough keycaps to make it look PS/2-like, but largely unchanged.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 09 January 2010, 18:46:19
Just some observations to put out there

It seems like some games ignore the Windows keyboard driver and sort of "have their own", reading the scancodes from the keyboard directly.

Source engine games are a hybrid...they recognize the Windows remaps of the keys, do their own thing for "typematic repeat" (properly detects when keys pressed/unpressed, but won't repeat typing for example)

Here's one nobody will care about but may be somehow significant. Mafia: The City of Lost Heaven is taking the 122 as an 84-key AT board, no exceptions at all. It isn't recognizing my  Cmd1 through 12 as being mapped to F1 to F12 or Cmd13 as Esc. It's using the numlock key as Esc (which is default behaviour), cursor keys are unmapped except left which is backslash...etc. No key sticking issues so it has a mechanism to counter that as well, I guess.

Either that or they're partially respecting the Windows driver, but only partially.

Thoughts/experiences?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: ch_123 on Sat, 09 January 2010, 18:47:30
Is it a DirectX thing? I've noted that many games default to the US layout despite the fact I had my system set to the UK one at the time.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sat, 09 January 2010, 18:59:10
Quote from: ch_123;149658
Is it a DirectX thing? I've noted that many games default to the US layout despite the fact I had my system set to the UK one at the time.


Interesting...it may indeed be DirectX related. If not then there's a lot of unnecessary work being done by game developers.

Quote from: ripster;149661
AutoHotkey can sometimes get disabled by some games.

Although this driver swap stuff is interesting I'm still thinking the small DIY controller is the best ultimate solution.  

Looking from the outside it seems the Geekhack controller project got bogged down by being over featured.  And you can't blame the Marketing department for that!


Yup, standalone controller is my goal. Kbdbabel was the original I wanted to try but that seems less feasible than an AIKON.

I'm thinking the AIKON will do the job for the 122, given its amazing customization abilities.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: JohnElliott on Tue, 19 January 2010, 14:19:59
Apparently,  if you have FilterKeys turned on key repeat is done in software. (http://blogs.msdn.com/oldnewthing/archive/2009/12/28/9941455.aspx#9941641)

This means that you can use the custom i8042prt driver and get repeating keys. The way I did it was:

1. Turn on FilterKeys: Control Panel | Accessiblity Options, tick "Use FilterKeys".
2. In the "Settings" page, untick "Use shortcut" and "Beep when keys pressed or accepted". Select "Ignore quick keystrokes and slow down the repeat rate", and click on the "Settings" button there.
3. Tick "Slow down keyboard repeat rates" and set the delay and repeat rate to the minimum (0.3 seconds). Set the "Keys must be held down for" slider to the mininmum (0.00 seconds).
4. Say OK to everything and check that you get (sluggish) key repeat.
5. Go to the Registry, HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Response (http://discuss.pcmag.com/forums/thread/1004407379.aspx) and edit the "AutoRepeatDelay" and "AutoRepeatRate" options to (say) 200 and 30 respectively.
6. It may be necessary to log out and log in to get the new rates to take.

(I probably did this the long way round. My guess is that changing the values of "AutoRepeatDelay", "AutoRepeatRate" and "Flags" in the Registry  would have sufficed).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Tue, 19 January 2010, 16:31:49
Thanks John! That's interesting. I'll definitely look into this next time my desktop is on (starting with just the registry change, if no luck then moving to FilterKeys).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Oqsy on Thu, 04 March 2010, 01:47:17
kishy: I'm noting my extreme interest in your completed conversion of this new acquisition right now  :D  I've silently watched this thread for a while now with hopes something like this might happen!  Awesome stuff!

Oqsy
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 04 March 2010, 05:24:09
Quote from: Oqsy;161733
kishy: I'm noting my extreme interest in your completed conversion of this new acquisition right now  :D  I've silently watched this thread for a while now with hopes something like this might happen!  Awesome stuff!

Oqsy


Heh, thanks I suppose. I had a feeling something would be possible the get the beasts usable.

Of course, I've sort of abandoned ways of improving this method since it looks like (the 122 key version of) this (http://geekhack.org/showwiki.php?title=Island:8406) will be better in the end. Of course, for people not as able/willing with a soldering iron, the method from this thread will still work...just not as well.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: sethstorm on Thu, 04 March 2010, 18:06:47
Quote from: kishy;161741
Heh, thanks I suppose. I had a feeling something would be possible the get the beasts usable.

Of course, I've sort of abandoned ways of improving this method since it looks like (the 122 key version of) this (http://geekhack.org/showwiki.php?title=Island:8406) will be better in the end. Of course, for people not as able/willing with a soldering iron, the method from this thread will still work...just not as well.

Well, it'll work in that it also works with the Terminal Model F - as they appear to have a different controller (as you once said).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Thu, 04 March 2010, 19:56:36
Quote from: sethstorm;161846
Well, it'll work in that it also works with the Terminal Model F - as they appear to have a different controller (as you once said).


True. Not so much just a "different controller" as a "different technology requiring different electronics". What exact differences there are, I'm not sure, but it's safe to say you'd need additional 'stuff' in the design.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: microsoft windows on Thu, 04 March 2010, 19:57:59
Does a converted 122-key Model F keyboard have N-key rollover?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: sethstorm on Fri, 05 March 2010, 23:31:40
Quote from: microsoft windows;161890
Does a converted 122-key Model F keyboard have N-key rollover?

As far as I know, yes.  I don't have any issue with blocked/ghosted keys with either the F or the M terminal boards.

The only questionable ones are the Home/End keys - which if you remove the FF keycode from being made into reset, they operate normally after Key Mapper uses them (or manual registry edit of the FF 7F(Home)/FF 7A(End)).

I just wish I could stuff multiple keycodes at the hardware level to bind to one key for the PF3-PF24 keys.  For now, it's impossible to do that w/ a Terminal Model F, but possible with a Terminal Model M(usb controller).
Title: in linux
Post by: rickfleming on Sun, 20 June 2010, 12:03:24
I haven't tried this yet, because I don't have the jumpers available, however I looked through the source code to the atkbd module, and it has a special case for a keyboard with an ID of ACA1, which looked like the keyboard should then operate in Set 3 mode, and I believe as the terminal keyboard behaves without the break codes.  This isn't tested yet however, I haven't the jumpers yet to set the ID.  The ID should be settable because the first to bits in each byte are the 10 (the bit value is 1010 1100 1010 0001), just as the keyboard allows.

And I don't currently have a PC setup with a natural PS/2 port either, I've been using a non-converting PS/2 to USB passive adapter, in which case I've been getting the repeat issue since the keyboard doesn't send the break code for the keys.

Once I have the jumpers I am going to attempt this.  It would be nice if Windows also had some catch like this but I very highly doubt it.

I ran into a bunch of code for FreeBSD and NetBSD which looked as though there was some sort of native level support for scancode set 3, and it should be possible to do something similar to the windows driver patch for linux by writing a custom application (either in c, python, or anything really) which will send the correct bytes to the /dev/port device, by opening the device and seeking to the correct IOPort address and writing the correct bytes.

Was wondering if anyone else had a good experience attempting to get this to work under linux.  I also have 64-bit Windows 7 however don't have the time right now to download the windows 2003 ddk and set it all up to patch the version compatible with the enhanced driver API.

Thanks,
Rick
Title: reprog the i8042 (yeah I know it's virtual) via the driver?
Post by: dfj on Sun, 20 June 2010, 14:06:26
Quote from: sethstorm;162081
As far as I know, yes.  I don't have any issue with blocked/ghosted keys with either the F or the M terminal boards.

The only questionable ones are the Home/End keys - which if you remove the FF keycode from being made into reset, they operate normally after Key Mapper uses them (or manual registry edit of the FF 7F(Home)/FF 7A(End)).

I just wish I could stuff multiple keycodes at the hardware level to bind to one key for the PF3-PF24 keys.  For now, it's impossible to do that w/ a Terminal Model F, but possible with a Terminal Model M(usb controller).


Nutter - you have been maintaining Monet and JCE's i8042 patch... (who else worked on this?)

You have the i8042 - and a live kernel driver: you can program it to do the deed for you - and for the driver to stash stuff before throwing a 'doze event... 'course your bugs will bring our systems into happy-busted-pagetable-land if you err correctly. :)

This is not the hardware you meant - but still, it is an option for 'dose - and the linux side is pretty well handled already, last I checked.

  Poor mac-folks. No terminals without USB for them. (not a troll - I am thinking of the mac-users not Apple.)

Anyway - I'm on the physical layer this weekend - going to be blocked on firmware in a couple days, though - so I'll be back on that page soon.

And - yes - I want GH to get some capacitive reading code into our shared brains - the AVR stuff rip mentioned is capable of very much more than we are thinking of - is for reading touch-devices, and might even support multi-touch. Very much more than we need. IBM did this with sane micros and components... once we have more devices in the hands of folks who like that level of layer the excitement will be back.

yup.
dfj
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 13 October 2010, 23:36:55
This hasn't really been discovered yet, more or less theorized about, but a pseudo-fact worth putting out there...

In IRC we've kind of come to the conclusion that there may be 5-pin DIN terminal keyboards that this doesn't work with. Not confirmed yet, working on that.

Basically, the later ones are clearly based upon the AT protocol...which is good. But in the same way that XT and AT use the same physical plug on PCs, it seems like the early terminal keyboards may have had XT-based communications. The board that spawned this thought is from 1983 which is iffy on the timeline; surely IBM had the AT stuff in the works at that point, but the stuff in actual production would have likely all been XT.

Unless, of course, the terminals, right from their introduction, were what "AT" was actually designed for to begin with and it just migrated to the AT itself when released...but there's no way in the world to figure that one out.

We shall see what future research and investigation reveals...
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Soarer on Wed, 05 January 2011, 07:55:32
Quote from: kishy;233623
We shall see what future research and investigation reveals...


Any new findings to report?

I'm working on an adapter which handles XT, AT and terminal keyboards, and it would be moderately easy to add support for such a beast should it exist.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Wed, 05 January 2011, 23:28:34
Quote from: Soarer;273447
Any new findings to report?

I'm working on an adapter which handles XT, AT and terminal keyboards, and it would be moderately easy to add support for such a beast should it exist.


Nothing on that note yet. The board I had that I suspected that of initially has been passed on to someone more capable of probing it (and understanding the findings).

It seems unlikely that my theory was right, though, seeing as the 3270 PC (which is itself a standard XT with extra stuff added) used an AT-speaking keyboard (the 122s we know and love). The ISA card apparently handled this translation.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Soarer on Thu, 06 January 2011, 07:30:50
Quote from: kishy;273884
Nothing on that note yet. The board I had that I suspected that of initially has been passed on to someone more capable of probing it (and understanding the findings).

It seems unlikely that my theory was right, though, seeing as the 3270 PC (which is itself a standard XT with extra stuff added) used an AT-speaking keyboard (the 122s we know and love). The ISA card apparently handled this translation.


Well it will be interesting to find out what it is once it's been probed.
Perhaps, though, could it simply be broken?

The only terminal board I have is a 3270, which I assume is from a 3270 PC, but it doesn't have the original label. It matches up to the descriptions I've read of other 122s: 240 degree DIN, set 3 codes, AT protocol, mostly no break codes sent (until commanded otherwise).
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 07 January 2011, 22:30:44
3270 describes a range/series of terminals...generally, they are the terminals for which these 122s are for. The keyboards are interchangeable so long as the plug is the same...specific part numbers for different units exist because of different key layouts.

The unit in question had both a DA-15 and DB-25 connector. The connection method to the terminal was not apparent, hence why it's been sent off elsewhere to be probed.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Soarer on Fri, 07 January 2011, 22:52:11
Ah, I see, it's not a 5-pinner. My oscilloscope only has two channels, so I'm sticking to the clock + data versions for now :-)

I've been wondering why the 3270 isn't included in the list in your sig (or on kbdbabel). Is it different in some way? Or just not a 'real' model number?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Fri, 07 January 2011, 23:12:59
Some of those (3179...um...there actually is something missing from that list, I think 3290s also use our DIN plug, but only some of them) are 3270 terminals - it's a class (http://en.wikipedia.org/wiki/IBM_3270) rather than a specific unit or type designation, and just saying "3270" includes many terminals that were many years earlier and, in terms of peripheral interfacing, not the same at all. The 3270 PC was a modified XT system that provided a featureset making it part of the 3270 class.

Funny little detail about the 5-pin DIN...it isn't actually 5 pins, technically. They removed the 6th pin from a 6-pin DIN plug and socket and used that. This is what creates the ambiguity between the AT/XT and terminal DIN plugs.

So, important thing is, some of them are 3270 terminals...many aren't (terminals were made as late as 1999, with 8P8C plugs, which use keyboards that this process applies to...but they aren't of the 3270 class).

Edit: indeed, some 3290s (past research suggests the first generation was what used the two d-subs I earlier described - this dates 1983, predating the AT protocol entirely and any use of it anywhere) did use the DIN plug. See here (http://www.recycledgoods.com/products/IBM-3290-02-19%22-Plasma-Screen-6217074-Vintage-Collectable.html) - terminal is a later model 3290 and it has the DIN socket.
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: Soarer on Fri, 07 January 2011, 23:29:25
Thanks. So '3270 PC' could go in the list, but it goes without saying, in a way. At least that means that so long as my adapter works with this 3270 PC keyboard, it should work with the other 122s with a 5-pin DIN :-)
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: jacynt on Sun, 18 September 2011, 11:32:47
Hello,
Does the Sherwood keyboards (Model EPC) are also mechanical? Keyboard is quite heavy, and it has a rj cabel. Under the buttons there are white "pin" similar to the Cherry MX, but insteed it is "female" like.
I look forward to try it on the PC. Will the trick with rj -> ps/2 adapter work for it? Where I can order this magic adapter?
Title: IBM 1386887 (3179 terminal) keyboard conversion
Post by: kishy on Sun, 18 September 2011, 12:25:29
Quote from: jacynt;418135
Hello,
Does the Sherwood keyboards (Model EPC) are also mechanical? Keyboard is quite heavy, and it has a rj cabel. Under the buttons there are white "pin" similar to the Cherry MX, but insteed it is "female" like.
I look forward to try it on the PC. Will the trick with rj -> ps/2 adapter work for it? Where I can order this magic adapter?

I have no idea, to be honest...Googling doesn't seem to get me a view of what you have. Unless it boasts IBM compatibility, I would really doubt this same process would apply (but hey, wouldn't know till you tried...which could be a dangerous endeavour - would encourage a new thread with lots of pics)
Title: Re: IBM 1386887 (3179 terminal) keyboard conversion
Post by: supermario802.1 on Sat, 22 September 2018, 05:32:51
I've got several 240 degree IBM Terminal Keyboard to USB Converter (http://www.tinkerboy.xyz/product/tinkerboy-ibm-terminal-keyboard240-degree-5-pin-din-to-usb-converter-with-soarers-converter-firmware/) if anyone is interested.