Mail Ack Button

Most of the times it becomes important to know whether the receiver of our mail has read the mail or not. Mail Ack Button provides an addition feather, which can be selected by the owner of the email id which gives the receiver to send a acknowledge to the sender by clicking on the ack button.
This feature is fully optional and must be possess by both sides to use it.  

lcd commands

No.	Instruction	Hex	Decimal
1	Function Set: 8-bit, 1 Line, 5x7 Dots	0x30	48
2	Function Set: 8-bit, 2 Line, 5x7 Dots	0x38	56
3	Function Set: 4-bit, 1 Line, 5x7 Dots	0x20	32
4	Function Set: 4-bit, 2 Line, 5x7 Dots	0x28	40
5	Entry Mode	0x06	6
6	Display off Cursor off (clearing display without clearing DDRAM content)	0x08	8
7	Display on Cursor on	0x0E	14
8	Display on Cursor off	0x0C	12
9	Display on Cursor blinking	0x0F	15
10	Shift entire display left	0x18	24
12	Shift entire display right	0x1C	30
13	Move cursor left by one character	0x10	16
14	Move cursor right by one character	0x14	20
15	Clear Display (also clear DDRAM content)	0x01	1
16	Set DDRAM address or coursor position on display	0x80+add*	128+add*
17	Set CGRAM address or set pointer to CGRAM location	0x40+add**	64+add**

EPP Explained

