PS/2 Mouse working with ATTINY and I2C

[BruceMcF]

On 8/9/2022 at 10:28 PM, Wavicle said:

A microcontroller that could interface with a 6502 bus is a tall order. ...

It depends on the interface, doesn't it? If you have the means to let the MCU know that you want to talk to it (REQUEST) and a means for the MCU to signal whether its ready to give/receive a byte (ACK), then the access protocol can be designed to work with the speed of the MCU. It works best if the REQUEST and ACK signals show up in specific spots in an I/O slot, but if some of that logic can be done with spare gates already present in the design, it might be doable with little or no additional glue logic.

[Stefan]

On 8/10/2022 at 2:36 PM, BruceMcF said:

It depends on the interface, doesn't it? If you have the means to let the MCU know that you want to talk to it (REQUEST) and a means for the MCU to signal whether its ready to give/receive a byte (ACK), then the access protocol can be designed to work with the speed of the MCU. It works best if the REQUEST and ACK signals show up in specific spots in an I/O slot, but if some of that logic can be done with spare gates already present in the design, it might be doable with little or no additional glue logic.

Will that kind of solution require you to slow down the 65C02 clock? How would you do that?

[BruceMcF]

On 8/10/2022 at 9:48 AM, Stefan said:

Will that kind of solution require you to slow down the 65C02 clock? How would you do that?

(1) You don't necessarily have to slow down the clock. If a write to a particular address triggers an interrupt in the MCU (REQUEST), and the MCU can set a GPIO that shows up at an address as low when the MCU is not ready and high when it is ready (or visa versa) (ACK), then the protocol can check that the MCU is ready for the next step in the protocol. After all, you are programming for an MCU routine that you have also programmed, so you don't have to hit arbitrary times specified in a pre-existing protocol.

Note that ACK could actually only be a single GPIO output connected through to D7 (when reading the correct address in that I/O slot), so that "BIT MCURDY" can put the state into the sign flag for BPL / BMI to use. With that design, you don't actually have to put a BIT mask into the accumulator, because you don't care what the state of the Z flag is after the BIT operation.

(2) If you want to slow down the clock, you can use the RDY line. It should still have some support circuitry doing that, so that the RDY line setting by the MCU only connects through to the CPU when the MCU I/O address space is accessed. Unlike the NMOS 6502, the RDY line on the 65C02 holds the CPU for both reads and writes.

Stretching the clock is indeed a general option (and with a counter based clock circuit, you can even get an "unstretched" clock output for the VIAs so that the VIA clock input remains steady), but since the 65C02 clock circuit is presently using a binary counter and jumpers to allow setting the clock to 1MHz / 2MHz / 4MHz / 8MHz, it seems like a clock stretching circuit for the CX16 would be more complex than if the inputs to the binary counter are not already put to use in the circuit for something else.

[Stefan]

On 8/10/2022 at 6:55 PM, BruceMcF said:

(1) You don't necessarily have to slow down the clock. If a write to a particular address triggers an interrupt in the MCU (REQUEST), and the MCU can set a GPIO that shows up at an address as low when the MCU is not ready and high when it is ready (or visa versa) (ACK), then the protocol can check that the MCU is ready for the next step in the protocol. After all, you are programming for an MCU routine that you have also programmed, so you don't have to hit arbitrary times specified in a pre-existing protocol.



Note that ACK could actually only be a single GPIO output connected through to D7 (when reading the correct address in that I/O slot), so that "BIT MCURDY" can put the state into the sign flag for BPL / BMI to use. With that design, you don't actually have to put a BIT mask into the accumulator, because you don't care what the state of the Z flag is after the BIT operation.



(2) If you want to slow down the clock, you can use the RDY line. It should still have some support circuitry doing that, so that the RDY line setting by the MCU only connects through to the CPU when the MCU I/O address space is accessed. Unlike the NMOS 6502, the RDY line on the 65C02 holds the CPU for both reads and writes.



Stretching the clock is indeed a general option (and with a counter based clock circuit, you can even get an "unstretched" clock output for the VIAs so that the VIA clock input remains steady), but since the 65C02 clock circuit is presently using a binary counter and jumpers to allow setting the clock to 1MHz / 2MHz / 4MHz / 8MHz, it seems like a clock stretching circuit for the CX16 would be more complex than if the inputs to the binary counter are not already put to use in the circuit for something else.

