Recognized as an
`American National Standard (ANSI)
`
`IEEE Std 1284-1994
`
`IEEE Standard Signaling Method for
`a Bidirectional Parallel Peripheral
`Interface for Personal Computers
`
`IEEE Computer Society
`
`.-
`
`Sponsored by the
`Microprocessor and Microcomputer Standards Committee
`
`h
`
`Published by the Institute of Electrical and Electronics Engineers, Inc., 345 East 4Tth Street, New York, N y lwlz USA.
`December 2, 1994
`
`SH 1 7335
`
`lEEE
`
`Papst Licensing GmbH & Co., KG.
`Petitioner - Huawei, LG and ZTE
`Patent Owner - Papst Licensing GmbH & Co., KG.
`IPR2017-00448
`EXH. 2004
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`1
`
`

`

`THIS PAGE WAS
`BLANK IN THE ORIGINAL
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`2
`
`

`

`Recognized as an
`American National Standard (ANSI)
`
`IEEE Std 1284-1994
`
`IEEE Standard Signaling Method for a
`Bidirectional Parallel Peripheral
`Interface for Personal Computers
`
`Sponsor
`Microprocessor and Microcomputer Standards Committee
`of the
`IEEE Computer Society
`
`-
`
`Approved March 30, 1994
`IEEE Standards Board
`
`Approved September 2, 1994
`American National Standards Institute
`
`Abstract: A signaling method for asynchronous, fully interlocked, bidirectional parallel communica-
`tions between hosts and printers or other peripherals is defined. A format for a peripheral identifi-
`cation string and a method of returning this string to the host outside of the bidirectional data stream
`is also specified.
`
`Keywords: bidirectional parallel communications, computers, interfaces, PCs, personal comput-
`ers, printers
`
`The Institute of Electrical and Electronics Engineers, Inc.
`345 East 47th Street, New York, NY 10017-2394, USA
`
`Copyright 0 1994 by the Institute of Electrical and Electronics Engineers, Inc.
`All rights reserved. Published 1994. Printed in the United States of America.
`
`ISBN 1-55937-427-6
`
`No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
`wriffen permission of the publisher.
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`3
`
`

`

`IEEE Standards documents are developed within the Technical Committees of the
`IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
`Board. Members of the committees serve voluntarily and without compensation.
`They are not necessarily members of the Institute. The standards developed within
`IEEE represent a consensus of the broad expertise on the subject within the Institute
`as well as those activities outside of IEEE that have expressed an interest in partici-
`pating in the development of the standard.
`
`Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard
`does not imply that there are no other ways to produce, test, measure, purchase, mar-
`ket, or provide other goods and services related to the scope of the IEEE Standard.
`Furthermore, the viewpoint expressed at the time a standard is approved and issued is
`subject to change brought about through developments in the state of the art and
`comments received from users of the standard. Every IEEE Standard is subjected to
`review at least every five years for revision or reaffirmation. When a document is
`more than five years old and has not been reaffirmed, it is reasonable to conclude that
`its contents, although still of some value, do not wholly reflect the present state of the
`art. Users are cautioned to check to determine that they have the latest edition of any
`IEEE Standard.
`
`Comments for revision of IEEE Standards are welcome from any interested party,
`regardless of membership affiliation with IEEE. Suggestions for changes in docu-
`ments should be in the form of a proposed change of text, together with appropriate
`supporting comments.
`
`Interpretations: Occasionally questions may arise regarding the meaning of portions
`of standards as they relate to specific applications. When the need for interpretations
`is brought to the attention of IEEE, the Institute will initiate action to prepare appro-
`priate responses. Since IEEE Standards represent a consensus of all concerned inter-
`ests, it is important to ensure that any interpretation has also received the concurrence
`of a balance of interests. For this reason IEEE and the members of its technical com-
`mittees are not able to provide an instant response to interpretation requests except in
`those cases where the matter has previously received formal consideration.
`
`Comments on standards and requests for interpretations should be addressed to:
`
`Secretary, IEEE Standards Board
`445 Hoes Lane
`P.O. Box 1331
`Piscataway, NJ 08855-1331
`USA
`
`IEEE standards documents may involve the use of patented technology. Their
`approval by the Institute of Electrical and Electronics Engineers does not mean that
`using such technology for the purpose of conforming to such standards is authorized
`by the patent owner. It is the obligation of the user of such technology to obtain all
`necessary permissions.
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`4
`
`

`

