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?
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.
Was Linux affected by the same problems?
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".
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).
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.
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).
(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 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.
Hey, this is great to see. Good work!
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.
ripster's Boscom was indeed a terminal emulator board.
Sounds like the converter isn't making the distinction.
Yes, but you're not supposed to hotplug PS/2 equipment :smile:
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
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!
The odds of you finding one on eBay UK is quite limited.
"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.
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.
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.
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.
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.
I have the same keyboard. It's a terminal emulation board, but it's meant more for an AS400 than for a mainframe.
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)
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).
Looking for keycaps
the DIP switches on the 3270 PC's keyboard (or whatever model is the one that has DIPs, I think it's that).
Attached you can find some photos regarding the layout.
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.
PS/2?
5-pin 240 DIN socket to 6-pin min DIN plug adapter
http://www.computer-engineering.org/
5.5mm nutdriver
PCB stuff
Wow, that's... Different.
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?
I'm interested to see how much of my annoying remapping (and possibly the key up code problems) is canceled out by using one.
a 56 SX with OS/2 2.1
Note that the terminal boards of this case design do not need a thin walled one, and I use a 7/32 socket.
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).
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 don't have a clue, however, how to "send command ____ to the keyboard".
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();
_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
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"?
This suggests to me that PS/2s might not support set 3 at all (perhaps designed not to),
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.
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.
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.
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.
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
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.
Regarding 1386887 usage on a PS/2 56SX: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...
Code 301 on POST (keyboard not responding or stuck key)
Then, I swapped out the keyboard for the terminal board, and proceeded to type "This sentence is being typed on a 1986 1386887."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.
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.
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?
Problem is, well, it's still typing gibberish.
That wouldn't explain the phenomenon as reported
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?
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.
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.
Making the keyboard return a different ID may not help, if the PS/2 BIOS is (eg) testing the ability to select scancode sets...
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?
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.
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.
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?
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?
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.
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.
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?
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).
"space saver"
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.
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.
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)
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 :)
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...
(Garry's Mod, check it out if you don't know it, fantastic fun physics game)
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?
Vista makes a WinME boot floppy, very easy.
Who says MS doesn't have a sense of humour?
Vista makes a WinME boot floppy, very easy.
Who says MS doesn't have a sense of humour?
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...
If you really want one
That's very kind, but I think will have to pass. If you have any spare time or space for sale, I might consider.
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.
As above, my concern is whether the typical Vista user has the floppy drive.
I expect we all know about this, but anyway: compare the output of ver in XP's command with command/c ver.
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).
I didn't think such a thing as "bootable Windows 95 on floppies" existed, but of course I'd want it if it did.
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...
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...
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...
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)?
More or less, I guess I'm wondering...is there a factory anywhere in the world that still produces 5.25" floppies?
Tsk tsk; what if you had a Zip drive? Those aren't completely outdated, yet.
perhaps I've missed something / fallen for a prank: command /c automatically closes upon opening, thus you can't type a command in it.
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.
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).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.
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).
I wonder why nested quotes don't work with the automatic quote function...
Personally that sort of style doesn't appeal, but go for it. You would have something unique even by this forum's standards.
Athana (http://www.athana.com/) still manufacture 8" floppies.
useful method of data transfer
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.
Thank you again for your investigative work.
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.
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.
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.
The Mexican one not having holes is weird - I saw one with channels AND holes on clickykeyboards.
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.
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.
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
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.
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.
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.
They're sending the break codes, but Windows is getting to them before whatever program you're using does.
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.
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.
Sounds like the problem mentioned here (http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-6.html).
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.
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.
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.
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.
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...
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.
Yep. JohnElliot and Kishy have working conversions.
[...]
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?
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...
(info regarding legality)
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;121315While 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;121315Something 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;121315My 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.
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.
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.
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.
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'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.
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:
(image)
It looks like I'm going to have to unlimber my multimeter to see if the wire colors correspond...
(image)
Sorry, saving those parts for other mods. Especially if I ever get around to making a buckling spring numpad.
Pics are in the "Destroying Boscom For Science" post in the mods section.
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.
Does yours work? - I keep pressing mine and my wife ignores it.
Anyone with Spotted **** for an avatar would appreciate the ancient Chinese saying,
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...
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 problem is that on these keyboards, each key can send make/break codes, or do typematic repeat, but not both.
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.
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.
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)
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.
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?
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.
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
Maxi Switch, Inc. #1101
Maxi Switch, Inc. #1102
Maxi Switch, Inc. #2101
Maxi Switch, Inc. #2102
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)
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.
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.
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)
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
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...
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.I did. :laugh:
Well, I was, now I'm not so sure...
I did. :laugh:
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:
Bad Daddy!Show Image(http://geekhack.org/attachment.php?attachmentid=4999&stc=1&d=1254701645)
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)
bad daddy!Show Image(http://geekhack.org/attachment.php?attachmentid=4999&stc=1&d=1254701645)
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.
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.
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.
hey kishy, speaking of terminal keyboard conversions... what do you make of this thing:
http://geekhack.org/showthread.php?p=123099#post123099
It's nice that it has a beer coaster tray, but it's at a weird angle.
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.
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)
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.
I think what I might try is swapping the controller board out of the Boscom and into the IBM.
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).
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.
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?
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?
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.
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.
My 1397000 review has all the detailed scancodes for what I got. Each had a make and break.
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.
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.
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).
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.
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.
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.
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.
NO CONN . . +5VDC
CLOCK . . . DATA BETW/ CLK & DATA: GND
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)
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.
Hi thereThat's the one, and it's from one of puravida1881's ebay sales.
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 dayWell, 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.
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.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.
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).
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).
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.
C:\WINDDK\3790.1830\src\input\pnpi8042
setenv.bat C:\WINDDK\3790.1830 fre hal
From there, change directory to ..\src\input\pnpi8042C:\WINDDK\3790.1830\src\input\pnpi8042\daytona\objfre_wnet_x86\i8042prt.sys
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.
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.
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.
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!
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.
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).
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).
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.
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.
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?