Trying to understand how to correctly implement response to the RESEND (0xFE) command from keyboard host, I've made an experiment: at a certain time, when the (real) keyboard is sending its first byte of response to the IDENTIFY (0xF2) command, i.e. first of AB 83 sequence, I try to hold the DATA line at zero level for the duration of one bit, so as to introduce a parity error. All this is registered with an oscilloscope so that I could see what a real keyboard does when the host tells it to RESEND.

What I saw looks like the following (click to see full-size oscillogram): oscillogram

Although the highest bit of 0xAB is not fully at zero (because it was a bit hard to aim), it does appear zeroed on the falling edge of the CLK line, so the host does proceed with issuing the RESEND command.

Here's the oscillogram interpreted:

$$ \require{cancel} \begin{array}{|c|c|c|l|} \hline \text{#}&\text{Kbd}&\text{Host}&\text{Comment}\\ \hline 1&\text{AA}& &\text{BAT OK} \\ \hline 2& &\text{F2}&\text{Read ID}\\ \hline 3&\text{FA}& &\text{ACK} \\ \hline 4&\cancel{\text{AB}}&&\text{First byte of ID (broken by me)}\\ \hline 5& &\text{FE}&\text{Resend} \\ \hline 6&\text{83}& &\text{Second byte of ID (Resend ignored?)}\\ \hline \end{array} $$

Before this I was under the impression that RESEND command should make the keyboard resend its last sent byte and continue with the transmission. But this behavior of a real keyboard made me wonder if it's actually implemented in most keyboards at all.

So, do modern-ish (this one is about 10 years old) PS/2 keyboards ignore the RESEND command? Or are responses to some commands somehow special-cased?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.