geekhack Community > Keyboards
IBM 1386887 (3179 terminal) keyboard conversion
JohnElliott:
--- 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.
--- End quote ---
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.
kishy:
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.
--- End quote ---
"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"?
JohnElliott:
--- Quote from: kishy;109585 ---I don't have a clue, however, how to "send command ____ to the keyboard".
--- End quote ---
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: ---
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();
--- End code ---
where kwait() and waitempty() are helper functions in assembly:
--- Code: ---
_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
--- End code ---
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"?
--- End quote ---
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.
kishy:
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).
kishy:
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version