Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral
  1. So Ben's next video is out and he did not disappoint by coming up with a very interesting solution without using a microcontroller! I suppose the only drawback is that you can't really talk back to the keyboard to switch the LED's and stuff like that. Losing the parity bit is probably also not really a big issue unless your circuit is really noisy. If it's really an issue I guess it could also even be handled by some additional circuitry...
  2. Would be very interesting to see what he comes up with! To me using a microcontroller would be cheating a little bit, unless it is one that was also available in the same era or is less powerful than the main CPU @Stefan Great analysis work! I take it you are also interested in how this works. Same here, very curious to see what they come up with. I guess the interrupt driven method saves some cycles compared to constantly polling at some interval. By the way, @kktos also had a great idea by storing key presses in RAM to be able to access them very quickly! I think this is also done by the C64 KERNAL...
  3. 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... 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.
  4. 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?
  • Create New...

Important Information

Please review our Terms of Use