IEEE 1284 Parallel Interface Specifications

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 trobe is !enerated by the software to clock the data to the printer. "i!ure # describes this transfer.

Figure 1
Compatibility Mode p#ase transitions$

Compatibility Mode !ata "ransfer Cycle

1. 2. 3. 4.

$rite the data to the data re!ister Pro!ram reads the status re!ister to check that the printer is not B% & If not B% &, then $rite to the Control 'e!ister to assert the T'(B) line $rite to the Control re!ister to de*assert the T'(B) line

+s can be seen, in order to output one byte of data it re,uires four I-( 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 #./0 bytes per second. This bandwidth is sufficient for communicatin! with dot matri1 and many older laser printers, but a limitation when communicatin! with pocket 2+3 adapters, remo4able disk dri4es, and the newest !eneration of laser printers, to name a few. (f course, this mode is for the forward channel only and must be combined with a re4erse channel mode in order to ha4e a complete bi*directional channel. This mode was included as a way to pro4ide backward compatibility with the hu!e base of installed printers and peripherals. The other modes are used to pro4ide the re4erse channel and hi!h performance communication links. 5any of the inte!rated #678 I-( controllers ha4e implemented a mode that uses a "I"( buffer to transfer data with the Compatibility mode protocol. This mode is referred to as ""ast Centronics" or "Parallel Port "I"( 5ode". $hen this mode is enabled, data written to the "I"( port will be transferred to the printer usin! hardware !enerated strobes for the handshakin!. ince there is 4ery little latency between transfers, and the software does not ha4e to do any of the strobin! or handshake checkin!, data rates o4er .//0 bytes per second are achie4able with some systems. This mode, howe4er, is not an I))) #678 defined mode and is not described in the standard.

2. %ibble Mode
The 3ibble mode is the most common way to !et re4erse 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. +ll of the standard parallel ports pro4ide . lines from the peripheral to the PC to be used for e1ternal status indications. %sin! these lines, a peripheral can send a byte of data 97*bits: by sendin! 6 nibbles 98*bits: of information to the PC in two data transfer cycles. %nfortunately, since the n+C0 line is !enerally used to pro4ide a peripheral interrupt, the bits used to transfer a nibble are not con4eniently packed into the byte defined by the tatus re!ister. "or this reason, the software must read the status byte and then manipulate the bits in order to !et a correct byte.

IEEE 1284 Parallel Interface Specifications

Table # identifies the si!nal names for the 3ibble mode. "i!ure 6 shows the basic data handshake for a nibble mode transfer from the peripheral to the host. "able 1 %ibble Mode Signals

SPP Signal
3 T'(B)

%ibble In&'ut Mode %ame

n T'(B) (ut (ut (ut (ut In In In In In

!escription

Signal usage (#en in %ibble Mode data transfer

3+%T(")); <ostBusy 3 )2)CTI3 #678+cti4e 3I3IT nI3IT 3+C0 B% & P) )2)CT 3)''(' ;+T+A7B#C PtrClk PtrBusy +ck;ata'e, @fla! n;ata+4ail 3ot %sed

3ot used for re4erse data transfer <ost nibble mode handshake si!nal. et low to indicate host is ready for nibble. et hi!h to indicate nibble has been recei4ed. et hi!h when host is in a #678 transfer mode. 3ot used for re4erse data transfer et low to indicate 4alid nibble data, set hi!h in response to <ostBusy !oin! hi!h. %sed for ;ata bit =, then > %sed for ;ata bit 6, then ? %sed for ;ata bit #, then . %sed for ;ata bit /, then 8

Figure 2

%ibble Mode !ata "ransfer Cycle #678 3ibble 5ode phase transitionB

1. 2. 3. 4. 5.
?.

<ost si!nals ability to take data by assertin! <ostBusy low Peripheral responds by placin! first nibble on status lines Peripheral si!nals 4alid nibble by assertin! PtrClk low <ost sets <ostBusy hi!h to indicate that it has recei4ed the nibble and is not yet ready for another nibble. Peripheral sets PtrClk hi!h to acknowled!e host tates # throu!h . repeat for the second nibble

3ibble mode, like the Compatible mode, re,uires that the software dri4e the protocol by settin! and readin! the lines on the parallel port. 3ibble mode is the most software intensi4e mode for re4erse channel data communication. "or this reason, there is a se4ere limitation of appro1imately ./0 bytes per second for this type of data transfer. The maDor ad4anta!e of this combination of modes is the ability to operate on all PCs that ha4e a parallel port. The performance limitations incurred by the 3ibble mode operation does not ha4e much 4isible effect on peripherals that ha4e low re4erse channel re,uirements, such as printers, but can be nearly intolerable when used for 2+3 adapters, disk dri4es or C; '(5 dri4es.

IEEE 1284 Parallel Interface Specifications ). *yte Mode

$ith later implementations of the parallel port interface, some manufacturers, led by IB5 on the P -6 parallel port, added the capability to disable the dri4ers used for dri4in! 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 usin! the 7 data lines, rather than the two cycles re,uired usin! the 3ibble mode. This ability enables a Byte mode for re4erse channel data transfer that can be used to pro4ide data rates into the PC approachin! 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 )nhanced Parallel Port 9)PP:. The followin! table identifies the Byte mode si!nal names, and fi!ure = shows the handshake for a Byte mode data transfer. "able 2 *yte Mode Signals

