6502.org

I've used nearly all of the many different features of the '22, but automatic handshaking has not been one of them. The data sheet addresses it though, starting in section 2.2 on page 10.

Don’t know how well the 65C22’s automatic handshake works, but I recall it didn't work well in Commodore’s 6526, at least in one application. I tried setting up the user port on a C-128 as a Centronics port to drive a parallel printer, using the auto-handshake to toggle the printer’s /STROBE input. The printer wouldn’t respond, which I later discovered was a timing issue with auto-handshake.

The Centronics standard requires that a minimum of one microsecond elapse after D0-D7 is written before toggling /STROBE. After being driven low, /STROBE must stay low for at least one microsecond before going high. What was happening was the 6526 was toggling /STROBE around 100 nanoseconds after driving the data onto D0-D7. The required setup time before /STROBE was being toggled was insufficient to give the device at the other end enough “warning” that data was on the way.

I ended up using one of the port-B lines as /STROBE, since I could control the elapsed time from when D0-D7 was written to when the remote device was strobed.

Re: GARTHWILSON
Re: BigDumbDinosaur
The way I'm thinking of doing it is, this. This is all with the FT245RL USB controller in mind.

READ FROM USB
Controller's !RD is set low via PORTB line 0, by default. USB data is now shifting into controller and thus onto PORT A from the connected device.
Controller pulls !RXF low (it does this internally), connected to VIA's CA1 indicating that the data is ready, PORT A is latched onto DATA bus and IRQ is set.

WRITE TO USB
Controller sets its !TXE low, indicating it is ready to receive data, connected to VIA's CA1.
When the VIA's both CS are active, i.e. it has been addressed and the CPU is writing (R!W is low), it latches DATA bus onto PORT A, since CA1 is low.
On the next clock edge, we set the controller's WR high (via PORTB line 1) and it starts transmitting the data on PORT A to the USB lines.
And on the next clock edge to that, we set the WR low again.

This scheme assumes it takes less time than one CPU clock cycle to transmit one byte over the USB lines.
Please let me know what you think. Have I misunderstood or made an error?

I've mostly used the mode where it automatically sends just a single clock cycle pulse, to clock flipflops or latches automatically after I write to a port. But if you're connecting to some existing protocol then I guess you have to be lucky and find it matches what the 6522 can do.

There is a mode where it holds one handshake line low until the remote end pulls the other one low to confirm receipt. Maybe that would have worked better for the printer you used - I think the BBC Micro did use it this way for example.

The Beeb uses Port A of one of the VIAs in a more or less standard data+strobe... wait for ack mode. I used several different printers with it, never noticed any issues - it "just worked" from what I recall.

Extract of the schematic here:
The busy signal isn't used, but the ACK from the Printer goes to CA1 and the Strobe comes from CA2.

-Gordon