Interfacing the Enhanced Parallel Port Table of Contents Enhanced Parallel Port EPP Hardware Properties The EPP Handshake EPP Data Write Cycle EPP Address Write Cycle EPP Data Read Cycle EPP Address Read Cycle The EPP's Software Registers EPP Programming Considerations EPP - Enhanced Parallel Port The Enhanced Parallel Port (EPP) was designed in a joint venture between Intel, Xircom & Zenith Data Systems. EPP Ports were first specified in the EPP 1.7 standard, and then later included in the IEEE 1284 Standard released in 1994. EPP has two standards, EPP 1.7 and EPP 1.9. There are differences between the two standards which may affect the operation of devices. This is further discussed latter. EPP has a typical transfer rate in the order of 500KB/S to 2MB/S. This is achieved by allowing the hardware contained in the port to generate handshaking, strobing etc, rather that have the software do it, which was the case with Centronics. For the hobbyist, EPP is more commonly used than ECP. EPP differs from ECP by the fact that the EPP Port generates and controls all the transfers to and from the peripheral. ECP on the other hand requires the peripheral to negotiate a reverse channel and control the handshaking. This is harder to achieve with common glue logic, thus really requires a dedicated controller or ECP Peripheral Chip. EPP Hardware Properties When using EPP mode, a different set of tasks and labels are assigned to each line. These are listed below in Table 4. It's very common to see both the SPP and EPP names interchanged in Parallel Port Data Sheets and Literature. This can make it very hard to focus on what is exactly happening. Therefore all the documentation here will use the EPP names. Pin SPP Signal EPP Signal IN/OUT Function 1 Strobe Write Out A low on this line indicates a Write, High indicates a Read 2-9 Data 0-7 Data 0-7 In-Out Data Bus. Bi-directional 10 Ack Interrupt In Interrupt Line. Interrupt occurs on Positive (Rising) Edge. 11 Busy Wait In Used for handshaking. A EPP cycle can be started when low, and finished when high. 12 Paper Out / End Spare In Spare - Not Used in EPP Handshake 13 Select Spare In Spare - Not Used in EPP Handshake 14 Auto Linefeed Data Strobe Out When Low, indicates Data transfer 15 Error / Fault Spare In Spare - Not used in EPP Handshake 16 Initialize Reset Out Reset - Active Low 17 Select Printer Address Strobe Out When low, indicates Address transfer 18-25 Ground Ground GND Ground Table 1. Pin Assignments For Enhanced Parallel Port Connector. Paper Out, Select and Error are not defined in the EPP handshake. These lines can be utilised in any way by the user. The status of these lines can be determined at anytime by viewing the SPP Status Register. Unfortunately there are no spare output's. This can become a hassle regularly. The EPP Handshake In order to perform a valid exchange of data using EPP we must follow the EPP handshake. As the hardware does all the work, this handshake only requires to be used for your hardware and not for software as the case with SPP. To initiate an EPP cycle your software needs to perform only one I/O operation to the relevant EPP Register. Details on this, latter. EPP Data Write Cycle Figure 1. Enhanced Parallel Port Data Write Cycle. 1. Program writes to EPP Data Register. (Base + 4) 2. nWrite is placed low. (Low indicates write operation) 3. Data is placed on Data Lines 0-7. 4. nData Strobe is asserted if Wait is Low (O.K. to start cycle) 5. Host waits for Acknowledgment by nWait going high (O.K. to end cycle) 6. nData Strobe is de-asserted. 7. EPP Data Write Cycle Ends. EPP Address Write Cycle Figure 2. Enhanced Parallel Port Address Write Cycle. 1. Program writes address to EPP's Address Register (Base + 3) 2. Write is placed low. (Low indicates write operation) 3. Address is placed on Data Lines 0-7. 4. Address Strobe is asserted if Wait is Low (O.K. to start cycle) 5. Host waits for Acknowledgment by wait going high (O.K. to end cycle) 6. nAddress Strobe is De-asserted. 7. EPP Address Write Cycle Ends. EPP Data Read Cycle Figure 3. Enhanced Parallel Port Data Read Cycle. 1. Program reads EPP Data Register. (Base + 4) 2. nData Strobe is asserted if Wait is Low (O.K. to start cycle) 3. Host waits for Acknowledgment by nWait going high 4. Data is read from Parallel Port Pins. 5. nData Strobe is de-asserted. 6. EPP Data Read Cycle Ends. EPP Address Read Cycle Figure 4. Enhanced Parallel Port Address Read Cycle. 1. Program reads EPP Address Register. (Base + 3) 2. nAddr Strobe is asserted if Wait is Low (O.K. to start cycle) 3. Host waits for Acknowledgment by nWait going high 4. Data is read from Parallel Port Pins. 5. nAddr Strobe is de-asserted. 6. EPP Address Read Cycle Ends. Note If implementing EPP 1.7 Handshake (Pre IEEE 1284) the Data and Address Strobes can be asserted to start a cycle regardless of the wait state. EPP 1.9 will only start a cycle once wait is low. Both EPP 1.7 and EPP 1.9 require the wait to be high to finish a cycle. The EPP's Software Registers. The EPP Port also has a new set of registers. However 3 of them have been inherited from the Standard Parallel Port. Below is a table showing the new and existing registers. Address Port Name Read/Write Base + 0 Data Port (SPP) Write Base + 1 Status Port (SPP) Read Base + 2 Control Port (SPP) Write Base + 3 Address Port (EPP) Read/Write Base + 4 Data Port (EPP) Read/Write Base + 5 Undefined (16/32bit Transfers) - Base + 6 Undefined (32bit Transfers) - Base + 7 Undefined (32bit Transfers) - Table 2 EPP Registers As you can see, the first 3 addresses are exactly the same than the Standard Parallel Port Register and behave in exactly the same way. Therefore if you used a Enhanced Parallel Port, you can output data to Base + 0 in exactly the same fashion than you would if it was a Standard Parallel Port (SPP). If you were to connect a printer, and use compatibility mode then you would have to check to see if the port is busy and then assert & de-assert the strobe using the Control and Status Port, then wait for the Ack. If you wish to communicate with a EPP compatible device then all you have to do, is place any data you wish to send in the EPP Data Register at Base + 4 and the card will generate all the necessary handshaking required. Likewise if you wish to send an address to your device, then you use the EPP Address Register at offset +3. Both the EPP Address Register and the EPP Data Register are read / write, thus to read data from your device, you can use the same registers. However the EPP Printer Card has to initiate a read Cycle as both the nData Strobe and nAddress Strobe are outputs. Your device can signal a read request via the use of the interrupt and have your ISR perform the Read Operation. The Status Port has one little modification. Bit 0, which was reserved in the SPP register set, now becomes the EPP Time-out Bit. This bit will be set when an EPP time-out occurs. This happens when the nWait line is not deasserted within approximately 10uS (depending upon the port) of the IOW or IOR line being asserted. The IOW and IOR are the I/O Read and Write lines present on the ISA Bus. The EPP mode is very depended of the ISA bus timing. When a read cycle is performed, the port must undertake the appropriate Read/Write handshake and return the data in that ISA cycle. Of course this doesn't occur within one ISA cycle, thus the port uses the IOCHRDY (I/O Channel Ready) on the ISA bus to introduce wait states, until the cycle completes. Now imagine if a EPP Read or Write is started with no peripheral connected? The port never gets an acknowledgment (nWait), thus keeps sending requests for wait states, and your computer locks up. Therefore the EPP implements a type of watchdog, which times out after approximately 10uS. The three registers, Base + 5, Base + 6 and Base + 7 can be used for 16 and 32 bit read/write operations if your port supports it. This can further reduce your I/O operations. The Parallel Port can only transport 8 bits at a time, thus any 32 or 16 bit word written to the Parallel Port will be split into byte size blocks and sent via the Parallel Port's 8 data lines. EPP Programming Considerations. EPP only has two main registers and a Time-out Status Flag, What could there possibly be to set up? Before you can start any EPP cycles by reading and writing to the EPP Data and Address Ports, the port must be configured correctly. In the idle state, an EPP port should have it's nAddress Strobe, nData Strobe, nWrite and nReset lines inactive, high. Some ports require you to set this up before starting any EPP Cycle. Therefore our first task is to manually initialise these lines using the SPP Registers. Writing XXXX0100 to the control port will do this. On some cards, if the Parallel Port is placed in reverse mode, a EPP Write cycle cannot be performed. Therefore it is also wise to place the Parallel Port in forward mode before using EPP. Clearing Bit 5 of the Control Register should result in an more enjoyable programming session, without tearing your hair out. The EPP Timeout bit we have already discussed. When this bit is set, the EPP port may not function correctly. A common scenario is always reading 0xFF from either the Address or Data Cycles. This bit should be cleared for reliable operation, and constantly checked.