SPP Signal
3 T'(B)

*yte Mode In&'ut %ame

<ostClk (ut (ut (ut (ut In In In In In Bi*;i

!escription Signal usage (#en in *yte Mode data transfer

Pulsed low at the end of each Byte mode data transfer to indicate that the byte was recei4ed. +cknowled!e si!nal. et low to indicate host is ready for byte. et hi!h to indicate byte has been recei4ed. <andshake si!nal. et hi!h when host is in a #678 transfer mode. 3ot used. et hi!h. et low to indicate 4alid data on the data lines, set hi!h in response to <ostBusy !oin! hi!h. "orward channel Busy status. "ollows n;ata+4ail )1tensibility fla!. 3ot used in Byte mode. et low by peripheral to indicate that re4erse data is a4ailable. %sed to pro4ide data from peripheral to host.

3+%T(")); <ostBusy 3 )2)CTI3 #678+cti4e 3I3IT nI3IT 3+C0 B% & P) )2)CT 3)''(' ;+T+A7BC PtrClk PtrBusy +ck;ata'e, @fla! n;ata+4ail ;+T+A7B#C

Figure )

*yte Mode !ata "ransfer Cycle

IEEE 1284 Parallel Interface Specifications

Byte 5ode si!nal transitionsB #. <ost si!nals ability to take data by assertin! <ostBusy low 6. Peripheral responds by placin! first byte on data lines =. Peripheral si!nals 4alid byte by assertin! PtrClk low 8. <ost sets <ostBusy hi!h to indicate that it has recei4ed the and is not yet ready for another byte .. Peripheral sets PtrClk hi!h to acknowled!e host. <ost pulses <ostClk as an acknowled!ement to the peripheral ?. tates # throu!h . repeat for additional bytes

4. EPP Mode
The )nhanced Parallel Port protocol was ori!inally de4eloped by Intel, @ircom and Eenith ;ata ystems, as a means to pro4ide a hi!h performance parallel port link that would still be compatible with the standard parallel port. This protocol capability was implemented by Intel in the =7? 2 chipset 976=?/ I-( chip:. This was prior to the establishment of the I))) #678 committee and the associated standards work. The )PP protocol offered many ad4anta!es to parallel port peripheral manufactures and was ,uickly adopted by many as an optional data transfer method. + loose association of around 7/ interested manufacturers was formed to de4elop and promote the )PP protocol. This association became the )PP Committee and was instrumental in helpin! to !et this protocol adopted as one of the I))) #678 ad4anced modes. ince )PP capable parallel ports were a4ailable prior to the release of the #678 standard, there is a small de4iation between the pre*#678 )PP ports and #678 )PP protocol. This will be made clearer later. The )PP protocol pro4ides four types of data transfer cyclesB 1. ;ata $rite Cycle 2. ;ata 'ead Cycle 3. +ddress $rite Cycle 4. +ddress 'ead Cycle ;ata cycles are intended to be used to transfer data between the host and the peripheral. +ddress cycles may be used to pass address, channel, or command and control information. These cycles can be 4iewed as Dust two different data cycles. The de4eloper may use and parse the address-data information in any method that makes sense for a particular desi!n. Table = describes the )PP si!nals and their associated PP si!nals.

"able )

EPP Signal !efinitions EPP Signal %ame

n$'IT)

SPP Signal
3 T'(B)

EPP Signal !escription

(ut (ut (ut (ut In In Bi*;i In In In +cti4e low. Indicates a write operation <i!h for a read cycle. +cti4e low. Indicates a ;ataF'ead or ;ataF$rite operation is in process. +cti4e low. Indicates an +ddressF'ead or +ddressF$rite operation is in process. +cti4e low. Peripheral reset. Peripheral interrupt. %sed to !enerate an interrupt to the host. <andshake si!nal. $hen low it indicates that is (0 to start a cycle 9assert a strobe:, when hi!h it indicates that it is (0 to end the cycle 9de*assert a strobe:. Bi*directional address-data lines. Can be used differently by each peripheral Can be used differently by each peripheral. Can be used differently by each peripheral.

3+%T(")); n;+T+ TB 3 )2)CTI3 n+;;' TB 3I3IT 3+C0 B% & ;A7B#C P) )2)CT 3)''(' n') )T nI3T' n$+IT +;A7B#C user defined user defined user defined

IEEE 1284 Parallel Interface Specifications

"i!ure 8 is an e1ample of a ;ataF$rite cycle . The CP% si!nal nI($ is shown Dust to emphasize that this entire handshake occurs within a sin!le I-( cycle.

Figure 4

EPP !ata+,rite Cycle

!ata ,rite cycle p#ase transitions$

#. 6. =. 8. .. ?. >. Pro!ram e1ecutes an I-( write cycle to port 8 9)PP ;ata Port: The n$rite line is asserted and the data is output to the parallel port The data strobe is asserted, since n$+IT is asserted low The port waits for the acknowled!e from the peripheral 9n$+IT deasserted: The data strobe is deasserted and the )PP cycle ends The I + I-( cycle ends n$+IT is asserted low to indicate that the ne1t cycle may be!in

(ne of the most important features to note here is that the entire data transfer occurs within one I + I-( cycle. The effect is that by usin! the )PP protocol for data transfer, a system can achie4e transfer rates from .//0 to 65 bytes per second. In this fashion, parallel port peripherals can operate at close to the same performance le4els as an e,ui4alent I + plu!*in card. The ability to !et this le4el of performance from a parallel port attached de4ice is one of the maDor features of the )PP protocol. $ith interlocked handshakes, the data transfer will happen at the speed of the slowest of the interfaces, the host adapter or the peripheral de4ice. This "speed adapti4e" property is transparent to both the host and peripheral. +ll #678 transfer modes are implemented with interlockin! handshakes. Interlockin! refers to the criteria that each control si!nal transition is acknowled!ed by the opposite side of the interface. In the abo4e dia!ram, n;ata trobe can be asserted because n$+IT is low, n$+IT deasserts in response to n;ata trobe be asserted, n;ata trobe deasserts in response to n$+IT bein! deasserted, and finally n$+IT asserts in response to n;ata trobe bein! deasserted. In this way the peripheral can control the setup time re,uired for its operation. This is done in the followin! mannerB the setup time is the time from the assertion of n;ata trobe to the deassertion of n$+IT, the peripherals controls this time. Interlockin! also has the ad4anta!e of makin! the transfer cycle independent of the cable len!th. The 3ibble, Byte, )PP and )CP modes all ha4e interlocked protocols. +s pre4iously mentioned, the pre*#678 )PP de4ices de4iated from the #678 protocol. +t the start of the cycle, the n;ata trobe or n+ddr trobe would assert re!ardless of the state of the n$+IT si!nal. This means that the peripheral could not hold off the start of a cycle by ha4in! n$+IT deasserted. This is sometimes referred to as )PP #.>, in reference to a @ircom proposal 4ersion #.>. This is the 4ersion that Intel implemented in the ori!inal 76=?/ I-( controller. + #678 )PP compatible peripheral will work properly with an )PP #.> 4ersion host adapter, but an )PP #.> peripheral may not operate properly with a #678 compliant host. "i!ure . is an e1ample of an +ddressF'ead cycle.

IEEE 1284 Parallel Interface Specifications

Figure -

EPP .ddress+/ead Cycle

EPP /egister Interface

The simplest software 4iew of )PP is that of an e1tension to the re!ister definitions for the standard parallel port. +s shown earlier, the PP consists of three re!isters, offset from the port's base addressB ;ata port, tatus port, and Control port. The most common )PP implementations e1pand this to use ports not defined by the PP. ee table 8.

"able 4 EPP /egister !efinitions Port %ame 'ffset

PP ;ata Port PP tatus Port PP Control Port )PP +ddress Port )PP ;ata Port G/ G# G6 G= G8

Mode
PP-)PP PP-)PP PP-)PP )PP )PP )PP

/ead&,rite
$ ' $ '-$ '-$ 3-+

!escription
tandard PP data port. 3o autostrobin!. 'eads the input status lines on the interface. ets the state of the output control lines. Henerates an interlocked address read or write cycle. Henerates an interlocked data read or write cycle. %sed differently by 4arious implementations. 5ay be used for #? and =6 bit I-(.

3ot ;efined G. to G>

By !eneratin! a sin!le I-( write instruction to "baseFaddress G 8", the )PP controller will !enerate the necessary handshake si!nals and strobes to transfer the data usin! an )PP ;ataF$rite cycle. I-( instructions to the base addresses, ports / throu!h 6, will cause beha4ior e1actly as that as to a standard parallel port. This !uarantees compatibility with standard parallel port peripherals and printers. +ddress cycles are !enerated when read or write I-( operations are !enerated to "baseFaddress G =". Ports . throu!h > are used differently by 4arious hardware implementations. These may be used to implement #? or =6*bit software interfaces, or used for confi!uration re!isters, or not used at all. "or e1ample, the $arp 3ine )n!ineerin!'s' "-PortPlus card has only an 7*bit data interface, but can be accessed usin! =6*bit I-(, for )PP data operations. The I + controller will intercept the =6* bit I-( and actually !enerate 8 fast 7* bit I-( cycles. The first cycle will be to the addressed I-( port usin! byte / 9bits /*>:, the second cycle will be to portG# usin! byte #, then portG6 usin! byte 6 and finally portG= usin! byte =. These additional cycles are !enerated by hardware and are transparent to the software. The total time for these four cycles will be less than 8 independent 7 bit cycles. "or e1ample, the "-PortPlus card 9from $arp 3ine )n!ineerin!: maps 8 I-( ports 9offset 8 to >: to the internal )PP ;ata re!ister. This enables the software to use =6*bit I-( operations for )PP data transfer. +ddress cycles are still limited to 7*bit I-(. The ability to transfer data to or from the PC by the use of a sin!le instruction is what enables )PP mode parallel ports to transfer data at I + bus speeds. 'ather than ha4in! the software implement an I-( intensi4e software loop, a

IEEE 1284 Parallel Interface Specifications

block of data can be transferred with a sin!le ')PFI( instruction. ;ependin! upon the host adapter port implementation and the capability of the peripheral, an )PP port can transfer data from .//0 bytes to nearly 65 bytes per second. This data transfer rate is more than enou!h to enable network adapters, C; '(5, tape backup and other peripherals to operate at nearly I + bus performance le4els. The )PP protocol and current implementations pro4ide a hi!h de!ree of couplin! between the peripheral dri4er and the peripheral. $hat this means is the software dri4er is always able to determine and control the state of communication to the peripheral at any !i4en time. Intermi1in! of read and write operations as well as block transfers are readily done. This type of couplin! is ideal for many re!ister*oriented or real*time controlled peripherals such as network adapters, data ac,uisition, portable hard dri4es, and other de4ices.

-. ECP Mode
The )1tended Capability Port, or )CP, protocol was proposed by <ewlett Packard and 5icrosoft as an ad4anced mode for communication with printer and scanner type peripherals. 2ike the )PP protocol, )CP pro4ides for a hi!h performance bi*directional communication path between the host adapter and the peripheral. The )CP protocol pro4ides the followin! cycle types in both the forward and re4erse directionsB #. ;ata cycles 1. Command cycles The command cycles are di4ided into 6 types, 'un*2en!th Count and Channel address. %nlike )PP, when the )CP protocol was proposed, a standard re!ister implementation was also proposed. This can be found in the 5icrosoft document "The I))) #678 )1tended Capabilities Port Protocol and I + Interface tandard" a4ailable from 5icrosoft Corp. This document defines features that are implementation specific which the I))) #678 standard could not address. These features include 'unF2en!thF)ncodin! 9'2): data compression for the host adapters, "I"(s for both the forward and re4erse channels, and ;5+ as well as pro!rammed I-( for the host re!ister interface. The '2) feature enables real time data compression that can achie4e compression ratios up to ?8B#. This is particularly useful for printers and scanners that are transferrin! lar!e raster ima!es that ha4e lar!e strin!s of identical data. In order for the '2) mode to be enabled both the host and the peripheral must support it. Channel addressin! is, conceptually, a little different than the )PP addressin!. Channel addressin! is intended to be used to address multiple lo!ical de4ices within a sin!le physical de4ice. Think of this in terms of a new multi*function de4ice such as "+@-Printer-5odem. $ithin one physical packa!e, ha4in! a sin!le parallel port attached, there is a printer, fa1 and modem. )ach of these separate functions can be thou!ht of as separate lo!ical de4ices within the same packa!e. %sin! the )CP channel addressin! to access each of these de4ices, you could recei4e data from the modem data de4ice while the printer data channel is busy processin! a print ima!e. $ith the compatibility mode protocol, if the printer !ets busy then no more communication can occur until the printer data channel if free. $ith )CP, the software dri4er simply addresses another channel and communication can continue. +s with the other #678 modes, the )CP protocol redefines the handshake. Table . describes these si!nals. PP si!nals to be more consistent with the )CP

