Jump to content

PS/2 Direction for the Commander X16


Recommended Posts

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.
Edited by Stefan
Link to comment
Share on other sites

On 12/29/2021 at 2:38 PM, martinot said:

General question/concern; was it not the idea with this forum to get the announcements and communication from David & Co here first? 

I'm not sure if first was one of the goals. Given the number of platforms out there one would hope this would be the primary one, as I feel its a better community than FB in terms of content and structure. I read the thread on FB and things seemed to turn ugly quickly.  😞

Given that announcement , it's good to get an update on the project even though it is stalled and will have chip supply issues too. 

PS - His last here visit according to the forum SW was Oct 24th, so perhaps this is appropriate:

 

  • Haha 2
Link to comment
Share on other sites

Continuing upon my last post here.

Currently the PS/2 data and clock lines of the keyboard (and mouse?) are connected directly to VIA#1 PA0-1 and PB0-1, while VIA#2 is unused as far as I can tell.

Thoughts on pin usage:

  • The ATTINY 861 has 14 GPIO pins, and 3 of them are used for power control. That leaves us with 11 pins to handle keyboard and mouse
  • Of these, 4 pins are needed to connect the keyboard and mouse PS/2 lines. Now we have 7 pins left
  • That is clearly not pins enough to transfer one byte at a time from the ATTINY to the 65C22. Maybe you could manage to transfer one nibble at a time. But even nibble transfer requires control lines, like chip enable, data transfer direction (read/write), read/write handshake, and keyboard/mouse select.
  • If byte or nibble transfers are not possible, we are stuck with serial transfer. It's very similar to connecting the keyboard directly to the VIA, however, with the benefit of having precise control over how the ATTINY sends the data it has buffered.

Returning to @Kevin Williams's initial question in this thread: In order to write keyboard and mouse controller software for the ATTINY, there first needs to be a hardware design.

Edited by Stefan
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Edited by BruceMcF
  • Like 1
Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Edited by BruceMcF
Link to comment
Share on other sites

On 12/30/2021 at 5:50 PM, Scott Robison said:

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.

Read the front page of this site; and it say "Copyright © 2021 8-Bit Productions LLC. All rights reserved.".

Checked and it seems that  8-Bit Productions LLC is owned by David:

8-Bit Productions LLC :: Texas (US) :: OpenCorporates

 

Link to comment
Share on other sites

On 12/31/2021 at 6: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?

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.

Both PS/2 and I2C clocks are largely driven by the non-ATTINY device. As I recall there are two independent state machines that handle sending and receiving things at a byte granularity from each interface and loop code that strings bytes together into something meaningful. I did not spend any time checking corner cases and very little time debugging the code. I think I recall hooking up the oscilloscope briefly to make sure the pullups were strong enough that clocks or data weren't lost to stray capacitance. Pretty much the minimum to prove out the basic idea. The prototype sat on the side of my workbench for a few weeks but was disassembled when I needed an Arduino for a quick sketch to show my 11 year old how controlling servos works. The code is still around somewhere; I don't think I ever intentionally delete code.

Link to comment
Share on other sites

On 12/31/2021 at 12:38 PM, martinot said:

Read the front page of this site; and it say "Copyright © 2021 8-Bit Productions LLC. All rights reserved.".

Checked and it seems that  8-Bit Productions LLC is owned by David:

8-Bit Productions LLC :: Texas (US) :: OpenCorporates

 

Interesting. It wouldn't be unusual for someone on a team who was working on an aspect of a project to assign copyright to the parent organization. I mean, Mark Zuckerberg probably isn't asked personally about all the copyright notices that are attached to Meta owned properties. Yes, it is a different situation, I just don't know if a copyright notice changes anything about the level of authority. But it is interesting.

Link to comment
Share on other sites

  • Administrators

As Scott Robison mentioned, I rarely visit this website.  It was originally Perifractic's idea and I told him when he created it that I didn't have time for yet another social media platform.  I come by every now and then to check in.  In fact the entire future of this website is in limbo since Perifractic was paying for it before.  After he left the project, I was asked to start paying for it and I declined.  I'm already in quite a bit of debt on the X16 project, and this website was never my idea.  So if somebody else wants to keep it going, that's totally fine by me.  But I won't be spending any money on it.   It has been discussed possibly replacing the forum with a discord channel or something.  But that won't save the software repository.  So I'm not sure what we'll do about that.  

  • Thanks 2
Link to comment
Share on other sites

On 12/31/2021 at 10:52 PM, The 8-Bit Guy said:

I'm already in quite a bit of debt on the X16 project, and this website was never my idea.  So if somebody else wants to keep it going, that's totally fine by me.  But I won't be spending any money on it.   It has been discussed possibly replacing the forum with a discord channel or something. 

Perhaps move it do some free forums? Maybe Discord could provide that.

 

Link to comment
Share on other sites

On 1/1/2022 at 12:49 AM, Justin Baldock said:

I also would chip in to help keep the site running.

Same for me. Let us know how we can help

Edit: By the way, we're going a bit out of topic here 😅

Edited by VincentF
  • Thanks 1
Link to comment
Share on other sites

  • Super Administrators

Off-topic: Just to clarify a little further, yes I am hosting the site still. The site’s creation came about with the endorsement of the whole X16 dev team on Slack, and indeed everyone seemed quite pleased with it initially. It even allowed David to shut down his own forum Murray2 with his brother and move the archives to this one. The team were all encouraged to post official updates here first, and copy the forum url to Facebook. However I think people just find Facebook quicker, and ultimately I couldn’t force the team to keep updates going here without starting to sound like I was nagging them each time 😅

Still I think it’s a wonderful site and @MattGrandisand I are very pleased with it, particularly the software library with built in emulator. Don’t see that very often elsewhere!

That is why, when there were no other offers from the team to keep the site alive, I financed another year of it recently even though I had stepped back from the X16 project itself. There’s a ton of time and work here that would’ve been lost and disappointed hundreds of people  

We’re open to passing the baton to the community as long as it is properly maintained and moderated. Feel free to DM @MattGrandis and I in a group message if you are serious about taking it on. I’m already discussing with one member also but we have about 8 months before we have to make the switch so no rush.

Thanks for your belief in the site as a cool place to be and a useful ecosystem. Happy new year! 

  • Like 10
  • Thanks 3
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