Seems reasonable you could use the RDY pin for this purpose, if it can halt all operations as you describe.

The first option---doing this without clock stretching---I do not fully understand. If the SMC is to drive the data bus without clock stretching, even to put just a one bit ready signal there, mustn't that be done within the strict timing limits that @Wavicle discussed above? And if the SMC was to drive the data bus outside those timing limits, wouldn't that corrupt the data bus?

EDIT: Another thing. In (2) I suppose the SMC must drive the RDY line within the 65C02 timing limits, that is 4--5 clock cycles for a microcontroller doing 100 MHz, according to @Wavicle above. Could that be a problem, as the SMC has several interrupt driven tasks it's running in parallel---being a host=slave for two PS/2 devices? The SMC could easily spend more than 5 clock cycles handling an incoming PS/2 bit at the same time the 65C02 wants to read a value.

[BruceMcF]

On 8/10/2022 at 12:22 PM, Stefan said:

Seems reasonable you could use the RDY pin for this purpose, if it can halt all operations as you describe.



The first option---doing this without clock stretching---I do not fully understand. If the SMC is to drive the data bus without clock stretching, even to put just a one bit ready signal there, mustn't that be done within the strict timing limits that @Wavicle discussed above? And if the SMC was to drive the data bus outside those timing limits, wouldn't that corrupt the data bus?



EDIT: Another thing. In (2) I suppose the SMC must drive the RDY line within the 65C02 timing limits, that is 4--5 clock cycles for a microcontroller doing 100 MHz, according to @Wavicle above. Could that be a problem, as the SMC has several interrupt driven tasks it's running in parallel---being a host=slave for two PS/2 devices? The SMC could easily spend more than 5 clock cycles handling an incoming PS/2 bit at the same time the 65C02 wants to read a value.

This is where the glue logic I mentioned would come in ... in (2) the MCU starts with the GPIO pin that asserts the RDY already in the state to hold the CPU in RDY state, and the circuit connects that pin TO the CPU RDY line in the cycle that that I/O select is asserted with that address selected. Then the MCU does its stuff, and when it is finished and either the data is read by the MCU (if its a 6502 Write cycle) or the data is latched and available at the MCU (in a 6502 Read cycle), it releases the RDY state and the CPU keeps going where it left off. The code that is accessing the MCU would be written with the knowledge of how long after the RDY is released that the RDY will be back in the hold state, so it just wouldn't access that address "too early".

In (1), again, there could be a hardware circuit that only connects the ACK line to D7 during the read cycle of the appropriate address. So the ACK starts out in the "no acknowledge" state, and when the MCU has received an handshake signal from the CPU and is ready to process it, it puts the ACK GPIO into the "acknowledge" state. As far as which state is ACK and which is NO-ACK, you design the protocol so that the state it comes up in after a reset is the NO-ACK state, so that positive action is required by the MCU in order to put it into ACK state.

[Stefan]

To be clear, in (2), the glue logic you are talking about could it be something like this?

A sufficiently wide address decoder.

The decoder output and the micro controller "request RDY" pin is run through a NAND gate

The NAND output is connected to the 65C02 RDY pin (active low).

[Wavicle]

On 8/10/2022 at 8:55 AM, BruceMcF said:

(1) You don't necessarily have to slow down the clock. If a write to a particular address triggers an interrupt in the MCU (REQUEST), and the MCU can set a GPIO that shows up at an address as low when the MCU is not ready and high when it is ready (or visa versa) (ACK), then the protocol can check that the MCU is ready for the next step in the protocol. After all, you are programming for an MCU routine that you have also programmed, so you don't have to hit arbitrary times specified in a pre-existing protocol.



Note that ACK could actually only be a single GPIO output connected through to D7 (when reading the correct address in that I/O slot), so that "BIT MCURDY" can put the state into the sign flag for BPL / BMI to use. With that design, you don't actually have to put a BIT mask into the accumulator, because you don't care what the state of the Z flag is after the BIT operation.



(2) If you want to slow down the clock, you can use the RDY line. It should still have some support circuitry doing that, so that the RDY line setting by the MCU only connects through to the CPU when the MCU I/O address space is accessed. Unlike the NMOS 6502, the RDY line on the 65C02 holds the CPU for both reads and writes.



