Jump to content

Prototype #3 - Parts have arrived and the first one has been built!


Recommended Posts

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
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use