`Introduction
`
`(This introduction is not a part of IEEE Std 1284-1994, IEEE Standard Signaling Method for a Bidirectional Parallel
`Peripheral Interface for Personal Computers.)
`
`This standard was formally started as an IEEE effort in January 1992, but without the advance work done by
`a loose alliance of printer manufacturers and printer software developers called the Network Printing Alli-
`ance, this standard would not be possible.
`
`At the time it was completed, the key contributors to the IEEE P1284 Working Group were as follows:
`
`Forrest D. Wright, Chair
`Michael Timperman, Editor
`Robert Hillis, Secretary
`
`Aldo Alesii
`Chirag Bakshi
`Motti Beck
`Eric Bokman
`James Booth
`Robert Botchek
`Kerry Bott
`Sylvan Butler
`Clark Buxton
`Angel Colon
`Darrell Cox
`Blaine Davies
`Steve Delnista
`Mike Dobbs
`Claudio Edelman
`James Edwards
`Boris Elpiner
`Michael Fink
`Neal Fischer
`Raimundo Garcia
`
`Steven Goss
`Robert Gross
`Pat Hacker
`Robert Herron
`Ken Hilliard
`Barry Hills
`George Horansky
`Richard Horton
`Bill Hurdle
`Arlin Jones
`Tony Kiburis
`Eric Kuang
`Boon Lim
`Peter Macourek
`Cynthia Magidson
`Ernie Mandese
`Martin Michael
`Joseph Mouhanna
`Roman Orzol
`Greg Peek
`
`The following persons were on the balloting committee:
`
`Scott Akers
`Keith D. Anthony
`Chirag Bakshi
`David Bartek
`Russell A. Beverly
`Christos Bezirtzoglou
`David Brearley
`Charles Brill
`Myron A. Calhoun
`Clyde Camp
`C. H. Chen
`Darrell Cox
`Craig Curtin
`Michael D. Dobbs
`Gordon Force
`Jerry V. Gilbert
`Julio Gonzalez Sanz
`Steven Goss
`William Groseclose
`Peter B. Gutgarts
`Pat Hacker
`
`Kenneth C. Heck
`Scott Hopkinson
`John C. Hoppe
`George Horansky
`Lak Ming Lam
`Tuvia Lamdan
`Min-Suk Lee
`Rollins Linser
`Andy J. Luque
`Stephen Mabbs
`Ernest N. Mandese
`Grzegorz Mazur
`Ed McCreight
`William C. McDonald
`Bruce Millard
`Anthony J. Moreno
`Klaus Dieter Mueller
`Roman Orzol
`Elwood Parsons
`Francisco Pataro
`L. M. Patnaik
`Mira Pauker
`
`Brian Pendleton
`Suzanne Price
`Dinesh Rao
`David Roach
`David Rosen
`Fred Schlaffer
`P.V. Shivkumar
`Ron Smith
`Jim Soriano
`Larry Stein
`Michael Stilz
`Stephen Tarr
`David Voth
`William Wagner
`James Ward
`Rusty Weyand
`Keith Winter
`Lloyd Young
`Fred Young
`Desmond Yuen
`
`Suzanne L. Price
`Brian Ramelson
`David L. Roach
`Jim Soriano
`Larry Stein
`Robert G. Stewart
`Michael D. Teener
`Michael G. Thompson
`Michael Timperman
`Joseph P. Trainor
`Robert Tripi
`David Voth
`Fritz Whittington
`Thomas Wicklund
`Hans A. Wiggers
`Mark Williams
`Anthony Winter
`David L. Wright
`F. D. Wright
`Oren Yuen
`Janusz Zalewski
`
`...
`111
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`5
`
`

`

`The final conditions for approval of this standard were met o n March 30, 1994. This standard was condition-
`ally approved by the IEEE Standards Board on March 17, 1994, with the following membership:
`
`Wallace S. Read, Chair
`
`Donald C . Loughry, Vice Chair
`Andrew G. Salem, Secretary
`
`Gilles A. Baril
`Bruce B. Barrow
`JosC A. Berrios de la Paz
`Clyde R. Camp
`James Costantino
`Stephen L. Diamond
`Donald C. Fleckenstein
`Jay Forster*
`Ramiro Garcia
`
`*Member Emeritus
`
`Donald N. Heirman
`Richard J. Holleman
`Jim Isaak
`Ben C. Johnson
`Sonny Kasturi
`Lorraine C. Kevra
`E. G. “Al” Kiener
`Ivor N. Knight
`
`Joseph L. Koepfinger*
`D. N. “Jim” Logothetis
`L. Bruce McClung
`Marco W. Migliaro
`Mary Lou Padgett
`Arthur K. Reilly
`Ronald H. Reimer
`Gary S . Robinson
`Leonard L. Tripp
`
`Also included are the following nonvoting IEEE Standards Board liaisons:
`
`Satish K. Aggarwal
`James Beall
`Richard B. Engelman
`David E. Soffrin
`Stanley I. Warshaw
`
`Mary Lynne Nielsen
`IEEE Standards Project Editor
`
`Windows is a trademark of Microsoft Corporation.
`Centronics is a registered trademark of Genicom Corporation.
`PS/2 is a registered trademark of International Business Machines, Inc
`Intel386 is a trademark of Intel Corporation.
`
`iv
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`6
`
`

