6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 01, 2024 5:24 am

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sun Apr 02, 2006 11:02 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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, [b]level-mode[/i] (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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Apr 03, 2006 7:04 am 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8534
Location: Southern California
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?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Apr 03, 2006 9:07 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Apr 03, 2006 12:38 pm 
Offline

Joined: Sun Feb 05, 2006 1:20 am
Posts: 21
Location: The Netherlands
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.

_________________
I trust my somewhat flawed English is comprehensible to all.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Apr 03, 2006 5:06 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Apr 07, 2006 7:38 pm 
Offline

Joined: Sun Feb 05, 2006 1:20 am
Posts: 21
Location: The Netherlands
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

_________________
I trust my somewhat flawed English is comprehensible to all.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Jul 31, 2006 1:16 pm 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
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:
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!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Aug 06, 2006 5:41 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: