PS/2 Mouse working with ATTINY and I2C

[Wavicle]

Some more good news to share with everyone... Big shout outs to @Stefan and @ZeroByte for many hours of help with code and debugging both on the ATTINY SMC and KERNAL while getting this working. I haven't yet found a game or application to show off the mouse in action that works on R41, let me know if there's a diamond out there that I've overlooked.

 

[kelli217]

Woohoo!

[twopoint71]

That's pretty sweet. I remember working on ASM subroutines to get mouse functionality in BASIC on XT 8088s.  Was probably easier though since it was just command bits in the registers, calling an interrupt and reading the results in other registers.

[Fabio]

as quoted from the ides of march status post now we have 2 competing standards:

Quote

As for the keyboard.  Originally we were bit-banging the PS/2 keyboard from one of the 6522 chips.  This presented problems and Michael Steil was not able to get it working reliably, so we tried moving that function over to the little micro-controller that was in charge of the power/reset systems.  We figured we’d talk to the micro-controller via I2C.  Frank was going to get this working for us, but he was having trouble with it, and there hasn’t been any word from him in months.



So, we had a meeting today between me, Kevin, and Adrian Black and brainstormed ideas.  We decided to replace the micro-controller with a larger one that has enough legs to integrate onto the main memory bus.  This way it can appear as 1 or 2 memory address registers.  It can read the PS/2 key up/down signals and place them in a buffer to be read in as bytes from that address.  This should make integration into the kernel much simpler. In reality, this is how the original IBM PC worked, so there’s nothing inappropriate about doing this.



Kevin and I talked about possibly building a small cartridge for the C64 that has the microcontroller and a PS-2 port.  This way kevin could test the microcontroller code and I could write some preliminary 6502 code to prove it all works. Then hopefully somebody could integrate that into the X16 kernel. It’s really hard to test stuff on the X16 when you have to burn a ROM chip every time you want to make a change. That will be solved once we have a working keyboard and file system.

• 
  PS2 ->Attiny-> I2C-> 6522->main bus-> CPU
  


• 
  PS2-> larger micro->main bus->CPU
  

? which direction should we take and how we decide it?

[Edmond D]

On 8/9/2022 at 6:53 AM, Fabio said:

as quoted from the ides of march status post now we have 2 competing standards:

• 
  PS2 ->Attiny-> I2C-> 6522->main bus-> CPU
  


• 
  PS2-> larger micro->main bus->CPU
  

? which direction should we take and how we decide it?

I prefer the shorter path personally. Less to go wrong, and doesn't use up 6522 resources.



That being said, we're at the mercy of the team actually building the platform. It appears they've made a decision to go with the larger micro. 

Original post on 


 

On 8/9/2022 at 6:53 AM, Fabio said:

So, we had a meeting today between me, Kevin, and Adrian Black and brainstormed ideas.  We decided to replace the micro-controller with a larger one that has enough legs to integrate onto the main memory bus.

 

[TomXP411]

On 8/9/2022 at 6:53 AM, Fabio said:

as quoted from the ides of march status post now we have 2 competing standards:

• 
  PS2 ->Attiny-> I2C-> 6522->main bus-> CPU
  


• 
  PS2-> larger micro->main bus->CPU
  

? which direction should we take and how we decide it?

IMO, all other things being equal, simpler is better. And this won't even be equal, since there are performance and efficiency benefits. Integrating directly onto the system bus means fewer parts, less code, and I'm betting the  data packets can be read in far fewer steps. 

So given the choice, I'd definitely choose the larger micro controller attached directly to the main bus. 

 

[BruceMcF]

On 8/9/2022 at 9:53 AM, Fabio said:

as quoted from the ides of march status post now we have 2 competing standards:

• 
  PS2 ->Attiny-> I2C-> 6522->main bus-> CPU
  


• 
  PS2-> larger micro->main bus->CPU
  

? which direction should we take and how we decide it?

Note that "ATTiny" and "larger micro" are not strict alternatives, since there are ATTiny processors with more legs than the one used for the power supply controller. AFAIU, the ATTiny family goes as high as 28 GPIO pins.

However, also note that it seems more like a performance question: there is a CPU <-> main bus <-> 6522 <-> I2C <-> RTC path already in the design, so having the ATTiny on the I2C bus does not means more parts and is unlikely to mean substantially more code. However, the performance of access to the RTC has a lot less system-wide impact than the performance of access to the keyboard and mouse.

[Wavicle]

A microcontroller that could interface with a 6502 bus is a tall order. I don't know that there is one that could do so reliably with an 8MHz 6502 and those that could aren't usually tolerant of 5V IO.

The simplest and lowest cost way to reduce the performance impact of scanning the keyboard and mouse every VSYNC is to give the host CPU the ability to determine the source of an interrupt. That way the host only needs to query the ATTINY over I2C when there is something for it. This can be accomplished with the leftover gates on the proto 3 hardware and a single 74ACT563 IC. I've already proven that this approach works on hardware, it's now a matter of getting another design change in. That will be hard to do at this point in the design process, as it should be. I'm going to try asking/encouraging Kevin to route the IRQ wires to an appropriate footprint on the proto 4 board so that if the opportunity presents itself, it can be capitalized on by inserting a $1 chip.

[Stefan]

Just of curiosity, what timing requirements are there, if you would like to put a SMC on the data bus? Must the state of a pin be changed within half a clock cycle 1/8,000,000/2 = 62.5 ns? But there's also the clock stretching...

[Wavicle]

On 8/9/2022 at 10:14 PM, Stefan said:

Just of curiosity, what timing requirements are there, if you would like to put a SMC on the data bus? Must the state of a pin be changed within half a clock cycle 1/8,000,000/2 = 62.5 ns? But there's also the clock stretching...

Here's the timing diagram I worked out for memory reads, same essentially goes for anything responding to read cycles from the CPU.



In theory the total access time is 85ns, but more realistically most devices will have to wait until the rising edge of PHI2 to be sure that they are being addressed. Data needs to be stable 10ns before the next falling edge, so about 52.5 ns to respond. Assuming the clock of the microcontroller is independent of the host clock, it may have to give up almost one full clock before detecting the access condition. Assuming a 100MHz microcontroller with a 10ns cycle time, that works out to 4, possibly 5, cycles to respond.