`

`..
`
`Contents
`
`CLAUSE
`
`PAGE
`
`1 .
`
`Overview ..............................................................................................................................................
`
`1.1 Scope ............................................................................................................................................
`1.2 Purpose .........................................................................................................................................
`
`2 .
`
`3 .
`
`References ............................................................................................................................................
`
`Definitions ............................................................................................................................................
`
`1
`
`1
`1
`
`1
`
`2
`
`3.1 General terminology ....................................................................................................................
`2
`3.2 Communication modes ................................................................................................................ 4
`3.3 Operating phases .......................................................................................................................... 4
`
`4 .
`
`Features and compliance ......................................................................................................................
`
`7
`
`4.1 Interface overview ....................................................................................................................... 7
`4.2 Features ........................................................................................................................................ 7
`4.3 Device compatibility criteria ........................................................................................................
`7
`4.4 Device compliance criteria ..........................................................................................................
`8
`4.5 Cable compliance criteria ............................................................................................................
`9
`
`5 .
`
`Interface signals .................................................................................................................................
`
`10
`
`HostClWnWrite (nstrobe): host driven ......................................................................................
`10
`5.1
`AD1 ... AD8 (Datal ... Data8): ......................................................................................................
`10
`5.2
`F'trClk/PeriphClk/Intr (nAck): peripheral driven .......................................................................
`10
`5.3
`5.4 PtrBusy/PeriphAcWnWait (busy): peripheral driven ................................................................. 11
`AckDataReqhAckReverse (PError): peripheral driven ............................................................
`11
`5.5
`5.6 Xflag (Select): peripheral driven ...............................................................................................
`11
`HostBusy/HostAcWnDStrb (nAutoFd): host driven ..................................................................
`12
`5.7
`5.8 Peripheral Logic High: peripheral driven ..................................................................................
`12
`nReverseRequest (dnit): host driven .........................................................................................
`12
`5.9
`5.10 nDataAvaiYnPeriphRequest (nFault): peripheral dnven ...........................................................
`13
`5.1 1 1284 ActivehAStrb (nSelectIn): host driven ............................................................................
`13
`5.12 Host Logic High: host driven .....................................................................................................
`13
`
`6 .
`
`Interface concepts .............................................................................................................................. 14
`
`Link level and data level separation ...........................................................................................
`14
`6.1
`IEEE 1284 communication options ...........................................................................................
`14
`6.2
`Nibble ModeByte Mode transfer ..............................................................................................
`15
`6.3
`6.4 Host-initiated transfers ............................................................................................................... 15
`6.5 Peripheral-initiated transfers ......................................................................................................
`15
`6.6 Multiple byte transfers ...............................................................................................................
`15
`6.7 Interface errors ...........................................................................................................................
`15
`6.8 Peripheral error resolution ......................................................................................................... 16
`6.9 ECP Mode command/data .........................................................................................................
`16
`6.10 EPP Mode addressing ................................................................................................................
`17
`6.1 1 Device identification .................................................................................................................. 17
`
`h
`
`h
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`V
`
`7
`
`

