Here are some more symptoms. Any help would be appreciated. I created a program on a F84 that reads the data coming off the keyboard and displays it on an LCD. When I press a key on the keyboard (the keyboard that works) I get 33 bits clocked in. This is as expected since it should give me a 1C when the key is pressed followed by an F0 and a 1C when the key is released. Since there is a start bit, a parity bit and a stop bit, this should produce 33 bits. So far so good. However, the bits that are clocked in are not what are expected. Instead of a 1C (which is supposed to be the scan code for "a"), I get an 0x18. I have the data line hooked to pin B0 and the clock hooked to B1. When I switched the data line to A4 (as Steve Lowthar has in his on-line code and schematic) the keyboard gives me a 0x10. Now you might be saying that the A4 pin needs a pull-up resistor, but according to the keyboard documentation, pc keyboards contain pull-ups on both the data and clock lines. However, in any case, adding a pull-up still produces a 0x10. Interesting that the value read on this pin changes depending upon whether it is read from pin B0 or pin A4. I decide to try Steve Lowther's code and schematic for a 16C84 hooked to a keyboard and an LCD display. When in doubt, start with something you know works, I figured. I wired it up on a protoboard and burned the chip. He uses B0 for clock (using it as an interrupt) and A4 for data. It produces the same 0x10 that I was getting from my code. Also, the other two keyboards don't work on his code either, leading me to believe that Mark is right, no reset is required (Steve's source code doesn't show any). Well, the bottom line is that my code seems to be producing the same results as his. I conclude that there must be a problem with the hardware somewhere, yet I've followed his schematic. I wonder if the fact that I get a different value from pin B0 and A4 provide any clues. There is no variability in the results produced: I always get 0x10 on A4 and 0x18 on B0. Once again any thoughts would be appreciated. John Hansen At 02:10 AM 5/30/00 -0700, you wrote: >I don't think that can be the case. That's pretty durn inconsistent >with "S.O.P." on keyboards... Said reset command, comes in via the >clock AND DATA lines - and REQUIRES the data line to be open collector >so (non-zero) data can be sent to the keyboard! This is like having a >Dallas 1-wire device which pulls the single line low, then expects a >command to somehow manage to arrive in over that same line... >Something's broke or latched up or ??? ( This is also rather akin >to supergluing someone's hands to a Rhino, then criticizing them *when* >they don't wave goodbye but that's getting somewhat OT!) > >I'm thinking to check the rise time on your 5V power for the keyboard >while waiting for me to get there (If it's too slow, perhaps the >keyboards are locking up - On a PC, the rise time's pretty fast IIRC.) > >If that's not it, I'd try toggling the clock line to see if that happens >to unlatch things, is all I can come up with at this hour. I should go >look at all the info I've notebooked together tomorrow. A look at the >POST code in an AT's BIOS would be the first place I look, now where'd I >lose THAT at? > >It's 2 AM and I'm rather "wiped", so maybe I'm forgetting something, of >course... > > Mark > >Alan B Pearce wrote: > > Your keyboards that keep the data line low are probably awaiting a > reset command > > from the PC before coming alive on the interface. Check the documentation > > available on the web for how the PC resets these.