Stretching the clock is indeed a general option (and with a counter based clock circuit, you can even get an "unstretched" clock output for the VIAs so that the VIA clock input remains steady), but since the 65C02 clock circuit is presently using a binary counter and jumpers to allow setting the clock to 1MHz / 2MHz / 4MHz / 8MHz, it seems like a clock stretching circuit for the CX16 would be more complex than if the inputs to the binary counter are not already put to use in the circuit for something else.

I've done the clock stretching circuit that works with the clock divider and delivers an unstretched clock to the VIAs. It was needed to enable reading from the YM2151 at 8MHz. At max stretch, it slows the high phase of PHI2 to an effective speed of 2MHz.

I had designed a circuit for interfacing a microcontroller to the 6502 bus. It doesn't assert RDY but does have the ATTN/ACK signals in bits 6 and 7. It's a bit out of date, but the principal is still valid. It required 6 ICs. That would be a big architectural change. The design for it is up on GitHub here: jburks/X16-Simple-Intf: A very simple X16 to microcontroller interface. (github.com).

With any change at this point the biggest questions become: Is the architectural risk justified by what it returns? How much does it increase complexity / the ability of the average enthusiast to understand the overall design (the "VIC-20" standard)? We have a working keyboard and mouse solution; what does the change proposed get us? Querying SMC over I2C every VSYNC has a performance hit of ~3% (30ms spent performing I2C transactions per second). There are some protocol tricks that could shave a little bit of time off of that (e.g. have a combined keyboard + mouse transaction instead of a transaction for each), but if we ignore those and just consider the 3% number - what will we gain from throwing more hardware at the problem? A 3% hit to an 8MHz 8-bit retro system still leaves us with a screaming fast retro system.

[ZeroByte]

If there were legs available, you could just wire them to a data port on VIA1 and have them as "data waiting" bits that only requires 4 cycles to read (assuming nobody has futzed with the DDR on VIA1)

[Fabio]

I didn't want to belittle Wavicle's work. I just expected instead that someone in the core team to say: "I2C works fine and it becomes our official choice" or: "we're sorry but the bus integrated mcu is almost ready and uses this glue logic .....".

In the IO map VIA 1 used 4 pins to bit bang mouse & keyboard now they are free and 2 can be used to signal keyboard data or mouse data waiting respectively.

another question: VIAs have a hardware shift register, is it used or usable anywhere?

 

[Wavicle]

On 8/12/2022 at 6:06 AM, Fabio said:

I didn't want to belittle Wavicle's work. I just expected instead that someone in the core team to say: "I2C works fine and it becomes our official choice" or: "we're sorry but the bus integrated mcu is almost ready and uses this glue logic .....".



In the IO map VIA 1 used 4 pins to bit bang mouse & keyboard now they are free and 2 can be used to signal keyboard data or mouse data waiting respectively.



another question: VIAs have a hardware shift register, is it used or usable anywhere?



 

Unfortunately, at this instant in time there isn't much of an active core team. @Michael Steil was pretty active this past spring, but other obligations consumed his available time just before summer started. Since then, @Kevin Williams has been pretty active but in the past couple of weeks he has been busy filling orders for his paying gig and is now spending what free time he has prepping for VCF Midwest. I've exchanged maybe 3 emails with David in the last 6 months, and he had neither spare time nor X16 hardware of his own. He's been happy to hear about the progress but hasn't been able to get much involved.

To the best of my knowledge there are two functional proto 3 boards (Michael has one and Kevin has the other); a third for David started getting built just this past week. I've sent Kevin three of my clock-stretching modules which I hope will make it into all three of those boards; the proto 4 boards will hopefully contain the clock stretching circuit and have no need for the module. It is also my understanding that the biggest blocker preventing more proto 3 boards from being built is the lack of a working keyboard. There is no hardware for anyone to prototype such an MCU solution - but there is a fully functional I2C-based keyboard solution which has been tested and works on my hardware and Kevin's proto 3 board. If nothing else, the new functionality here should unblock X16 development.

For comparison, I have three functional X16-compatible computers of my own design on my bench: "Antares" and "Canopus" that are fully functional on manufactured PCBs; and "Breadboard16" which was fully functional at one time, but now exists only for nostalgia.