6522 Parallel Handshake Performance

[kc5tja]

According to my datasheets at home, the 65C22 requires an enormous amount of time to transfer data using the parallel handshake mode of operation. By my calculations, a 1MHz part can, at best, transfer only 20KBps or so through that port, making it not all that much faster than the serial port (and I'd wager a guess, even slower than the serial port under some circumstances).

Can anyone confirm the performance by actual real-world measurements of the timing characteristics of the 6522 port A operation in automatic, level-mode (iow, not pulse mode), automated handshake mode?

I would do it myself, but alas, my Kestrel 1 is in pieces right at the moment, and part of this exercise is, in fact, to design the next Kestrel board.

Thanks.

[GARTHWILSON]

A quick (non-detailed) look at the timing diagrams tells me you're including interrupt (and interrupt-source polling) overhead in that figure. Is that right?

[kc5tja]

No. I'm going *exclusively* based on documented timing diagrams. If you look on page 41 of the 6522 data sheet, in figure 3-7, there is a large ambiguity on the data sheet with respect to t21 (which I'm interpreting as tRS1, since there is no t21 in the timing parameters); its unit is labeled *microseconds*, not nanoseconds. If true, then the protocol overhead from write-to-read-and-back will reduce throughput on a 1MHz part quite significantly.

[raccoon]

I assume you are using the WDC W65C22S datasheet, as figure and page numbers you mentioned match.
It looks like this datasheet is a mess. The more I looked into the problem, the more inconsistencies, obvious typos and suspicious data I encountered.

The table *does* contain t21 = 535ns max, although it should be a minimum value and refer to figure 3-7 . t21 is the time the device waits for the listener to respond. It requiring a maximum makes no sense.
tRS1 has nothing to do with handshake mode. Anyway, this data has problems of its own. It should refer to figure 3-4. The value taking almost exactly 1000 clock cycles is highly suspicious. It should be in ns.

In many cases, though not all, nanoseconds is expressed as nS instead of ns.....

Need I continue?
If you want to design strictly by the book, you might as well forget about it.

[kc5tja]

Since what I purchase is determined by published figures, I have no choice but to go by the book.

Also, S is the SI unit for conductivity (Siemens), and not a unit of measure of time. s is more correct.

Having a maximum time to wait for a response is logical -- what if the peripheral never responds? Having a minimum time makes no sense to me -- what if it responds so fast that the VIA doesn't register the acknowledgement? Either way results in a deadlock condition without some form of external watch dog, and some means of resetting that functionality of the chip.

[raccoon]

kc5tja wrote:

Having a maximum time to wait for a response is logical -- what if the peripheral never responds?

Handshake acknowledgements can take an indefinite amount of time. The 65C22 was not designed to detect time outs. If your system is in danger of encountering deadlocks, you should have the software detect time outs and take appropriate measures.

kc5tja wrote:

Having a minimum time makes no sense to me -- what if it responds so fast that the VIA doesn't register the acknowledgement?

It's only approx. one Phi2 cycle. It means the listener shouldn't respond instantaneously, which is meaningless in handshaking. (If it did respond instantaneously, handshaking would serve no purpose.)

kc5tja wrote:

Since what I purchase is determined by published figures, I have no choice but to go by the book.

Poorly written datasheets are becoming an increasing problem. If you encounter an obvious flaw, there are a few things you can do:
* Contact the manufacturer to obtain the right data (the hard way)
* Avoid dependancy of this data
* Ignore the faulty data and replace it by what seems plausible, if possible
* Throw the datasheet and the components away

Edited by raccoon on Apr 8 2006 , 13:05 UTC

[Mats]

Reading this correspondence I get puzzled! I think the referenced diagram on page 41 has little to do with a maximal bit rate but rather explains the logic of the transfer! There are certainly no restictions on speed for a transfer other then the basic speed of the processor!

A


LDA Port

or a

STA Port

takes the same time if "Port" is an I/O register of a 6522 or RAM/ROM

a typical handshake write would be programmed as follows

Code: Select all

L1   <fetch the value to be written and put it in the X register>
      LDA #$02     ; THE MASK
L2    BIT IFR      ;POLLING THE INTERRUPT FLAG REGISTER
      BEQ L2
      STX PORT   ;WRITE TO THE I/O REGISTER
      JMP L1

If the reciever is faster then your 6502 system the "BEQ L2" branch will never be taken and you just have to add up the cycles needed for going through these instructions. The CPU does not wait for the 6522 in any way and the transfer speed has nothing to do with the diagrams on page 41!

Another matter is that too high transfer rates can lead to inductive "cross-talk" in the cable connection. It could be necessary to build in additional "wait loops" to hold the transfer rate down!

[kc5tja]

Mats wrote:

Reading this correspondence I get puzzled! I think the referenced diagram on page 41 has little to do with a maximal bit rate but rather explains the logic of the transfer! There are certainly no restictions on speed for a transfer other then the basic speed of the processor!

This was never in question. The question lay *specifically* with the timing of the 6522 chip *itself.* Of course I already know about the CPU timing issues.