Shop OBEX P1 Docs P2 Docs Learn Events
PS/2 IBM AT Keyboard Utility — Parallax Forums

PS/2 IBM AT Keyboard Utility

PJAllenPJAllen BannedPosts: 5,065
edited 2010-09-10 13:18 in General Discussion
Anybody with a program, app., utility, tool, or similar, which will make the computer/PC run a BAT/boot_test on a PS/2 (non-USB) keyboard?
Shutting down windows and rebooting to find the handshaking protocol/comms would be arduous, laborious in the extreme, a bridge way too far.
[I'm trying to come up with a "keyboard wedge", but I need it to be more than that.]

Comments

  • FranklinFranklin Posts: 4,747
    edited 2010-09-07 19:48
    What do you need it to be? And just what is a BAT/boot_test on a PS/2 keyboard? Does that mean you want to hot swap the keyboard?
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2010-09-08 05:46
    When the PC is booting up, in BIOS/DOS, it does a check for peripherals, some time before windows starts chugging. There is a little handshaking/checking/conversation between the host and the keyboard, it finds out what's what.
    I've read that there are only a few Host generated queries and an equally limited set of responses. They may come in the same order on every machine, I don't know. Recycling windows isn't the way to go to find, I'd just like to 'prompt' the computer into doing this checking routine as I require.
  • rosco_pcrosco_pc Posts: 468
    edited 2010-09-08 18:43
    Well, I don't know of any application able to do this, but you can do this by sending a reset command, 0XFF, to the keyboard (http://pcbheaven.com/wikipages/The_PS2_protocol/).

    Not sure how to do this under windows though. But you might be able to use a propeller demoboard for this.

    [EDIT] Found this: http://www.win.tue.nl/~aeb/linux/kbd/scancodes-11.html. You'll need to be able to write to port 0x64.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2010-09-08 19:48
    Interesting suggestion. That may prove useful. If that Reset results in the same frames being sent as at boot then this may be good.

    I have managed to transmit scancodes on the PS/2, so I should be able to transmit a $FF easily enough. $FF... OK

    I think I know what the replies to the Host queries should be.
    I'll try and capture the Host query and if I brick-wall it, reprogram the Stamp till I get all the way through. The Stamp is fast enough, but maybe not fast enough to choose from options. It needs to start replies in <1.5ms, etc.

    Thanks, rosco_pc.
  • rosco_pcrosco_pc Posts: 468
    edited 2010-09-09 01:31
    I made some mistake: make sure to also read this page:
    http://www.win.tue.nl/~aeb/linux/kbd/scancodes-12.html

    0x64 = keyboard controller (inside the host/PC)
    0x60 = keyboard directly.

    0xFF will just reset the keyboard. This might be followed by some more commands to set LED's, repeat rate and so on.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2010-09-09 02:16
    The Propeller can do this with the keyboard module, with adaption.

    The first issue is that the serial i/o is asymmetric. One direction is 12 bits and the other is 13. (Thank you IBM!)

    So using the Propeller's code as a starting point will eliminate a lot of work.
    Then it is merely a matter of sending your request and looking at the reply.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2010-09-09 05:57
    The Stamp will not be fast enough to pick from options (if this then that, if the other then something else or some other...) given some Host query, only fast enough to get it and dispatch an appropriate reply.

    Someone last week posted about, essentially, sending scancodes from a Stamp. [I think they propose to do such things because some other genius hasn't told them about the serial port.] I recall similar posts, too.

    Sending scancodes is easy enough, no big deal. Trying to go full out and use a Stamp to "trick" the PC into figuring that it's connected to a PS/2 keyboard is complicated. And whatever I come up with, if I come up with anything, may not necessarily work for other PCs/BIOSs/etc. because I haven't read from any of the webpages about this stuff that there is a definite, standard, fixed order of Host queries.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2010-09-10 00:44
    Use the Propeller and bypass having to look at PC BIOSes as they are in constant evolution and often not well-documented.

    You can use an SX chip to interface as a UART, but why bother when the Propeller already provides a better means to hack? After all, the Propeller is strictly NON-USB keyboard and mouse at this point. And it appears you only require communicating with the keyboard, not the PC inbetween.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2010-09-10 06:14
    Let's have complete understanding.

    I am trying to come up with a way for the Stamp to "emulate" a keyboard; howbeit, its speed limits my options to just in time responses. I don't need the Stamp to "understand", to be an "intelligent peripheral", it just needs to cough-up canned responses in time.

    I don't need a Propeller to interface with an AT keyboard. I don't need a Stamp to interact with a keyboard. I need a Stamp to present as a keyboard, to fool a PC that it's connected to a keyboard, via the PS/2 connector/topology/architecture/protocol/ad nauseam and then do some "keyboardy" things.

    [PJ said, "I'm trying to come up with a 'keyboard wedge',..."]

    The clincher/bug-a-boo/deal-maker is that I need to find out what the PC/Host queries are, and more specifically what order they come, so that I can program the Stamp to send the appropriate reply (i.e. regurgitate.)
    The Stamp is not fast enough to deal with any/all ranges of options or order of queries, so whether this will necessarily work for anyone else is inconsequential at this point. First, it has to work for me. I don't need the Stamp to "understand", to be an "intelligent peripheral", it just needs to cough-up canned responses in time.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2010-09-10 13:18
    I got it - a keyboard wedge (never heard of a wedge before). I am trying to be equally clear.
    The interface is 13 bits in one direction and 12 bits in the other with parity.

    I doubt that the Stamp will easily do that timing (but the Propeller does in PASM). You can also easily do that timing in an SX in SX/asm.

    Nonetheless, if you really, really want to stay with the Stamp, you can emulate this version of SPI with a Shift IN and Shift Out coordinated with a clock pulse and possibly get results. I think you can just ignore the parity bit. But it will be very slow on a Stamp if done at all.

    IBM made this weird interface just to make it harder for hackers, like having EBDIC rather than ASCII.
Sign In or Register to comment.