How does PS2 keyboard interface work

[JanSwanepoel 0]

Hi everyone,

I am trying to understand how PS2 keyboard output is read by the CommanderX16.
From my understanding the data and clock pins of the keyboard is connected to VIA2 pins PA0 and PA1. Initially I thought that the VIA would fire an interrupt when the clock changed which samples the data pin. But glancing over the datasheet of the 65C22 I don't see the possibility to generate an interrupt if the clock pin (PA1) would change. Maybe the clock is also separately connected to an interrupt pin? If not, then I guess the keyboard is not interrupt driven?

Next I tried to read the kernal keyboard driver code but my assembly skills are a bit limited. Looks like clock (PA1) is held low which prevents the keyboard from sending data. When the program want to read the keyboard it releases the clock line and then starts to sample the data and clock pins until the whole scancode was read. But this would mean that when the program wants to check for a key press it will block until the user presses a key which also does not sound correct?

Does anybody have some insights on how this works?

[TomXP411 304]

So the thing you’re missing about the keyboard is that the keyboard generates the clock. And since PS/2 is an event driven protocol (messages are sent when a key is pressed or released), the system requires interrupts. 
 

So the keyboard and mouse ports will be hooked to the IRQ line, because they have to be.

So the process would be that when you press a key, the keyboard will cycle the clock line, triggering an interrupt, and the computer will then start reading the clock and data lines. Once the data has been read from the port, the character will be placed in the keyboard buffer. 
 

I haven’t looked at the keyboard code in the emulator yet, but it’s possible that the emulator is injecting values directly into the system; that’s the approach I took when I first started my own virtual computer project. 

[Lorin Millsap 171]

We have new code in testing that the emulator doesn’t reflect. When then code passes and we know it works reliably we will update the emulator and documentation. How it works now is not how it will work down the road.

 

 

Sent from my iPhone using Tapatalk

[Lorin Millsap 171]

One thing to note though is you should from a good coding standpoint, never attempt to read the keyboard or mouse directly. You should use the KERNAL routines instead. If you try to write your own routines it will cause several bad side effects.

One is that if the way the keyboard works changes, it will break your code every time. What if a future version used a USB keyboard or a direct matrix? If you use the KERNAL routines you will always work and it would be the KERNAL that would change to match the hardware.

Also we have found some keyboards have different requirements. We are making our routine as robust as possible. Custom routines may not be as forgiving.


Sent from my iPhone using Tapatalk

[izb 46]

One thing to note though is you should from a good coding standpoint, never attempt to read the keyboard or mouse directly. You should use the KERNAL routines instead. If you try to write your own routines it will cause several bad side effects.

One is that if the way the keyboard works changes, it will break your code every time. What if a future version used a USB keyboard or a direct matrix? If you use the KERNAL routines you will always work and it would be the KERNAL that would change to match the hardware.

Also we have found some keyboards have different requirements. We are making our routine as robust as possible. Custom routines may not be as forgiving.


Sent from my iPhone using Tapatalk

Will the new kernal routines allow you to detect when a key is held and released?


Sent from my iPhone using Tapatalk

[kktos 14]

Just a thought here:
One possibility could be the kbd/mouse firmware just store in RAM the data.
That will save some cycles on the caller side. just read RAM rather than call a sys function.

[JanSwanepoel 0]

18 hours ago, TomXP411 said:

So the process would be that when you press a key, the keyboard will cycle the clock line, triggering an interrupt, and the computer will then start reading the clock and data lines. Once the data has been read from the port, the character will be placed in the keyboard buffer. 

That makes much more sense. So then it means that the clock line is not only connected to PA1 but also tied to the interrupt pin (probably the non-maskable pin) of the 6502. So in the ISR it could then check PA1 to determine if the keyboard generated the interrupt...

15 hours ago, Lorin Millsap said:

One is that if the way the keyboard works changes, it will break your code every time. What if a future version used a USB keyboard or a direct matrix? If you use the KERNAL routines you will always work and it would be the KERNAL that would change to match the hardware.

Good point, I will for sure rather use the Kernal routines. The question was more out of curiosity and to understand how the mechanism works. Most of the projects I have seen in the past used some micro-controller to handle the PS2 keyboard and this direct handling had me curious.