IEEE 1284 Parallel Interface Specifications "able SPP Signal 3 T'(B) ECP Mode %ame <ostClk In&' ut (ut

8 ECP Mode Signals

!escription 0 Signal usage (#en in ECP Mode data transfer

3+%T(")); <ost+ck

3 )2)CTI3 #678+cti4e n'e4erse'e, 3I3IT (ut ;ri4en low to put the channel in re4erse direction. uest 3+C0 PeriphClk In %sed with <ost+ck to transfer data in the re4erse direction. %sed with <ostClk to transfer data or address information in the forward direction. B% & Periph+ck In Pro4ides Command-;ata status in the re4erse direction. P) n+ck'e4erse In ;ri4en low to acknowled!e n'e4erse'e,uest. )2)CT @fla! In )1tensibility fla!. nPeriph'e,ue 3)''(' In et low by peripheral to indicate that re4erse data is a4ailable. st ;ataA7B#C ;ataA7B#C Bi*;i %sed to pro4ide data between the peripheral and host. "i!ure ? shows two forward data transfer cycles. $hen <ost+ck is hi!h it indicates that a data cycle is takin! place. $hen <ost+ck is asserted low, a command cycle is takin! place and the data represents either an '2) count or a Channel address. Bit 7, of the data byte is used to indicate '2) 4s. Channel address. If bit 7 is /, then bits #*> represent a 'unF2en!th Count 9/*#6>:. If bit 7 is #, then bits #*> represent a Channel address 9/*#6>:. "i!ure ? shows a data cycle followed by a command cycle. "i!ure > shows a re4erse channel command cycle followed by a re4erse channel data cycle. The I-( read or write strobes are not shown in these fi!ures. This is because the )CP "I"(s are used to decouple the I + data transfers, either ;5+ or pro!rammed I-(, from the actual host-peripheral data transfers. It is this decouplin! of the transfer states that makes the )CP protocol a "loosely coupled" protocol. The software dri4er does not know the e1act state of the data transfers. If a lar!e block is bein! transferred 4ia ;5+, the dri4er does not know if the #6=rd byte is bein! transferred or the =86,6/#st byte. +s in the case of printers, the software may not care. The only concern is whether the transfer was completed or not.

