Commander X16

On 12/30/2021 at 3:45 AM, Scott Robison said:

David's never been an active participant in this forum. I think it is safe to say that this forum was started by other team members. I'm glad this forum exists, but I don't think we can fault David for not making this his primary venue for sharing with the community.

Maybe it was Christian which said that this forum was setup for this purpose, and make sure that it got the official announcements?

That said; who really owns this domain and forum? Is it David, Christian or someone else?

Isn't the ATTINY 861 connected to the Via with I2c?

can the comunication be performed 2 bits at time (if useful)?

On 12/30/2021 at 2:45 PM, Fabio said:

Isn't the ATTINY 861 connected to the Via with I2c?

I see that Kevin said so in his original post. And that the PS/2 should be interrupt driven.

My understanding of the 65C22 is very limited, but there is no mention in the datasheet of I2C support. As far as I can tell from the Kernal source, I2C is done by bit banging VIA pins. But yes, I suppose you could read and write data from/to the ATTINY using this kind of I2C communication.

One thing that springs to mind is that the ATTINY then might need to drive three timing dependant serial interfaces simultaneously (two PS/2 and one I2C). Can it do all that?

And if an NMI may be generated at any time to read PS/2 data as soon as it's available, will that cause problems for other timing dependant code running on the 65C02, for instance music?

I feel it would be necessary to draw up some diagrams to fully understand how this is going to work low level.

On 12/30/2021 at 4:05 AM, martinot said:

That said; who really owns this domain and forum? Is it David, Christian or someone else?

Whois doesn't review much, but the domain owner is in California - https://www.whois.com/whois/commanderx16.com



 

On 12/29/2021 at 11:48 AM, Stefan said:

Hi,



On Facebook there was a post answered by David that I read today, and that said that there is yet no solution to the PS/2 issue.



Unfortunately, I have no clear idea of how the 65C02 -> 65C22 -> ATTINY861 setup would work.



Some thoughts:

• 
  I suppose one possibility is that the ATTINY generates a NMI on the 65C02 when there is PS/2 data to be read.
  


• 
  A drawback of this design is that the NMI could occur at any time, possibly disturbing other time critical code running on the 65C02.
  


• 
  Another design option might be to let the ATTINY buffer PS/2 codes received, and to disable PS/2 communication if the buffer is full.
  


• 
  To support both keyboard and mouse, there could be one buffer for each
  


• 
  I suppose the ATTINY cannot handle both the keyboard and mouse simultaneously. Maybe there needs to be a priority, for instance so that on receiving PS/2 data from the keyboard the mouse PS/2 line is always disabled.
  


• 
  With this setup the Kernal code could try fetching one PS/2 scan code from the keyboard and mouse buffers on each VBLANK.
  

I think that rather the CX16 would poll the ATTiny for a key on one vertical refresh and poll for a mouse event on the next and then repeat. 1/30th of a second seems to me to be fast enough that the queue should not fill up, so there is no need for an NMI.

"As yet no solution" could easily mean that the preference is to get the PS/2 straight from the 6522 if possible, and that is waiting until Michael Steil has time to work through suggested fixes. It could also easily mean that the preference is to use the ATTiny, and that is not working yet. That's among the reasons I am not keen on doing any tea leaf reading on comments like that.

On 12/30/2021 at 5:05 AM, martinot said:

Maybe it was Christian which said that this forum was setup for this purpose, and make sure that it got the official announcements?



That said; who really owns this domain and forum? Is it David, Christian or someone else?

I suspect Christian though my evidence is circumstantial. perifractic.com and commanderx16.com are both registered through Public Domain Registry while the8bitguy.com is registered through GoDaddy.

On 12/30/2021 at 6:46 PM, BruceMcF said:

I think that rather the CX16 would poll the ATTiny for a key on one vertical refresh and poll for a mouse event on the next and then repeat. 1/30th of a second seems to me to be fast enough that the queue should not fill up, so there is no need for an NMI.



"As yet no solution" could easily mean that the preference is to get the PS/2 straight from the 6522 if possible, and that is waiting until Michael Steil has time to work through suggested fixes. It could also easily mean that the preference is to use the ATTiny, and that is not working yet. That's among the reasons I am not keen on doing any tea leaf reading on comments like that.

I agree that we should refrain from both tea leaf reading, and Kremlinology, and focus on the request for assistance put out in Kevin's original post in this thread. As he hasn't yet thanked anyone for solving this, it's reasonable to believe that it isn't solved.

My intuition is that using the I2C protocol to send keyboard and mouse data from the ATTINY over the 65C22 to the 65C02 is asking for unnecessary problems.

Looking for solutions online, I particularly like at least some aspects of this one: https://blondihacks.com/veronica-keyboard/

The Veronica keyboard controller is a microprocessor that reads PS/2 data and pushes it to a shift register that is read by a 6522 which in it's turn is read by the 6502. The Veronica keyboard uses an interrupt to signal to the 6502 that there is PS/2 data to be read, and there is an interrupt handler that basically just stores the data to a keyboard buffer. The interrupt handler must run immediately and be as small as possible in order not to loose data, especially multibyte scan codes.

As far as I understand, the 65C22 has a built-in shift register that could be used by the X16 instead of an external shift register. And there is also an unused 65C22 (VIA #2) on the board if that functionality cannot be put into VIA #1.

I also think that a polling solution would be better than an interrupt firing at any time. This should be possible if the ATTINY buffers data until it's read.

I had a built a prototype when this topic first got posted using a different ATTINY, but was able to validate the path between the ATTINY and PS/2 device (in my case a PS/2 to USB adapter because I don't have a PS/2 keyboard) and an Arduino and the ATTINY using I2C + interrupt line.

I have it in my head that I had read somewhere that they had moved forward on the ATTINY based PS/2 solution so I figured they had either taken on the development internally or had chosen someone else. That said, I cannot remember clearly what I had read and cannot find any such statement now. Assume my memory is unreliable; it's what I do.

Nice work @Wavicle! 

What strategy did you have to handle PS/2-I2C conflicts? I mean what if PS/2 communication started while you were sending data over I2C. Did you just disable the PS/2 line while sending over I2C?

How did you handle multibyte scan codes? Was there a buffer?

One benefit of a shift register solution is that it might be possible to shift out bits even when receiving PS/2 data during the PS/2 clock inactive state. The inactive state is 30-50 us per bit corresponding to 300-500 processor cycles on the ATTINY @ 10MHz. Is that enough to transfer one byte? I think there's a good change you could make it fit if you look at the instruction set table for the ATTINY.

On 12/31/2021 at 9:00 AM, Stefan said:

Nice work @Wavicle! 



What strategy did you have to handle PS/2-I2C conflicts? I mean what if PS/2 communication started while you were sending data over I2C. Did you just disable the PS/2 line while sending over I2C? ...

That would seem to be the direct solution ... pull the PS2 SCL clock line low while leaving the data line high before starting to send data to the master over I2C, release it when done.