IEEE 1284 Parallel Interface Specifications
1. Compatibility Mode
This mode defines the protocol used by most PCs to transfer data to a printer. It is commonly called the "Centronics" mode and is the method utilized with the standard parallel port. In this mode, data is placed on the port's data lines, the printer status is checked for no errors and that it is not Busy, and then a data Strobe is generated by the software to clock the data to the printer. Figure 1 describes this transfer.
Figure 1 -- Compatibility Mode Data Transfer Cycle
Compatibility Mode phase transitions:
- Write the data to the data register
- Program reads the status register to check that the printer is not BUSY
- If not BUSY, then Write to the Control Register to assert the STROBE line
- Write to the Control register to de-assert the STROBE line
As can be seen, in order to output one byte of data it requires four I/O instructions and at least as many additional instructions. The net effect of this is a limitation on the bandwidth capabilities of the port on the order of 150K bytes per second. This bandwidth is sufficient for communicating with dot matrix and many older laser printers, but a limitation when communicating with pocket LAN adapters, removable disk drives, and the newest generation of laser printers, to name a few. Of course, this mode is for the forward channel only and must be combined with a reverse channel mode in order to have a complete bi-directional channel. This mode was included as a way to provide backward compatibility with the huge base of installed printers and peripherals. The other modes are used to provide the reverse channel and high performance communication links. Many of the integrated 1284 I/O controllers have implemented a mode that uses a FIFO buffer to transfer data with the Compatibility mode protocol. This mode is referred to as "Fast Centronics" or "Parallel Port FIFO Mode". When this mode is enabled, data written to the FIFO port will be transferred to the printer using hardware generated strobes for the handshaking. Since there is very little latency between transfers, and the software does not have to do any of the strobing or handshake checking, data rates over 500K bytes per second are achievable with some systems. This mode, however, is not an IEEE 1284 defined mode and is not described in the standard.
2. Nibble Mode
The Nibble mode is the most common way to get reverse channel data from a printer or peripheral. This mode is usually combined with the Compatibility mode or a proprietary forward channel mode to create a complete bi-directional channel.
All of the standard parallel ports provide 5 lines from the peripheral to the PC to be used for external status indications. Using these lines, a peripheral can send a byte of data (8-bits) by sending 2 nibbles (4-bits) of information to the PC in two data transfer cycles. Unfortunately, since the nACK line is generally used to provide a peripheral interrupt, the bits used to transfer a nibble are not conveniently packed into the byte defined by the Status register. For this reason, the software must read the status byte and then manipulate the bits in order to get a correct byte.
Table 1 identifies the signal names for the Nibble mode. Figure 2 shows the basic data handshake for a nibble mode transfer from the peripheral to the host.
Table 1 -- Nibble Mode Signals
| SPP Signal | Nibble Mode Name | In/Out | Description -- Signal usage when in Nibble Mode data transfer |
| NSTROBE | nSTROBE | Out | Not used for reverse data transfer |
| NAUTOFEED | HostBusy | Out | Host nibble mode handshake signal. Set low to indicate host is ready for nibble. Set high to indicate nibble has been received. |
| NSELECTIN | 1284Active | Out | Set high when host is in a 1284 transfer mode. |
| NINIT | nINIT | Out | Not used for reverse data transfer |
| NACK | PtrClk | In | Set low to indicate valid nibble data, set high in response to HostBusy going high. |
| BUSY | PtrBusy | In | Used for Data bit 3, then 7 |
| PE | AckDataReq | In | Used for Data bit 2, then 6 |
| SELECT | Xflag | In | Used for Data bit 1, then 5 |
| NERROR | nDataAvail | In | Used for Data bit 0, then 4 |
| DATA[8:1] | Not Used | | |
Figure 2 -- Nibble Mode Data Transfer Cycle 1284 Nibble Mode phase transition:
- Host signals ability to take data by asserting HostBusy low
- Peripheral responds by placing first nibble on status lines
- Peripheral signals valid nibble by asserting PtrClk low
- Host sets HostBusy high to indicate that it has received the nibble and is not yet ready for another nibble.
- Peripheral sets PtrClk high to acknowledge host
- States 1 through 5 repeat for the second nibble
Nibble mode, like the Compatible mode, requires that the software drive the protocol by setting and reading the lines on the parallel port. Nibble mode is the most software intensive mode for reverse channel data communication. For this reason, there is a severe limitation of approximately 50K bytes per second for this type of data transfer. The major advantage of this combination of modes is the ability to operate on all PCs that have a parallel port. The performance limitations incurred by the Nibble mode operation does not have much visible effect on peripherals that have low reverse channel requirements, such as printers, but can be nearly intolerable when used for LAN adapters, disk drives or CD ROM drives.
3. Byte Mode
With later implementations of the parallel port interface, some manufacturers, led by IBM on the PS/2 parallel port, added the capability to disable the drivers used for driving the data lines, and allowed the data port to become an input read data port. This enables a peripheral to send an entire byte of data to the PC in one data transfer cycle by using the 8 data lines, rather than the two cycles required using the Nibble mode.
This ability enables a Byte mode for reverse channel data transfer that can be used to provide data rates into the PC approaching that of the Compatibility mode, from the PC. This type of port is sometimes referred to as a "enhanced bi-directional" port, and has caused some confusion when mistaken for an Enhanced Parallel Port (EPP).
The following table identifies the Byte mode signal names, and figure 3 shows the handshake for a Byte mode data transfer.
Table 2 -- Byte Mode Signals
| SPP Signal | Byte Mode Name | In/Out | Description Signal usage when in Byte Mode data transfer |
| NSTROBE | HostClk | Out | Pulsed low at the end of each Byte mode data transfer to indicate that the byte was received. Acknowledge signal. |
| NAUTOFEED | HostBusy | Out | Set low to indicate host is ready for byte. Set high to indicate byte has been received. Handshake signal. |
| NSELECTIN | 1284Active | Out | Set high when host is in a 1284 transfer mode. |
| NINIT | nINIT | Out | Not used. Set high. |
| NACK | PtrClk | In | Set low to indicate valid data on the data lines, set high in response to HostBusy going high. |
| BUSY | PtrBusy | In | Forward channel Busy status. |
| PE | AckDataReq | In | Follows nDataAvail |
| SELECT | Xflag | In | Extensibility flag. Not used in Byte mode. |
| NERROR | nDataAvail | In | Set low by peripheral to indicate that reverse data is available. |
| DATA[8:] | DATA[8:1] | Bi-Di | Used to provide data from peripheral to host. |
Figure 3 -- Byte Mode Data Transfer Cycle
Byte Mode signal transitions:
1. Host signals ability to take data by asserting HostBusy low
2. Peripheral responds by placing first byte on data lines
3. Peripheral signals valid byte by asserting PtrClk low
4. Host sets HostBusy high to indicate that it has received the and is not yet ready for another byte
5. Peripheral sets PtrClk high to acknowledge host. Host pulses HostClk as an acknowledgement to the peripheral
6. States 1 through 5 repeat for additional bytes
4. EPP Mode
The Enhanced Parallel Port protocol was originally developed by Intel, Xircom and Zenith Data Systems, as a means to provide a high performance parallel port link that would still be compatible with the standard parallel port. This protocol capability was implemented by Intel in the 386SL chipset (82360 I/O chip). This was prior to the establishment of the IEEE 1284 committee and the associated standards work.
The EPP protocol offered many advantages to parallel port peripheral manufactures and was quickly adopted by many as an optional data transfer method. A loose association of around 80 interested manufacturers was formed to develop and promote the EPP protocol. This association became the EPP Committee and was instrumental in helping to get this protocol adopted as one of the IEEE 1284 advanced modes.
Since EPP capable parallel ports were available prior to the release of the 1284 standard, there is a small deviation between the pre-1284 EPP ports and 1284 EPP protocol. This will be made clearer later.
The EPP protocol provides four types of data transfer cycles:
- Data Write Cycle
- Data Read Cycle
- Address Write Cycle
- Address Read Cycle
Data cycles are intended to be used to transfer data between the host and the peripheral. Address cycles may be used to pass address, channel, or command and control information. These cycles can be viewed as just two different data cycles. The developer may use and parse the address/data information in any method that makes sense for a particular design. Table 3 describes the EPP signals and their associated SPP signals.
Table 3 -- EPP Signal Definitions
| SPP Signal | EPP Signal Name | EPP Signal Description | | |
| NSTROBE | nWRITE | Out | Active low. Indicates a write operation High for a read cycle. | |
| NAUTOFEED | nDATASTB | Out | Active low. Indicates a Data_Read or Data_Write operation is in process. | |
| NSELECTIN | nADDRSTB | Out | Active low. Indicates an Address_Read or Address_Write operation is in process. | |
| NINIT | nRESET | Out | Active low. Peripheral reset. | |
| NACK | nINTR | In | Peripheral interrupt. Used to generate an interrupt to the host. | |
| BUSY | nWAIT | In | Handshake signal. When low it indicates that is OK to start a cycle (assert a strobe), when high it indicates that it is OK to end the cycle (de-assert a strobe). | |
| D[8:1] | AD[8:1] | Bi-Di | Bi-directional address/data lines. | |
| PE | user defined | In | Can be used differently by each peripheral | |
| SELECT | user defined | In | Can be used differently by each peripheral. | |
| NERROR | user defined | In | Can be used differently by each peripheral. | |
Figure 4 is an example of a Data_Write cycle . The CPU signal nIOW is shown just to emphasize that this entire handshake occurs within a single I/O cycle.
Figure 4 -- EPP Data_Write Cycle
Data Write cycle phase transitions:
- Program executes an I/O write cycle to port 4 (EPP Data Port)
- The nWrite line is asserted and the data is output to the parallel port
- The data strobe is asserted, since nWAIT is asserted low
- The port waits for the acknowledge from the peripheral (nWAIT deasserted)
- The data strobe is deasserted and the EPP cycle ends
- The ISA I/O cycle ends
- nWAIT is asserted low to indicate that the next cycle may begin
One of the most important features to note here is that the entire data transfer occurs within one ISA I/O cycle. The effect is that by using the EPP protocol for data transfer, a system can achieve transfer rates from 500K to 2M bytes per second. In this fashion, parallel port peripherals can operate at close to the same performance levels as an equivalent ISA plug-in card. The ability to get this level of performance from a parallel port attached device is one of the major features of the EPP protocol. With interlocked handshakes, the data transfer will happen at the speed of the slowest of the interfaces, the host adapter or the peripheral device. This "speed adaptive" property is transparent to both the host and peripheral. All 1284 transfer modes are implemented with interlocking handshakes.
Interlocking refers to the criteria that each control signal transition is acknowledged by the opposite side of the interface. In the above diagram, nDataStrobe can be asserted because nWAIT is low, nWAIT deasserts in response to nDataStrobe be asserted, nDataStrobe deasserts in response to nWAIT being deasserted, and finally nWAIT asserts in response to nDataStrobe being deasserted. In this way the peripheral can control the setup time required for its operation. This is done in the following manner: the setup time is the time from the assertion of nDataStrobe to the deassertion of nWAIT, the peripherals controls this time. Interlocking also has the advantage of making the transfer cycle independent of the cable length. The Nibble, Byte, EPP and ECP modes all have interlocked protocols.
As previously mentioned, the pre-1284 EPP devices deviated from the 1284 protocol. At the start of the cycle, the nDataStrobe or nAddrStrobe would assert regardless of the state of the nWAIT signal. This means that the peripheral could not hold off the start of a cycle by having nWAIT deasserted. This is sometimes referred to as EPP 1.7, in reference to a Xircom proposal version 1.7. This is the version that Intel implemented in the original 82360 I/O controller. A 1284 EPP compatible peripheral will work properly with an EPP 1.7 version host adapter, but an EPP 1.7 peripheral may not operate properly with a 1284 compliant host. Figure 5 is an example of an Address_Read cycle.
Figure 5 -- EPP Address_Read Cycle
EPP Register Interface
The simplest software view of EPP is that of an extension to the register definitions for the standard parallel port. As shown earlier, the SPP consists of three registers, offset from the port's base address: Data port, Status port, and Control port. The most common EPP implementations expand this to use ports not defined by the SPP. See table 4.
Table 4 EPP Register Definitions
| Port Name | Offset | Mode | Read/Write | Description |
| SPP Data Port | +0 | SPP/EPP | W | Standard SPP data port. No autostrobing. |
| SPP Status Port | +1 | SPP/EPP | R | Reads the input status lines on the interface. |
| SPP Control Port | +2 | SPP/EPP | W | Sets the state of the output control lines. |
| EPP Address Port | +3 | EPP | R/W | Generates an interlocked address read or write cycle. |
| EPP Data Port | +4 | EPP | R/W | Generates an interlocked data read or write cycle. |
| Not Defined | +5 to +7 | EPP | N/A | Used differently by various implementations. May be used for 16 and 32 bit I/O. |
By generating a single I/O write instruction to "base_address + 4", the EPP controller will generate the necessary handshake signals and strobes to transfer the data using an EPP Data_Write cycle. I/O instructions to the base addresses, ports 0 through 2, will cause behavior exactly as that as to a standard parallel port. This guarantees compatibility with standard parallel port peripherals and printers. Address cycles are generated when read or write I/O operations are generated to "base_address + 3".
Ports 5 through 7 are used differently by various hardware implementations. These may be used to implement 16 or 32-bit software interfaces, or used for configuration registers, or not used at all. For example, the Warp Nine Engineering's' F/PortPlus card has only an 8-bit data interface, but can be accessed using 32-bit I/O, for EPP data operations. The ISA controller will intercept the 32- bit I/O and actually generate 4 fast 8- bit I/O cycles. The first cycle will be to the addressed I/O port using byte 0 (bits 0-7), the second cycle will be to port+1 using byte 1, then port+2 using byte 2 and finally port+3 using byte 3. These additional cycles are generated by hardware and are transparent to the software. The total time for these four cycles will be less than 4 independent 8 bit cycles. For example, the F/PortPlus card (from Warp Nine Engineering) maps 4 I/O ports (offset 4 to 7) to the internal EPP Data register. This enables the software to use 32-bit I/O operations for EPP data transfer. Address cycles are still limited to 8-bit I/O.
The ability to transfer data to or from the PC by the use of a single instruction is what enables EPP mode parallel ports to transfer data at ISA bus speeds. Rather than having the software implement an I/O intensive software loop, a
block of data can be transferred with a single REP_IO instruction. Depending upon the host adapter port implementation and the capability of the peripheral, an EPP port can transfer data from 500K bytes to nearly 2M bytes per second. This data transfer rate is more than enough to enable network adapters, CD ROM, tape backup and other peripherals to operate at nearly ISA bus performance levels.
The EPP protocol and current implementations provide a high degree of coupling between the peripheral driver and the peripheral. What this means is the software driver is always able to determine and control the state of communication to the peripheral at any given time. Intermixing of read and write operations as well as block transfers are readily done. This type of coupling is ideal for many register-oriented or real-time controlled peripherals such as network adapters, data acquisition, portable hard drives, and other devices.
5. ECP Mode
The Extended Capability Port, or ECP, protocol was proposed by Hewlett Packard and Microsoft as an advanced mode for communication with printer and scanner type peripherals. Like the EPP protocol, ECP provides for a high performance bi-directional communication path between the host adapter and the peripheral.
The ECP protocol provides the following cycle types in both the forward and reverse directions:
- Data cycles
- Command cycles
The command cycles are divided into 2 types, Run-Length Count and Channel address.
Unlike EPP, when the ECP protocol was proposed, a standard register implementation was also proposed. This can be found in the Microsoft document "The IEEE 1284 Extended Capabilities Port Protocol and ISA Interface Standard" available from Microsoft Corp. This document defines features that are implementation specific which the IEEE 1284 standard could not address. These features include Run_Length_Encoding (RLE) data compression for the host adapters, FIFOs for both the forward and reverse channels, and DMA as well as programmed I/O for the host register interface.
The RLE feature enables real time data compression that can achieve compression ratios up to 64:1. This is particularly useful for printers and scanners that are transferring large raster images that have large strings of identical data. In order for the RLE mode to be enabled both the host and the peripheral must support it.
Channel addressing is, conceptually, a little different than the EPP addressing. Channel addressing is intended to be used to address multiple logical devices within a single physical device. Think of this in terms of a new multi-function device such as FAX/Printer/Modem. Within one physical package, having a single parallel port attached, there is a printer, fax and modem. Each of these separate functions can be thought of as separate logical devices within the same package. Using the ECP channel addressing to access each of these devices, you could receive data from the modem data device while the printer data channel is busy processing a print image. With the compatibility mode protocol, if the printer gets busy then no more communication can occur until the printer data channel if free. With ECP, the software driver simply addresses another channel and communication can continue.
As with the other 1284 modes, the ECP protocol redefines the SPP signals to be more consistent with the ECP handshake. Table 5 describes these signals.
Table 5 -- ECP Mode Signals
| SPP Signal | ECP Mode Name | In/Out | Description – Signal usage when in ECP Mode data transfer |
| NSTROBE | HostClk | Out | Used with PeriphAck to transfer data or address information in the forward direction. |
| NAUTOFEED | HostAck | Out | Provides Command/Data status in the forward direction. Used with PeriphClk to transfer data in the reverse direction. |
| NSELECTIN | 1284Active | Out | Set high when host is in a 1284 transfer mode. |
| NINIT | nReverseRequest | Out | Driven low to put the channel in reverse direction. |
| NACK | PeriphClk | In | Used with HostAck to transfer data in the reverse direction. |
| BUSY | PeriphAck | In | Used with HostClk to transfer data or address information in the forward direction. Provides Command/Data status in the reverse direction. |
| PE | nAckReverse | In | Driven low to acknowledge nReverseRequest. |
| SELECT | Xflag | In | Extensibility flag. |
| NERROR | nPeriphRequest | In | Set low by peripheral to indicate that reverse data is available. |
| Data[8:1] | Data[8:1] | Bi-Di | Used to provide data between the peripheral and host. |
Figure 6 shows two forward data transfer cycles. When HostAck is high it indicates that a data cycle is taking place. When HostAck is asserted low, a command cycle is taking place and the data represents either an RLE count or a Channel address. Bit 8, of the data byte is used to indicate RLE vs. Channel address. If bit 8 is 0, then bits 1-7 represent a Run_Length Count (0-127). If bit 8 is 1, then bits 1-7 represent a Channel address (0-127). Figure 6 shows a data cycle followed by a command cycle.
Figure 7 shows a reverse channel command cycle followed by a reverse channel data cycle. The I/O read or write strobes are not shown in these figures. This is because the ECP FIFOs are used to decouple the ISA data transfers, either DMA or programmed I/O, from the actual host/peripheral data transfers. It is this decoupling of the transfer states that makes the ECP protocol a "loosely coupled" protocol. The software driver does not know the exact state of the data transfers. If a large block is being transferred via DMA, the driver does not know if the 123rd byte is being transferred or the 342,201st byte. As in the case of printers, the software may not care. The only concern is whether the transfer was completed or not.
Figure 6 -- ECP Forward Data and Command Cycle
Forward Transfer phase transistions:
- The host places data on the data lines and indicates a data cycle by setting HostAck high.
- Host asserts HostClk low to indicate valid data
- Peripheral acknowledges host by setting PeriphAck high
- Host sets HostClk high. This is the edge that should be used to clock the data in to the peripheral.
- Peripheral sets PeriphAck low to indicate that it is ready for the next byte.
- The cycle repeats, but this time it is a command cycle because HostAck is low.
NOTE: Since ECP transfers are loosely coupled, with a FIFO possibly on both sides of the interface, it is important to note at which step the data is considered "transferred". This point occurs at step 4, when the HostClk goes high. At this time, the data should be clocked in to the peripheral, and any data counters updated. There is a condition in the ECP protocol that could cause the transfer to abort at between steps 3 and 4. In this case the data should not be considered to have been transferred.
Figure 7 shows another of the differences between the ECP and EPP protocols. With EPP, the software driver may intermix read and write operations without any overhead or protocol handshaking. With the ECP protocol, changes in the data direction must be negotiated. The host must request a reverse channel transfer by asserting nReverseRequest and then wait for the peripheral to acknowledge the request by asserting nAckReverse. Only then can a reverse channel data transfer take place. In addition, since the previous transfer may have been DMA driven, the host software must either wait for the DMA to complete, or interrupt the DMA, backflush the FIFO to determine the exact transferred byte count, and then request the reverse channel. This adds a fair amount of overhead with peripherals that require a lot of intermixed reading and writing of registers or small buffers.
Figure 7 -- ECP Reverse Data and Command Cycle
Reverse Transfer phase transistions:
- The host requests a reverse channel transfer by setting nReverseRequest low.
- The peripheral signals that it is OK to proceed by setting nAckReverse low
- The peripheral places data on the data lines and indicates a data cycle by setting PeriphAck high.
- Peripheral asserts PeriphClk low to indicate valid data
- Host acknowledges by setting HostAck high
- Peripheral sets PeriphClk high. This is the edge that should be used to clock the data in to the host.
- Host sets HostAck low to indicate that it is ready for the next byte.
- The cycle repeats, but this time it is a command cycle because PeriphAck is low.
ECP Software and Register Interface
The Microsoft specification, "The IEEE 1284 Extended Capabilities Port Protocol and ISA Interface Standard", defines a common register interface for ISA based 1284 adapters with ECP. This specification also defines a number of operational modes that the adapter can operate under. Table 6 identifies these modes.
Table 6 -- ECR Register Modes
| Mode | Description |
| 000 | SPP mode |
| 001 | Bi-directional mode (Byte mode) |
| 010 | Fast Centronics |
| 011 | ECP Parallel Port mode |
| 100 | EPP Parallel Port mode (note 1) |
| 101 | (reserved) |
| 110 | Test mode |
| 111 | Configuration mode |
(note 1) This mode is implemented by the SMC FDC37C665/666 controller and is not defined by the ECP specification. Most 1284 I/O controllers implement the EPP mode in a similar fashion.
The register model for an ECP port is similar to that of the standard parallel port, but takes advantage of a significant design oddity of the ISA bus architecture. In the IBM compatible PC architecture, only the first 1024 I/O ports, or addresses, are used. This is the basic I/O space of 0x000h to 0x3ffh. In order to address this range of addresses, only 10 address bits are needed (AD0-9). In order to save cost, older PC's only drove and decoded these address bits on the ISA bus and therefore limited the available I/O space to these 1024 registers. Newer PC's, actually drive and decode more address bits, enabling a larger available I/O space. This creates, in effect, multiple "pages" of the first 1K I/O ports. A software driver can access these pages by adding 1024 (0x400h hex notation) to the base address being accessed. Therefore, addressing addresses 0x378h and 0x778h can access 2 registers on two separate pages, but be guaranteed not to interfere with any other installed ISA device. The advantage is that by using this "aliasing" effect, new cards can have "hidden" registers, thus expanding the available number of registers available, and still maintain compatibility with older ISA cards that only decode 10 address bits.
The ECP register model takes advantage of this and defines 6 registers that only require 3 actual I/O ports. Table 7 identifies these registers. Note that the register definition may be dependent upon the current mode of operation. The ECR register is the most important aspect of this register configuration. This is the register that is used to set the current operational mode. Additionally, this register can be used by software to determine if an ECP-capable port is installed in the PC. Detection software can try to access any ECR registers by adding 0x402h to the base address of the LPT ports identified in the BIOS LPT port table.
Table 7 -- ECP Register Description
| Offset | Name | Read/Write | ECP Mode | Function |
| 000 | Data | R/W | 000-001 | Data Register |
| 000 | ecpAfifo | R/W | 011 | ECP Address FIFO |
| 001 | dsr | R/W | all | Status Register |
| 002 | dcr | R/W | all | Control Register |
| 400 | cFifo | R/W | 010 | Parallel Port Data FIFO |
| 400 | ecpDfifo | R/W | 011 | ECP Data FIFO |
| 400 | tfifo | R/W | 110 | Test FIFO |
| 400 | cnfgA | R | 111 | Configuration Register A |
| 401 | cnfgB | R/W | 111 | Configuration Register B |
| 402 | ecr | R/W | all | Extended Control Register |
This paper will not attempt to describe all the functions of the ECP registers. For information regarding the register usage and bit definitions, please refer to the Microsoft document or the I/O controller data sheet.
It should be noted that if the port is in either standard parallel port mode or bi- directional mode, then the first 3 registers behave exactly as a standard parallel port. This way, compatibility with older devices and device drivers is maintained.
Usage of this port is similar to that of the EPP port. An operational mode is written to the ecr register, and then data transfer is accomplished by writing or reading from the appropriate I/O port. All of the handshaking is automatically generated by the interface controller. The major difference is that the ECP port is meant to be driven by DMA rather than explicit I/O operations. Again, this is a loosely coupled interface that is targeted primarily at peripherals that interchange large blocks of data.