ECP Explained

Interfacing the Extended Capabilities Port Table of Contents Introduction to the Extended Capabilities Port ECP Hardware Properties The ECP Handshake ECP Forward Data Cycle ECP Forward Command Cycle ECP Reverse Data Cycle ECP Reverse Command Cycle ECP Handshake vs SPP Handshake RLE - Run Length Encoding ECP Software Registers ECP's Extended Control Register (ECR) ECP's Configuration Register A (cnfgA) ECP's Configuration Register B (cnfgB) Introduction to the Extended Capabilities Port The Extended Capabilities Mode was designed by Hewlett Packard and Microsoft to be implemented as the Extended Capabilities Port Protocol and ISA Interface Standard. This protocol uses additional hardware to generate handshaking signals etc just like the EPP mode, thus runs at very much the same speed than the EPP mode. This mode, however may work better under Windows as it can use DMA channels to move it's data about. It also uses a FIFO buffer for the sending and/or receiving of data. Another feature of ECP is a real time data compression. It uses Run Length Encoding (RLE) to achieve data compression ratio's up to 64:1. This comes is useful with devices such as Scanners and Printers where a good part of the data is long strings which are repetitive. The Extended Capabilities Port supports a method of channel addressing. This is not intended to be used to daisy chain devices up but rather to address multiple devices within one device. Such an example is many fax machines on the market today which may contain a Parallel Port to interface it to your computer. The fax machine can be split up into separate devices such as the scanner, modem/Fax and printer, where each part can be addresses separately, even if the other devices cannot accept data due to full buffers. ECP Hardware Properties While Extended Capabilities Printer Ports use exactly the same D25 connector as your SPP, ECP assigns different tasks to each of the pins, just like EPP. This means that there is also a different handshake method when using a ECP interface. The ECP is backwards compatible to the SPP and EPP. When operating in SPP mode, the individual lines operate in exactly the same fashion than the SPP and thus are labeled Strobe, Auto Linefeed, Init, Busy etc. When operating in EPP mode, the pins function according to the method described in the EPP protocol and have a different method of Handshaking. When the port is operating in ECP mode, then the following labels are assigned to each pin. Pin SPP Signal ECP Signal IN/OUT Function 1 Strobe HostCLK Out A low on this line indicates, that there is valid data at the host. When this pin is de-asserted, the +ve clock edge should be used to shift the data into the device. 2-9 Data 0-7 Data 0-7 In/Out Data Bus. Bi-directional 10 Ack PeriphCLK In A low on this line indicates, that there is valid data at the Device. When this pin is de-asserted, the +ve clock edge should be used to shift the data into the Host. 11 Busy PeriphAck In When in reverse direction a HIGH indicates Data, while a LOW indicates a Command Cycle. In forward direction, functions as PeriphAck. 12 Paper Out / End nAckReverse In When Low, Device acknowledges Reverse Request. 13 Select X-Flag In Extensibility Flag 14 Auto Linefeed Host Ack Out When in forward direction a HIGH indicates Data, while a LOW indicates a Command Cycle. In reverse direction, functions as HostAck. 15 Error / Fault PeriphRequest In A LOW set by the device indicates reverse data is available 16 Initialize nReverseRequest Out A LOW indicates data is in reverse direction 17 Select Printer 1284 Active Out A HIGH indicates Host is in 1284 Transfer Mode. Taken low to terminate. 18-25 Ground Ground GND Ground Table 1. Pin Assignments For Extended Capabilities Parallel Port Connector. The HostAck and PeriphAck lines indicate whether the signals on the data line are data or a command. If these lines are high then data is placed on the data lines (Pins 2-7). If a command cycle is taking place then the appropriate line will be low, ie if the host is sending a command, then HostAck will be low or if the device/peripheral is sending a command the PeriphAck line will be low. A command cycle can be one of two things, either a RLE count or an address. This is determined by the bit 7 (MSB) of the data lines, ie Pin 9. If bit 7 is a 0, then the rest of the data (bits 0-6) is a run length count which is used with the data compression scheme. However if bit 7 is a 1, then the data present on bits 0 to 6 is a channel address. With one bit missing this can only be a value from 0 to 127(DEC). The ECP Handshake The ECP handshake is different to the SPP handshake. The most obvious difference is that ECP has the ability at anytime to transmit data in any direction, thus additional signaling is required. Below is the ECP handshake for both the Forward and Reverse Directions. ECP Forward Data Cycle Figure 1. Enhanced Capabilities Port Forward Data Cycle. 1. Data is placed on Data lines by Host. 2. Host then indicates a Data Cycle will proceed by asserting HostAck. 3. Host indicates valid data by asserting HostClk low. 4. Peripheral sends its acknowledgment of valid data by asserting PeriphAck. 5. Host de-asserts HostClk high. +ve edge used to shift data into the Peripheral. 6. Peripheral sends it's acknowledgment of the byte via de-asserting PeriphAck. ECP Forward Command Cycle Figure 2. Enhanced Capabilities Port Forward Command Cycle. 1. Data is placed on Data lines by Host. 2. Host then indicates a Command cycle will proceed by de-asserting HostAck. 3. Host indicates valid data by asserting HostClk low. 4. Peripheral sends its acknowledgment of valid data by asserting PeriphAck. 5. Host de-asserts HostClk high. +ve edge used to shift data into the Peripheral. 6. Peripheral sends it's acknowledgment of the byte via de-asserting PeriphAck. ECP Reverse Data Cycle Figure 3. Enhanced Capabilities Port Reverse Data Cycle. 1. Host sets nReverseRequest Low to request a reverse channel. 2. Peripheral acknowledges reverse channel request via asserting nAckReverse low. 3. Data is placed on data lines by Peripheral. 4. Data cycle is then selected by Peripheral via PeriphAck going high. 5. Valid data is indicated by the Peripheral setting PeriphClk low. 6. Host sends its acknowledgment of valid data via HostAck going high. 7. Device/Peripheral sets PeriphClk high. +ve edge used to shift data into the Host. 8. Host sends it's acknowledgment of the byte by de-asserting HostAck low. ECP Reverse Command Cycle Figure 4. Enhanced Capabilities Port Reverse Command Cycle. 1. Host sets nReverseRequest Low to request a reverse channel. 2. Peripheral acknowledges reverse channel request via asserting nAckReverse low. 3. Data is placed on data lines by Peripheral. 4. Command cycle is then selected by Peripheral via PeriphAck going low. 5. Valid data is indicated by the Peripheral setting PeriphClk low. 6. Host sends its acknowledgment of valid data via HostAck going high. 7. Device/Peripheral sets PeriphClk high. +ve edge used to shift data into the Host. 8. Host sends it's acknowledgment of the byte by de-asserting HostAck low. ECP Handshake vs SPP Handshake If we look back at the SPP Handshake you will realize it only has 5 steps, 1. Write the byte to the Data Port. 2. Check to see is the printer is busy. If the printer is busy, it will not accept any data, thus any data which is written will be lost. 3. Take the Strobe (Pin 1) low. This tells the printer that there is the correct data on the data lines. (Pins 2-9) 4. Put the strobe high again after waiting approximately 5 microseconds after putting the strobe low. (Step 3) 5. Check for Ack from Peripheral. and that the ECP handshake has many more steps. This would suggest that ECP would be slower that SPP. However this is not the case as all of these steps above are controlled by the hardware on your I/O control. If this handshake was implemented via software control then it would be a lot slower that it's SPP counterpart. RLE - Run Length Encoding As briefly discussed earlier, the ECP Protocol includes a Simple Compression Scheme called Run Length Encoding. It can support a maximum compression ratio of 64:1 and works by sending repetitive single bytes as a run count and one copy of the byte. The run count determines how many times the following byte is to be repeated. For example, if a string of 25 'A's were to be sent, then a run count byte equal to 24 would be sent first, followed by the byte 'A'. The receiving peripheral on receipt of the Run Length Count, would expand (Repeat) the next byte a number of times determined via the run count. The Run Length Byte has to be distinguished from other bytes in the Data Path. It is sent as a Command to the ECP's Address FIFO Port. Bytes sent to this register can be of two things, a Run Length Count or an Address. These are distinguished by the MSB, Bit 7. If Bit 7 is Set (1), then the other 7 bits, bits 0 to 6 is a channel address. If Bit 7 is Reset (0), then the lower 7 bits is a run length count. By using the MSB, this limits channel Addresses and Run Length Counts to 7 Bits (0 - 127). ECP Software Registers The table below shows the registers of the Extended Capabilities Port. The first 3 registers are exactly the same than with the Standard Parallel Port registers. Note should be taken, however, of the Enable Bi-Directional Port bit (bit 5 of the Control Port.) This bit reflects the direction that the ECP port is currently in, and will effect the FIFO Full and FIFO Empty bits of the ECR Register, which will be explained later. Address Port Name Read/Write Base + 0 Data Port (SPP) Write ECP Address FIFO (ECP MODE) Read/Write Base + 1 Status Port (All Modes) Read/Write Base + 2 Control Port (All Modes) Read/Write Base + 400h Data FIFO (Parallel Port FIFO Mode) Read/Write Data FIFO (ECP Mode) Read/Write Test FIFO (Test Mode) Read/Write Configuration Register A (Configuration Mode) Read/Write Base + 401h Configuration Register B (Configuration Mode) Read/Write Base + 402h Extended Control Register (Used by all modes) Read/Write Table 2 : ECP Registers ECP's Extended Control Register (ECR) The most important register with a Extended Capabilities Parallel Port is the Extended Control Register (ECR) thus we will target it's operation first. This register sets up the mode in which the ECP will run, plus gives status of the ECP's FIFO among other things. You will find the contents of this register below, in more detail. Bit Function 7:5 Selects Current Mode of Operation 000 Standard Mode 001 Byte Mode 010 Parallel Port FIFO Mode 011 ECP FIFO Mode 100 EPP Mode 101 Reserved 110 FIFO Test Mode 111 Configuration Mode 4 ECP Interrupt Bit 3 DMA Enable Bit 2 ECP Service Bit 1 FIFO Full 0 FIFO Empty Table 3 ECR - Extended Control Register The three MSB of the Extended Control Register selects the mode of operation. There are 7 possible modes of operation, but not all ports will support all modes. The EPP mode is one such example, not being available on some ports. Below is a table of Modes of Operation. Modes of Operation Standard Mode Selecting this mode will cause the ECP port to behave as a Standard Parallel Port, without Bi-directional functionality. Byte Mode / PS/2 Mode Behaves as a SPP in Bi-directional (Reverse) mode. Parallel Port FIFO Mode In this mode, any data written to the Data FIFO will be sent to the peripheral using the SPP Handshake. The hardware will generate the handshaking required. Useful with non-ECP devices such as Printers. You can have some of the features of ECP like FIFO buffers and hardware generation of handshaking but with the existing SPP handshake instead of the ECP Handshake. ECP FIFO Mode Standard Mode for ECP Use. This mode uses the ECP Handshake, already described. EPP Mode/Reserved On some chipsets, this mode will enable EPP to be used. While on others, this mode is still reserved. Reserved Currently Reserved FIFO Test Mode While in this mode, any data written to the Test FIFO Register will be placed into the FIFO and any data read from the Test FIFO register will be read from the FIFO buffer. The FIFO Full/Empty Status Bits will reflect their true value, thus FIFO depth, among other things can be determined in this mode. Configuration Mode In this mode, the two configuration registers, cnfgA & cnfgB become available at their designated Register Addresses. As outlined above, when the port is set to operate in Standard Mode, it will behave just like a Standard Parallel Port (SPP) with no bi-directional data transfer. If you require bi-directional transfer, then set the mode to Byte Mode. The Parallel Port FIFO mode and ECP FIFO mode both use hardware to generate the necessary handshaking signals. The only difference between each mode is that The Parallel Port FIFO Mode uses SPP handshaking, thus can be used with your SPP printer. ECP FIFO mode uses ECP handshaking. The FIFO test mode can be used to test the capacity of the FIFO Buffers as well as to make sure they function correctly. When in FIFO test mode, any byte which is written to the TEST FIFO (Base + 400h) is placed into the FIFO buffer and any byte which is read from this register is taken from the FIFO Buffer. You can use this along with the FIFO Full and FIFO Empty bits of the Extended Control Register to determine the capacity of the FIFO Buffer. This should normally be about 16 Bytes deep. The other Bits of the ECR also play an important role in the operation of the ECP Port. The ECP Interrupt Bit, (Bit 4) enables the use of Interrupts, while the DMA Enable Bit (Bit 3) enables the use of Direct Memory Access. The ECP Service Bit (Bit 2) shows if an interrupt request has been initiated. If so, this bit will be set. Resetting this bit is different with different chips. Some require you to Reset the Bit, E.g. Write a Zero to it. Others will reset once the Register has been read. The FIFO Full (Bit 1) and FIFO Empty (Bit 0) show the status of the FIFO Buffer. These bits are direction dependent, thus note should be taken of the Control Register's Bit 5. If bit 0 (FIFO Empty) is set, then the FIFO buffer is completely empty. If Bit 1 is set then the FIFO buffer is Full. Thus, if neither bit 0 or 1 is set, then there is data in FIFO, but is not yet full. These bits can be used in FIFO Test Mode, to determine the capacity of the FIFO Buffer. ECP's Configuration Register A (cnfgA) Configuration Register A is one of two configuration registers which the ECP Port has. These Configuration Registers are only accessible when the ECP Port is in Configuration Mode. (See Extended Control Register) CnfgA can be accessed at Base + 400h. Bit Function 7 1 Interrupts are level triggered 0 Interrupts are edge triggered (Pulses) 6:4 00h Accepts Max. 16 Bit wide words 01h Accepts Max. 8 Bit wide words 02h Accepts Max. 32 Bit wide words 03h:07h Reserved for future expansion 3 Reserved 2 Host Recovery : Pipeline/Transmitter Byte included in FIFO? 0 In forward direction, the 1 byte in the transmitter pipeline doesn't affect FIFO Full. 1 In forward direction, the 1 byte in the transmitter pipeline is include as part of FIFO Full. 1:0 Host Recovery : Unsent byte(s) left in FIFO 00 Complete Pword 01 1 Valid Byte 10 2 Valid Bytes 11 3 Valid Bytes Table 4 - Configuration Register A Configuration Register A can be read to find out a little more about the ECP Port. The MSB, shows if the card generates level interrupts or edge triggered interrupts. This will depend upon the type of bus your card is using. Bits 4 to 6, show the buses width within the card. Some cards only have a 8 bit data path, while others may have a 32 or 16 bit width. To get maximum efficiency from your card, the software can read the status of these bits to determine the Maximum Word Size to output to the port. The 3 LSB's are used for Host Recovery. In order to recover from an error, the software must know how many bytes were sent, by determining if there are any bytes left in the FIFO. Some implementations may include the byte sitting in the transmitter register, waiting to be sent as part of the FIFO's Full Status, while others may not. Bit 2 determines weather or not this is the case. The other problem is that the Parallel Ports output is only 8 bits wide, and that you many be using 16 bit or 32 bit I/O Instructions. If this is the case, then part of your Port Word (Word you sent to port) may be sent. Therefore Bits 0 and 1 give an indication of the number of valid bytes still left in the FIFO, so that you can retransmit these. ECP's Configuration Register B (cnfgB) Configuration Register B, like Configuration Register A is only available when the ECP Port is in Configuration Mode. When in this mode, cnfgB resides at Base + 401h. Below is the make-up of the cnfgB Register. Bit(s) Function 7 1 Compress outgoing Data Using RLE 0 Do Not compress Data 6 Interrupt Status - Shows the Current Status of the IRQ Pin 5:3 Selects or Displays Status of Interrupt Request Line. 000 Interrupt Selected Via Jumper 001 IRQ 7 010 IRQ 9 011 IRQ 10 100 IRQ 11 101 IRQ 14 110 IRQ 15 111 IRQ 5 2:0 Selects or Displays Status of the DMA Channel the Printer Card Uses 000 Uses a Jumpered 8 Bit DMA Channel 001 DMA Channel 1 010 DMA Channel 2 011 DMA Channel 3 100 Uses a Jumpered 16 Bit DMA Channel 101 DMA Channel 5 110 DMA Channel 6 111 DMA Channel 7 Table 5 - Configuration B Register The Configuration Register B (cnfgB) can be a combination of read/write access. Some ports may be software configurable, where you can set the IRQ and DMA resources from the register. Others may be set via BIOS or by using jumpers on the Card, thus are read only. Bit 7 of the cnfgB Register selects whether to compress outgoing data using RLE (Run Length Encoding.) When Set, the host will compress the data before sending. When reset, data will be sent to the peripheral raw (Uncompressed). Bit 6 returns the status of the IRQ pin. This can be used to diagnose conflicts as it will not only reflect the status of the Parallel Ports IRQ, but and other device using this IRQ. Bits 5 to 3 give status of about the Port's IRQ assignment. Likewise for bits 2 to 0 which give status of DMA Channel assignment. As mentioned above these fields may be read/write. The disappearing species of Parallel Cards which have Jumpers may simply show it's resources as "Jumpered" or it may show the correct Line Numbers. However these of course will be read only.

