Commander X16

Not only was the PS/2 ports in the PS/2 computer read and written to by a microcontroller, the IBM-AT predecessor to the PS/2 was. My inclination would be to go truly retro and access the ports the way they were originally accessed back in the 80s.

Now, AFAIU, the Intel part that they used back then is no longer in production, but 8bit microcontrollers that can do the task are, so go with that.

I am NOT saying this JUST to free up more GPIO pins in the VIAs ... oh no! But if it DOES free up more GPIO, that would be cool too.

28 minutes ago, BruceMcF said:

Not only was the PS/2 ports in the PS/2 computer read and written to by a microcontroller, the IBM-AT predecessor to the PS/2 was. My inclination would be to go truly retro and access the ports the way they were originally accessed back in the 80s.



Now, AFAIU, the Intel part that they used back then is no longer in production, but 8bit microcontrollers that can do the task are, so go with that.



I am NOT saying this JUST to free up more GPIO pins in the VIAs ... oh no! But if it DOES free up more GPIO, that would be cool too.

Yeah, if we already have an MCU working the power circuit, maybe a larger chip with more GPIO pins could be used to read the keyboard and mouse. 

I'm a little worried about the "the keyboard only works at 2MHz" thing going on right now. Designing the I/O subsystems so that they are clock speed dependent is a bad idea...

 

I remember @Lorin Millsap said some months ago, that the current Kernal function for reading the keyboard would not be the one to be used in the final product.

On Github, there is the "ps2-nmi" branch last updated at the end of April. I haven't analyzed the code, but it seems to be an interrupt based solution instead of the polling method used in the current master branch.

 

I remember [mention=28]Lorin Millsap[/mention] said some months ago, that the current Kernal function for reading the keyboard would not be the one to be used in the final product.
On Github, there is the "ps2-nmi" branch last updated at the end of April. I haven't analyzed the code, but it seems to be an interrupt based solution instead of the polling method used in the current master branch.
 

I’m certainly not an expert on the code. But what seems to be happening is the PS/2 code that was used was written in a poll type interface. PS/2 was meant to be interrupt driven. Because the code is Polk based it inhibits keyboard communication except when it wants to. On a CPU cycle limited system like a VIC20 or C64 where you need to read things within a narrow window of time that works fine. And on our system this is still somewhat the case, except it needs to to be implemented differently. Holding the click line to inhibit communication is not the problem. The problem is the code essentially hits a timeout, and if the keyboard hasn’t started transmitting by the time the code times out, then it misses the data. When it’s run at lower speeds this works fine, but when the CPU speed gets increased then it times out faster. I thought Frank wrote some new code that worked better, but apparently it never got merged in.


Sent from my iPhone using Tapatalk

Thanks @Lorin Millsap!

I looked at and calculated the wait loop on lines 55-60 in the file x16-rom/kernal/drivers/x16/ps2.s (Github master branch) once more.

AFAIU:

• 
  The loop setup on lines 55-56 is 4 cycles. The loop counter (Y) is set to 80.
  


• 
  Each loop (lines 57-60) takes 11 cycles. The test for a start condition happens 4 cycles into the loop.
  


• 
  The loop will check for a start condition 79 times
  


• 
  The last check will happen 4 + 78*11 + 4 = 866 cycles after the I2C lines were released
  


• 
  866 cycles @ 8 MHz processor speed is about 108 us. @ 2 MHz it's about 433 us. If the keyboard hasn't started to transfer data within that time, the PS/2 lines are made inactive again.
  


• 
  As far as I can see, there are no other parts of the Kernal PS/2 code that has a similar timeout. If receiving a start condition, the code will wait (indefinitely) for the keyboard to finish transmission.
  


• 
  Instead of lowering the processor speed, you could increase the value of the loop counter on line 56. If the counter is set to it's maximum value of 255, the timeout will happen after 349 us.
  


• 
  If that's not enough, you could add one ore more NOPs to the loop for testing purposes. One NOP at the beginning of the loop would increase the wait to about 414 us if the loop counter is set to 255.
  

Thanks [mention=28]Lorin Millsap[/mention]!
I looked at and calculated the wait loop on lines 55-60 in the file x16-rom/kernal/drivers/x16/ps2.s (Github master branch) once more.
AFAIU:

• The loop setup on lines 55-56 is 4 cycles. The loop counter (Y) is set to 80.
• Each loop (lines 57-60) takes 11 cycles. The test for a start condition happens 4 cycles into the loop.
• The loop will check for a start condition 79 times
• The last check will happen 4 + 78*11 + 4 = 866 cycles after the I2C lines were released
• 866 cycles @ 8 MHz processor speed is about 108 us. @ 2 MHz it's about 433 us. If the keyboard hasn't started to transfer data within that time, the PS/2 lines are made inactive again.
• As far as I can see, there are no other parts of the Kernal PS/2 code that has a similar timeout. If receiving a start condition, the code will wait (indefinitely) for the keyboard to finish transmission.
• Instead of lowering the processor speed, you could increase the value of the loop counter on line 56. If the counter is set to it's maximum value of 255, the timeout will happen after 349 us.
• If that's not enough, you could add one ore more NOPs to the loop for testing purposes. One NOP at the beginning of the loop would increase the wait to about 414 us if the loop counter is set to 255.

In my view the timeout should be removed and a separate system based timer should be used. The same VIA chip has timers and they can be configured to count higher. Also running in a loop defeats the purpose of switching the circuit to IRQ based.

The way the PS/2 has now been setup it is connected to VIA0. This VIA has its _IRQ line connected to the CPU _NMI line which means IRQs generated by this VIA cannot be ignored. The theory is that you only use IRQ functions of this VIA for PS/2 related functions. For most software unless you are doing timing critical stuff there is no problem with the PS/2 keyboard generating these NMI events at pretty much any time. It will just read the data as it comes in, and you just disable the keyboard at times when you don’t want interruptions. Normal behavior will be to inhibit mouse except for once per frame if the mouse is enabled. And the mouse and keyboard will have to take turns.


Sent from my iPhone using Tapatalk

On 8/15/2021 at 7:05 AM, BruceMcF said:

Not only was the PS/2 ports in the PS/2 computer read and written to by a microcontroller, the IBM-AT predecessor to the PS/2 was. My inclination would be to go truly retro and access the ports the way they were originally accessed back in the 80s.

I really like and support this idea.