Commander X16

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

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. 

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.

On 1/16/2021 at 11:26 AM, JanSwanepoel said:

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?

• 
  ioinit function is called (kernal/cbm/init.s:20)
  


• 
  ioinit function calls ps2_init function (kernal/drivers/x16/x16.s:27)
  


• 
  ps2_init disables all PS/2 communication by pulling clock pin low and data pin high (kernal/drivers/x16/ps2.s:27-38)
  

• 
  The function kbd_scan is called as part of the IRQ handler (kernal/cbm/irq.s:50)
  


• 
  kbd_scan calls _kbd_scan (kernal/drivers/x16/ps2kbd.s:49)
  


• 
  _kbd_scan calls receive_down_scancode_no_modifiers (kernal/drivers/x16/ps2kbd.s:126)
  


• 
  receive_down_scancode_no_modifiers calls receive_scancode (kernal/drivers/x16/ps2kbd.s:261)
  


• 
  receive_scancode calls ps2_receive_byte (kernal/drivers/x16/ps2kbd.s:225)
  

• 
  First it releases the clock and data pins (kernal/drivers/x16/ps2.s:51-53). As you might remember, these pins were pulled low and high at system startup.
  


• 
  The function polls the state of the clock and data pins at most 10 times (kernal/drivers/x16/ps2.s:55-60) looking for a start condition (clock and data low). I guess 10 times is a timing issue. I haven't done the math on how much time is really spent in that loop before aborting.
  


• 
  If no start condition found within the 10 loops:
  
  
  
  • 
    Branch to line 98 where the ps/2 disable function is called, the same that disabled PS/2 communication at system startup
    
  
  
  
  


• 
  If start condition found:
  
  
  
  • 
    8 bits and 1 parity bit are read and stored (kernal/drivers/x16/ps2.s:62-81)
    
  
  
  • 
    ps2dis is called to disable PS/2 communication again (kernal/drivers/x16/ps2.s:82).
    
  
  
  • 
    And finally the function returns after loading the received byte into A 
    
  
  
  
  

• 
  The Kernal isn't faking it. It reads a byte bit by bit, as you would expect
  


• 
  PS/2 communication is disabled almost all the time by the Kernal pulling the clock and data pins
  


• 
  The Kernal only releases the clock and data pins every VBLANK to read the keyboard
  


• 
  It reads the keyboard by polling the state for a period of time that is sufficiently long to follow PS/2 standard
  


• 
  The above suggests that there is no special IRQ line driven by the keyboard. 
  

• 
  The ps2_receive_byte doesn't poll the PS/2 state 10 times, but 10  times multiplied by processor frequency in MHz => 80 times in total
  


• 
  Manually calculating the cycles spent in the polling loop, I got 11 cycles per loop (more if the code would be split over a page boundary)
  


• 
  That sums up to 880 cycles equivalent to about 110 us @ 8 MHz
  


• 
  I've read that a PS/2 device is required to buffer data to be sent if the host holds the clock line low, and that transmission should begin not before 50 us after the clock line is released
  


• 
  The Kernal is waiting and polling the PS/2 state for about 0.66% of the total VBLANK (0.01667 s @ 60 Hz), if my calculations are right (= 0.00011 s / 0.01667 s).
  


• 
  And probably double that time if we take into consideration the PS/2 mouse