|
The ZIP Parallel Interface : Zip protocol handshake
All connection to the zip drive is braced by the following sequence
parport_claim()
connection_and_select()
commands [and data]
ending
status
disconnect()
connect, reset, disconnect()
parport_release()
Claim and release have been discussed earlier. They are the essential mechanism to prevent other applications from obtaining the interface.
connection_and_select()
All communication with a zip drive begins with a connection and selection sequence to that drive.
For ppa chips
At the end of the selection sequence the status is expected to be 0xE0 command wanted.
Command Sequence
Commands to the zip drive are sent in exactly the same manner as data transfers in exactllt the same mode (epp or spp).
Depending on the command, the status will vary between wanting more commands, wanting data, sending data, or simply idle
Data Sequence.
Data to the Zip drive is simply sent. (just like commands).
Data FROM the zip drive requires that the interface is turned around. This is done 'as is' by ppa devices, but, for IMM devices, the interface must be negotiated if it is in spp mode (epp works normally), and at the end of the transfer and ackowledge sequence is required.
At the end of the data transfer, the interface is expected to be in the idle state
Ending Status
A two byte scsi status is available at the zip drive. Since this is a read mode, IF the interface is an IMM chip, AND it is in spp mode, then the negotiate and acknowledge sequence is also required.
Connect, reset, Disconnect
To make the interface available to other devices. The zip drive is reset at the completion of a task,