USB DEVICE DRIVER PROGRAM

header:

#include<linux/init.h>
#include<linux/module.h>
#include<linux/usb.h>
#include<linux/kernel.h>


#ifndef PRINTK
#define PRINTK
#endif

const char *DEVICE_NAME ="Abhi_usb";
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Abhishek");
MODULE_DESCRIPTION("USB_DRIVER");

static int pen_probe(struct usb_interface *interface, const struct usb_device_id *id);

static void pen_disconnect(struct usb_interface *interface);

static struct usb_device_id pen_table[] =
{
        {USB_DEVICE(0x0781,0x5567)},
        {}
};
MODULE_DEVICE_TABLE(usb,pen_table);

int usb_register_driver(struct usb_driver *, struct module *,
                               const char *);
void usb_deregister(struct usb_driver *);
static struct usb_driver pen_driver=
{
        .name="Abhishek_usb_driver",
        .id_table = pen_table,
        .probe=pen_probe,
        .disconnect=pen_disconnect
};

PROGRAM:

 #include"header.h"


static int pen_probe(struct usb_interface *interface, const struct usb_device_id *id)
{

        printk(KERN_INFO "Abhishek Driver:Pen drive (%04X:%04X) plugged\n", id->idVendor, id->idProduct);

    return 0;
}