`

`CLAUSE
`
`PAGE
`
`7.
`
`Interface operation .............................................................................................................................
`
`19
`
`....................................
`
`19
`
`.........................
`.................................................
`7.1 Power-On
`........................................................
`7.2 Initialization ..
`....................
`7.3 Compatibility
`7.4 Negotiation .......................................................................
`7.5 Peripheral-to-host transfer modes .........
`.........................
`7.6 Device ID .............................................................................................
`52
`7.7 Termination .......................................................
`......................................................... 53
`.........................
`....................
`7.8 Collisions
`53
`
`.................
`
`............... 22
`
`~
`
`8.
`
`Mechanical and electrical interface ...................................................................................................
`
`56
`
`8.1 General considerations ...............................................................................................................
`56
`8.2 Mechanical characteristics ......................................................................................................... 56
`8.3 Electrical characteristics ............................................................................................................
`69
`
`9.
`
`Software support ................................................................................................................................
`
`9.1 General considerations ...........................
`..........................................................
`.......................
`9.2 Application level compatibility ...................................................
`9.3 MS-DOS IEEE 1284 driver ..........................
`.............................................................
`...........................................................
`......................
`9.4 Windows 1284 driver
`9.5 Reverse channel data ........................................
`..............................................
`9.6 Link performance .......
`........................
`.............................................................
`
`75
`
`75
`75
`75
`75
`
`76
`
`ANNEX
`
`Annex A Timing specifications (normative) ............................................................................................... 77
`
`Annex B Signal transition events (normative) ............................................................................................ 79
`
`Annex C Centronics and PC-compatible parallel interfaces (informative). ................................................
`
`83
`
`C.l Purpose and scope .............................................................................................................. 83
`C.2 Centronics interface background information ...................................................................
`83
`C.3 Classic Centronics Standard Parallel Interface ..................................................................
`84
`C.4 PC Parallel and PC-Compatible Printer Interfaces ............................................................
`88
`C.5 Enhanced and bidirectional parallel printer interface ........................................................
`93
`C.6 Printer interface variations .................................................................................................
`96
`
`Annex D Bibliography (informative) ........................................................................................................ 100
`
`vi
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`8
`
`

`

`IEEE Standard Signaling Method for a
`Bidirectional Parallel Peripheral
`Interface for Personal Computers
`
`1. Overview
`
`1.1 Scope
`
`,-
`
`This standard defines a signaling method for asynchronous, fully interlocked, bidirectional parallel commu-
`nications between hosts and printers or other peripherals. A functional subset of the signaling method may
`be implemented on personal computers (PCs) or equivalent parallel port hardware with new software. This
`standard recommends new electrical interfaces, cabling, and interface hardware that provides improved per-
`formance while retaining backward compatibility with this subset.
`
`This standard also specifies a format for a peripheral identification string and a method of returning this
`string to the host outside of the bidirectional data stream.
`
`1.2 Purpose
`
`This standard was created because there existed no defined standard for bidirectional parallel communica-
`tions between personal computers and printing peripherals. Re-existing methods utilized a wide variety of
`hardware and software products, each with unique and incompatible signaling schemes. This standard was
`developed to provide an open path for communications between computers and more intelligent printers and
`peripherals. The availability of a standard bidirectional protocol will encourage the development of new
`peripherals that return significant data, as well as basic status, to the host.
`
`2. References
`
`This standard shall be used in conjunction with the following publications. If the following publications are
`superseded by an approved revision, the revision shall apply.
`
`IEC 950 : 1991, Safety of information technology equipment, including electrical business equipment.'
`
`h
`
`'IEC publications are available from IEC Sales Department, Case Postale 131, 3 rue de VaremM, CH-1211, Genkve 20, Switzerland
`Suisse. IEC publications are also available in the United States from the Sales Department, American National Standards Institute, 11
`West 42nd Street, 13th Floor, New York, NY 10036, USA.
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`1
`
`9
`
`

