Z85C3010PSG Zilog, Z85C3010PSG Datasheet - Page 268

• Manufacturer Part Number: Z85C3010PSG
• Description: IC 10MHZ Z8500 CMOS SCC 40-DIP
• Manufacturer: Zilog
• Series: SCCr

Specifications of Z85C3010PSG

• Processor Type: Z80
• Features: Error Detection and Multiprotocol Support
• Speed: 10MHz
• Voltage: 5V
• Mounting Type: Through Hole
• Package / Case: 40-DIP (0.620", 15.75mm)
• Cpu Speed: 8MHz
• Digital Ic Case Style: DIP
• No. Of Pins: 40
• Supply Voltage Range: 5V
• Operating Temperature Range: 0°C To +70°C
• Svhc: No SVHC (18-Jun-2010)
• Base Number: 85
• Rohs Compliant: Yes
• Clock Frequency: 10MHz
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant
• Other names: 269-3934; Z85C3010PSG

UM010901-0601
Dynamic Node ID
LLAP requires the use of an 8-bit node identifier number
(node ID) for each node on the link. Apple had decided that
all LLAP nodes must have a dynamically assigned node
ID. A node would assign itself its unique address upon
activation. It is then up to that particular node to ascertain
that the address it had chosen is unique. A node randomly
chooses an 8-bit address (for example, the refresh register
value on the Z80181 is added to a randomly chosen value
on the receive buffer to obtain a pseudo random 8-bit
address).
The node then sends out an LLAP Enquiry control packet
to all the other nodes and waits for the prescribed
interframe gap of 200 sec. If another node is already
using this node ID, then that node must respond within 200
new node must then rebroadcast a new guess for its node
ID. If a LLAP Acknowledgment packet is not received
within 200
address is indeed unique. The new node must rebroadcast
the LLAP enquiry packet several more times to account for
cases when the packet could have been lost or when the
guessed node ID is busy and could have missed the
Enquiry packet.
LLAP Packet
LLAP packets are made up of three header bytes
(destination ID, source ID and LLAP type) and 0 to 600
bytes of variable length data. The LLAP type indicates the
type of packet that is being sent. 80H to FFH are reserved
as LLAP control packets. The four LLAP control packets
that are currently being used are: The lapENQ, which is
used as enquiry packet for dynamic node assignments;
the lapACK, which is the acknowledgment to the lapENQ;
the lapRTS, which is the request to send packet that
notifies the destination of a pending transmission; and the
lapCTS, which is the clear-to-send packet in response to
the RTS packet. Control packets do not contain data fields.
LLAP Packet Transmission
LLAP distinguishes between two types of transmissions: a
directed packet is sent from the source node to a specific
destination node through a directed transmission dialog; a
broadcast packet is sent from the source node to all nodes
on the link (destination ID is FFH) through a broadcast
transmission dialog. All dialogs must be separated by a
minimum Inter Dialog Gap (IDG) of 400
within these dialogs must be separated from each other
with a maximum Inter Frame Gap (IFG) of 200 sec.
sec with a LLAP Acknowledgment control packet. The
sec then the new node assumes that the
Technical Considerations When Implementing LocalTalk Link Access Protocol
sec. Frames
The source node uses the physical layer to detect the
presence or the absence of data packets on the link. The
node will wait until the line is no longer busy before
attempting to send its packets. If the node senses that the
line is indeed busy, then this node must defer. When the
node senses that the line is idle, then the node waits the
minimum IDG plus some randomly generated time before
sending the packet (the line must remain idle throughout
this period before attempting to send the packet). The
initial packets to be sent are handshaking packets. The
first packet sent by the source node to its destination node
is the RTS packet. The receiver of this RTS packet must
return a CTS packet within the allowable maximum IFG.
The source node then starts transmitting the rest of its data
packet upon receiving this CTS.
Collisions are more likely to occur during the handshaking
phase of the dialog. The randomly generated time that is
added to the IDG tends to help spread out the use of the
link among all the transmitters. A successful RTS to CTS
handshake signifies that a collision did not take place. An
RTS packet that collides with another frame has corrupt
data that shows up as a CRC error on the receiving or the
destination node. Upon receiving this, the destination node
infers that a collision must have taken place and abstains
from sending its CTS packet. The source or the
transmitting node sees that the CTS packet was not
received during the IFG and also infers that a collision did
take place. The sending node then backs off and retries.
The LLAP keeps two history bytes that log the number of
deferrals and collisions during a dialog. These history
bytes help determine the randomly generated time that is
added to the IDG. The randomly generated time is
readjusted according to the traffic conditions that are
present on the link. If collisions or deferrals have just
occurred on the most recently sent packets, then it can be
assumed that the link has heavier than usual traffic. Here,
the randomly generated number should be a larger
number in order to help spread out the transmission
attempts. Similarly, if the traffic is not so great, then the
randomly generated number should be smaller, thus
reducing the dispersion of the transmission attempts.
LocalTalk Physical Layer
LocalTalk uses the SDLC format and the FM0 bit encoding
technique.
transmission and reception was chosen over the RS-232
because a higher data rate over a longer physical distance
is required. LocalTalk requires signals at 230.4 Kbits per
second over a distance of 300 meters.
The
RS-422
signalling
Application Note
standard
6-133
for
1