static void pen_disconnect(struct usb_interface *interface)
{
    printk(KERN_INFO "Abhishek Driver:Pen drive removed\n");
}


static int usb_initialisation(void)
{
        int no;
        #ifdef PRINTK
        printk(KERN_INFO"Begin:%s",__func__);
        #endif
        no=usb_register_driver(&pen_driver,THIS_MODULE, DEVICE_NAME);
        #ifdef PRINTK
        printk(KERN_INFO"usb_register:%d",no);
        printk(KERN_INFO"End:%s",__func__);
        #endif
return 0;
}

static void usb_cleanup(void)
{
        #ifdef PRINTK
        printk(KERN_INFO"Begin:%s",__func__);
        #endif
        usb_deregister(&pen_driver);
        #ifdef PRINTK
        printk(KERN_INFO"End:%s",__func__);
        #endif
}

module_init(usb_initialisation);
module_exit(usb_cleanup);

http://www.linuxforu.com/2011/10/usb-drivers-in-linux-1/

Usb device driver

IEEE_1284

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:

1. Write the data to the data register
2. Program reads the status register to check that the printer is not BUSY
3. If not BUSY, then Write to the Control Register to assert the STROBE line
4. 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:

1. Host signals ability to take data by asserting HostBusy low
2. Peripheral responds by placing first nibble on status lines
3. Peripheral signals valid nibble by asserting PtrClk low
4. Host sets HostBusy high to indicate that it has received the nibble and is not yet ready for another nibble.
5. Peripheral sets PtrClk high to acknowledge host
6. 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:

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 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:

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 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:

1. Data cycles

1. 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:

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 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:

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