`

`IEEE
`Std 1284-1994
`
`3. Definitions
`
`3.1 General terminology
`
`IEEE STANDARD SIGNALING METHOD FOR A BIDIRECTIONAL
`
`The following terms are used in this standard and/or may be used in conjunction with the signaling methods
`defined in this standard. The definitions are not intended to be absolute, but they do reflect the use of the
`terms in this standard.
`
`3.1.1 bidirectional operation: When the peripheral and host communicate using both forward and reverse
`data channels. As defined in this standard, Nibble and Byte Modes provide reverse channel communication
`and are used in conjunction with Compatibility Mode to provide bidirectional operation. Extended Capabili-
`ties Port (ECP) and Enhanced Parallel Port (EPP) Modes support bidirectional communication.
`
`3.1.2 Centronics: The popular name for the parallel printer port used as the parallel interface for most print-
`ers and supported by most “MS-DOS compatible” PCs. The name is derived from the printer manufacturer
`that introduced this interface, Centronics Data Computer Corporation. This interface has never been formal-
`ized. Despite a basic similarity, many variations of this interface have been implemented in different periph-
`erals and hosts. This specification describes the more prevalent variations of the “Centronics” interface and
`defines a family of signaling methods that are backward compatible with the typical “Centronics” interface.
`
`3.1.3 Centronics connector: The popular name for the 36-pin ribbon contact type connector commonly
`used for the parallel port on printers. This connector is referred to as the “IEEE 1284-B’ connector in this
`standard.
`
`3.1.4 command set: A field in the Device ID message identifying the type of data expected by the periph-
`eral. For example, a printer might use this field to report which page description language(s) it supports.
`
`3.1.5 compatible device: A device that supports any of a specified range of popular variants of the “Cen-
`tronics” interface. Compatible devices will interoperate with compliant devices in Compatibility Mode only.
`
`r
`
`3.1.6 compliant device: A device that supports either the Level 1 or Level 2 electrical interface, plus Com-
`patible and Nibble Mode operation, as well as the negotiation phases necessary to transition between these
`two modes.
`
`3.1.7 device driver: A program that runs on the host and manages the sending and receiving of information
`from the peripheral. The driver utilizes the link level interface defined in this standard to communicate data
`between the application program and the peripheral personality.
`
`3.1.8 Device ID: A structured, variable length ASCII message identifying the manufacturer, command set,
`and model of the peripheral. The message is provided by the peripheral in response to a request issued by the
`host during the negotiation phase. Provided that the peripheral supports the bidirectional mode requested by
`the host, this message is provided in the requested mode. The Device ID is intended to assist the host in
`selecting the device and/or peripheral driver appropriate to the peripheral.
`
`3.1.9 forward channel: Data path from the host to the peripheral.
`
`3.1.10 host: A device, typically a personal computer, that will control the communications with attached
`peripherals.
`
`3.1.11 IEEE 1284-compatible device: See compatible device.
`
`3.1.12 IEEE 1284-compliant device: See compliant device.
`
`2
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`10
`
`

`

`PARALLEL PERIPHERAL INTERFACE FOR PERSONAL COMPUTERS
`
`IEEE
`Std 1284-1 994
`
`-
`
`3.1.13 IEEE 1284-A connector: A plug or receptacle 25-pin subminiature D-shell connector, as specified in
`8.2 and shown in figure 24. This is the type of connector used on the MS-DOS compatible PC printer port
`adapter.
`
`3.1.14 IEEE 1284-B connector: A plug or receptacle 36-pin ribbon type connector, as specified in 8.2 and
`shown in figure 25. This type of connector is also known as a “Centronics Connector.”
`
`3.1.15 IEEE 1284-C connector: A miniature plug or receptacle 36-pin ribbon type connector, as specified
`in 8.2 and shown in figure 26.
`
`3.1.16 Level 1 device: A device that supports the Level 1 electrical interface.
`
`3.1.17 Level 2 device: A device that supports the Level 2 electrical interface.
`
`3.1.18 link: The physical connection and electronic hardware by which data is transferred between the host
`and the peripheral. This standard is concerned only with the link layer; the only information transfer defined
`or required as part of this standard is that necessary to control and synchronize the communication of periph-
`eral data. The defined interface is transparent to the peripheral data communicated at data or higher layers.
`
`3.1.19 n: When preceding a capitalized signal name, denotes a signal having negative true logic.
`
`3.1.20 PC parallel port: The parallel printer port used as the parallel interface for most printers and sup-
`ported by most PCs. This interface has been variously defined by different PC and peripheral manufacturers.
`This standard describes the more prevalent variations of the interface and defines a family of signaling meth-
`ods that are backward compatible with the typical PC parallel port.
`
`h
`
`3.1.21 peripheral: A device, attached to a host via a communication link.
`
`3.1.22 peripheral personality: The characteristics of a language processor or operating environment that a
`peripheral runs to interpret commands and data being sent.
`
`3.1.23 reverse channel: Data path from the peripheral to the host.
`
`3.1.24 solicited status: Information generated by the peripheral in response to a command from the host.
`
`3.1.25 status: A term used generally to describe data generated by the peripheral that reflects the current
`operating state of the peripheral.
`
`3.1.26 status lines: Unidirectional signals from the peripheral to the host, defined in Compatibility Mode to
`handshake data and to report error conditions. In other IEEE 1284 interface modes defined in this standard,
`these lines are used for control, data, and/or status.
`
`3.1.27 unidirectional operation: When the peripheral and host communicate data in one direction only.
`Compatibility Mode is unidirectional in the forward direction; Byte and Nibble Modes are unidirectional in
`the reverse direction.
`
`3.1.28 unsolicited status: Information generated by the peripheral that has not been asked for by the host,
`yet is important enough that the peripheral desires to send it to the host.
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`3
`
`11
`
`