%sed with Periph+ck to transfer data or address information in the forward direction. Pro4ides Command-;ata status in the forward direction. %sed with PeriphClk to (ut transfer data in the re4erse direction. (ut et hi!h when host is in a #678 transfer mode.

Figure 1

ECP For(ard !ata and Command Cycle

"orward Transfer phase transistionsB

#. 6. =. 8. .. ?. The host places data on the data lines and indicates a data cycle by settin! <ost+ck hi!h. <ost asserts <ostClk low to indicate 4alid data Peripheral acknowled!es host by settin! Periph+ck hi!h <ost sets <ostClk hi!h. This is the ed!e that should be used to clock the data in to the peripheral. Peripheral sets Periph+ck low to indicate that it is ready for the ne1t byte. The cycle repeats, but this time it is a command cycle because <ost+ck is low.

3(T)B ince )CP transfers are loosely coupled, with a "I"( 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 8, when the <ostClk !oes hi!h. +t

IEEE 1284 Parallel Interface Specifications

this time, the data should be clocked in to the peripheral, and any data counters updated. There is a condition in the )CP protocol that could cause the transfer to abort at between steps = and 8. In this case the data should not be considered to ha4e been transferred. "i!ure > shows another of the differences between the )CP and )PP protocols. $ith )PP, the software dri4er may intermi1 read and write operations without any o4erhead or protocol handshakin!. $ith the )CP protocol, chan!es in the data direction must be ne!otiated. The host must re,uest a re4erse channel transfer by assertin! n'e4erse'e,uest and then wait for the peripheral to acknowled!e the re,uest by assertin! n+ck'e4erse. (nly then can a re4erse channel data transfer take place. In addition, since the pre4ious transfer may ha4e been ;5+ dri4en, the host software must either wait for the ;5+ to complete, or interrupt the ;5+, backflush the "I"( to determine the e1act transferred byte count, and then re,uest the re4erse channel. This adds a fair amount of o4erhead with peripherals that re,uire a lot of intermi1ed readin! and writin! of re!isters or small buffers.

Figure 2

ECP /e3erse !ata and Command Cycle

'e4erse Transfer phase transistionsB

#. 6. =. 8. .. ?. >. 7. The host re,uests a re4erse channel transfer by settin! n'e4erse'e,uest low. The peripheral si!nals that it is (0 to proceed by settin! n+ck'e4erse low The peripheral places data on the data lines and indicates a data cycle by settin! Periph+ck hi!h. Peripheral asserts PeriphClk low to indicate 4alid data <ost acknowled!es by settin! <ost+ck hi!h Peripheral sets PeriphClk hi!h. This is the ed!e that should be used to clock the data in to the host. <ost sets <ost+ck low to indicate that it is ready for the ne1t byte. The cycle repeats, but this time it is a command cycle because Periph+ck is low.

ECP Soft(are and /egister Interface

The 5icrosoft specification, "The I))) #678 )1tended Capabilities Port Protocol and I + Interface tandard", defines a common re!ister interface for I + based #678 adapters with )CP. This specification also defines a number of operational modes that the adapter can operate under. Table ? identifies these modes.

"able 1 Mode
/// PP mode

EC/ /egister Modes !escription

IEEE 1284 Parallel Interface Specifications

//# /#/ /## #// #/# ##/ ### Bi*directional mode 9Byte mode: "ast Centronics )CP Parallel Port mode )PP Parallel Port mode 9note #: 9reser4ed: Test mode Confi!uration mode

10

9note #: This mode is implemented by the

5C ";C=>C??.-??? controller and is not defined by the )CP specification. 5ost #678 I-( controllers implement the )PP mode in a similar fashion. The re!ister model for an )CP port is similar to that of the standard parallel port, but takes ad4anta!e of a si!nificant desi!n oddity of the I + bus architecture. In the IB5 compatible PC architecture, only the first #/68 I-( ports, or addresses, are used. This is the basic I-( space of /1///h to /1=ffh. In order to address this ran!e of addresses, only #/ address bits are needed 9+;/*I:. In order to sa4e cost, older PC's only dro4e and decoded these address bits on the I + bus and therefore limited the a4ailable I-( space to these #/68 re!isters. 3ewer PC's, actually dri4e and decode more address bits, enablin! a lar!er a4ailable I-( space. This creates, in effect, multiple "pa!es" of the first #0 I-( ports. + software dri4er can access these pa!es by addin! #/68 9/18//h he1 notation: to the base address bein! accessed. Therefore, addressin! addresses /1=>7h and /1>>7h can access 6 re!isters on two separate pa!es, but be !uaranteed not to interfere with any other installed I + de4ice. The ad4anta!e is that by usin! this "aliasin!" effect, new cards can ha4e "hidden" re!isters, thus e1pandin! the a4ailable number of re!isters a4ailable, and still maintain compatibility with older I + cards that only decode #/ address bits. The )CP re!ister model takes ad4anta!e of this and defines ? re!isters that only re,uire = actual I-( ports. Table > identifies these re!isters. 3ote that the re!ister definition may be dependent upon the current mode of operation. The )C' re!ister is the most important aspect of this re!ister confi!uration. This is the re!ister that is used to set the current operational mode. +dditionally, this re!ister can be used by software to determine if an )CP*capable port is installed in the PC. ;etection software can try to access any )C' re!isters by addin! /18/6h to the base address of the 2PT ports identified in the BI( 2PT port table. "able 2 ECP /egister !escription

'ffset
/// /// //# //6 8// 8// 8// 8// 8/# 8/6

%ame
;ata ecp+fifo dsr dcr c"ifo ecp;fifo tfifo cnf!+ cnf!B ecr

/ead&,rite
'-$ '-$ '-$ '-$ '-$ '-$ '-$ ' '-$ '-$

ECP Mode
///*//# /## all all /#/ /## ##/ ### ### all

Function
;ata 'e!ister )CP +ddress "I"( tatus 'e!ister Control 'e!ister Parallel Port ;ata "I"( )CP ;ata "I"( Test "I"( Confi!uration 'e!ister + Confi!uration 'e!ister B )1tended Control 'e!ister

This paper will not attempt to describe all the functions of the )CP re!isters. "or information re!ardin! the re!ister usa!e and bit definitions, please refer to the 5icrosoft document or the I-( 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 = re!isters beha4e e1actly as a standard parallel port. This way, compatibility with older de4ices and de4ice dri4ers is maintained.

%sa!e of this port is similar to that of the )PP port. +n operational mode is written to the ecr re!ister, and then data transfer is accomplished by writin! or readin! from the appropriate I-( port. +ll of the handshakin! is automatically !enerated by the interface controller. The maDor difference is that the )CP port is meant to be dri4en by ;5+ rather than e1plicit I-( operations. +!ain, this is a loosely coupled interface that is tar!eted primarily at peripherals that interchan!e lar!e blocks of data.