Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

help with AT keyboard protocol...

Status
Not open for further replies.

alunaro

Member level 5
Member level 5
Joined
Jan 15, 2002
Messages
91
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Location
Another world
Activity points
770
Hi, I'm trying to emulate a AT keyboard with pic, but there're some obscure points about protocol that I don't understand, and have no information about. all information will be welcomed:

Questions:

1- if keyb is retransmiting last byte (because host sent a Resend) and host inhibits the bus in the middle of transmition
, after processing the new command... keyb should resend the last byte without waiting for Resend command or should wait
for a Resend comand from host?. IE:

keyb host

Z ----->
A ----->
<---- Resend
A --X (host inhibit bus) why? I think Host can do it.
<---- sends another comand -not Resend-
???? ----->

should keyb try to send again key "A"? next key in buffer? wait another Resend commando from host? ...?
how sending "A" keyb was interrupted, the LastKey sent will be "Z"?


2- This case:

keyb host

A ----->
<---- command (not resend)
ACK ----->
<---- Resend
???? ----->


what should resend the keyboard? "A" key, or only "ACK", or the complete command packet?


3- how many Resends must send the keyboard before sending a 0xFC? (I think 1 resend and if the second byte from host
is still wrong, then keyb sends oxFC)
what does keyb after transmiting a 0xFC error code? stands waiting commands from host? stops keys scanning? ...?


Thanks!!
 

There are some excellent references on the web. Take a look at the following for examples - the first one has some programming hints with code segments:

h**p://www.beyondlogic.org/keyboard/keybrd.htm

h**p://www.hth.com/filelibrary/TXTFILES/keyboard.txt

(replace * with t in above)
 

Thanks, but I have read that webs before, and don't have any solution for my questions. Really I was looking for them for some month ago, and NOTHING !!!

So now I'm making a logger for AT Keyboard, but all well be easier if I could read that I need. xDD
I'll continue looking for it.... :cry:
 

AT Keyboard

Here a software AVR based for AT keyboard. I expect that it be usefull. Regards.
 

thank u.. but... I had read it yet.. hahahaha Really I have read ap notes of cypress, philips, atmel, microchip, and others, lot of webs, faqs and articles, but all talk about the scan code of conversion routines or timming the communication, but no one about the "high level" protocol keyboard-host ie: what happen if keyboard sends and 0xFC or... how many resends must send keyboad before send an 0xFC error? or the questions of my first post..

loggeeer, I need UUUUU

thanks
 

mmmmmh that's new!! let's seee (I hope it won't be the state machine of timmings, because I did it hahahaha )

thanks :D
 

In last case, you can try to reverse the interruption of keyboard handler (int 9), in pure dos mode, without loading keyb driver) ... or check in some reference code (see PM)
 

thanks... I think now I have a interesting piece of code xD ;)
I should study it, maybe it wont resolve all problems but as I see, I could resolve almost all -I think- xD

Thank U :eek:

If I get to resolve the protocol, maybe I could post it.. but before... I must to translate it hehe

I'm making a full operative keyb encoder with PIC, but information... aaaaag IBM sucks.
 

alunaro said:
thanks... I think now I have a interesting piece of code xD ;)
I should study it, maybe it wont resolve all problems but as I see, I could resolve almost all -I think- xD

Thank U :eek:

If I get to resolve the protocol, maybe I could post it.. but before... I must to translate it hehe

I'm making a full operative keyb encoder with PIC, but information... aaaaag IBM sucks.
Looking at DOS int9 may not help, because the low-level protocol is implemented by the host controller on your motherboard. On the original IBM AT this was an 8042 micro, but it's probably fully integrated and inaccessible on modern mbds.
I'd suggest you be pragmatic, and do what is simple to implement and won't lose data:
1. resend the A
2. resend the A
3. I'd suggest after sending the 0xfc, do a restart (without sending POST code!) and carry on scanning; main thing is to clear down buffers and statuses, so any queued keystrokes are erased.

I used to work for a kbd manufacturer, and I've never seen a resend requested; your logger is unlikely to answer your questions. If you want the full detail, get a kbd and motherboard host controller both implemented in an readable micro (preferably from the original IBM AT), read the programs and disassemble. That'll at least tell you what the manufacturer of those parts did. That's exactly what we did to implement our first AT keyboard! I don't still have the code to send you - it was more than 15 yrs ago :-o

HTH
barny
 

yes i know that after reading the code.. xDD

I only need to logger the data packages and send some ones wrong (my logger could do it when I finish). I havent any other resources.. I must made it myself xD.

But I thought about resend the keystokes and a "reset" of keyboard when sends a FC code... more or less.

now I don't know... tomorrow I'll think about it xD.

Thanks U 4 all.
 

h**p://koti.mbnet.fi/~gkos/gkosnet/gn-circuit-ps2.html

It works.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top