`

`IEEE
`Std 1284-1 994
`
`3.2 Communication modes
`
`IEEE STANDARD SIGNALING METHOD FOR A BIDIRECTIONAL
`
`signaling method described herein provides for several modes of host-peripheral communication. The
`NOTE-The
`interface is initially in Compatibility Mode. Other modes provide additional features andor improved performance.
`Compliant devices can determine and switch to the most effective mode supported by both devices. All compliant
`devices are required to support Compatibility Mode, Nibble Mode, and the negotiation necessary to switch between
`communication modes.
`
`3.2.1 Compatibility Mode: An asynchronous, byte-wide forward (host-to-peripheral) channel with data and
`status lines used according to their original definitions. Compatibility Mode is backward compatible with
`many existing devices, including the PC parallel port, and is the base mode common to all compliant
`interfaces.
`
`3.2.2 Nibble Mode: An asynchronous, reverse (peripheral-to-host) channel, under control of the host. Data
`bytes are transmitted as two sequential, 4-b nibbles using four peripheral-to-host status lines. Nibble Mode is
`used with Compatibility Mode to implement a bidirectional channel. These two modes cannot be active
`simultaneously.
`
`3.2.3 Byte Mode: An asynchronous, byte-wide reverse (peripheral-to-host) channel using the eight data
`lines of the interface for data and the control/status lines for handshaking. Byte Mode is used with Compati-
`bility Mode to implement a bidirectional channel, with transfer direction controlled by the host when the
`host and peripheral both support bidirectional use of the data lines. The two modes cannot be active
`simultaneously.
`
`3.2.4 Extended Capabilities Port (ECP) Mode: An asynchronous, byte-wide, bidirectional channel. An
`ihterlocked handshake replaces the minimum timing requirements of Compatibility Mode. A control line is
`provided to distinguish between command and data transfers. A command may optionally be used to indi-
`cate single-byte data compression or channel address.
`
`3.2.5 Enhanced Parallel Port (EPP) Mode: An asynchronous, byte-wide, bidirectional channel controlled
`by the host device. This mode provides separate address and data cycles over the eight data lines of the
`interface.
`
`3.3 Operating phases
`
`NOTGInterface operation is divided into a number of interface phases. Each communication mode consists of one or
`more phases. Additional phases are defined to cover initialization and transitions between communication modes. The
`names and interpretations of the interface signals may vary between phases, but are consistent within each phase.
`
`3.3.1 Compatibility Mode phases
`
`3.3.1.1 Compatibility Mode forward data transfer phase: Begins when the host asserts nStrobe and ends
`following data hold time and nStrobe de-assertion. (Note that the host is not free to send the next data byte
`until the peripheral acknowledges the transfer using nAck.) The host may not initiate negotiation to a new
`operating mode until the interface returns to Compatibility Mode forward idle phase.
`
`3.3.1.2 Compatibility Mode forward idle phase: When the interface is in Compatibility Mode with no
`data transfer in progress. The host may initiate a data transfer in Compatibility Mode or may initiate negoti-
`ation to a new operating mode.
`
`3.3.2 Nibble and Byte Mode phases
`
`3.3.2.1 reverse data transfer phase: When data transfers from the peripheral to the host.
`
`4
`
`Authorized licensed use limited to: UNIVERSITY OF VICTORIA. Downloaded on July 29,2010 at 20:21:17 UTC from IEEE Xplore. Restrictions apply.
`
`12
`
`

`

`PARALLEL PERIPHERAL INTERFACE FOR PERSONAL COMPUTERS
`
`IEEE
`Std 1284-1 994
`
`3.3.2.2 reverse host busy data available phase: When the peripheral has data to transmit.
`
`3.3.2.3 reverse host busy data not available phase: When the peripheral has no more data to transmit.
`
`3.3.2.4 reverse idle phase: When no data transfer is in progress and the host is waiting for peripheral data.
`When data are available, the peripheral will cause the interface to go to the reverse interrupt phase.
`
`3.3.2.5 reverse interrupt phase: A phase that provides the mechanism for the peripheral to alert the host
`that it has data to transfer. While in this phase, the host may cause the interface to go to the termination
`phase.
`
`3.3.3 ECP Mode phases
`
`3.3.3.1 ECP setup phase: A phase that sets the interface signals to the correct state for the ECP forward
`transfer phase. It immediately follows the negotiation phase.
`
`3.3.3.2 ECP forward transfer phase: When the