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:

1. Data Write Cycle
2. Data Read Cycle
3. Address Write Cycle
4. 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 1 describes the EPP signals and their associated SPP signals.

Table 1 -- EPP Signal Definitions

Figure 1 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 1 -- EPP Data_Write Cycle

Data Write cycle phase transitions:

1. Program executes an I/O write cycle to port 4 (EPP Data Port)
2. The nWrite line is asserted and the data is output to the parallel port
3. The data strobe is asserted, since nWAIT is asserted low
4. The port waits for the acknowledge from the peripheral (nWAIT deasserted)
5. The data strobe is deasserted and the EPP cycle ends
6. The ISA I/O cycle ends
7. 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 2 is an example of an Address_Read cycle.

Figure 2 -- 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 2.

Table 2 EPP Register Definitions

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.

| Home | Product | Ordering | 1284 Info | News | Contact Us | Support | Search |

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:

1. Data cycles
   
2. 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 1 describes these signals.

Table 1 -- ECP Mode Signals

Figure 1 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 2 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 1 -- ECP Forward Data and Command Cycle

Forward Transfer phase transistions:

1. The host places data on the data lines and indicates a data cycle by setting HostAck high.
2. Host asserts HostClk low to indicate valid data
3. Peripheral acknowledges host by setting PeriphAck high
4. Host sets HostClk high. This is the edge that should be used to clock the data in to the peripheral.
5. Peripheral sets PeriphAck low to indicate that it is ready for the next byte.
6. 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 2 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 2 -- ECP Reverse Data and Command Cycle

Reverse Transfer phase transistions:

1. The host requests a reverse channel transfer by setting nReverseRequest low.
2. The peripheral signals that it is OK to proceed by setting nAckReverse low
3. The peripheral places data on the data lines and indicates a data cycle by setting PeriphAck high.
4. Peripheral asserts PeriphClk low to indicate valid data
5. Host acknowledges by setting HostAck high
6. Peripheral sets PeriphClk high. This is the edge that should be used to clock the data in to the host.
7. Host sets HostAck low to indicate that it is ready for the next byte.
8. 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 2 identifies these modes.

Table 2 -- ECR Register Modes

(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 9 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 3 -- ECP Register Description

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.

| Home | Product | Ordering | 1284 Info | News | Contact Us | Support | Search |

Copyright © 1998-1999  Warp Nine Engineering

Last modified