CA2075774C - Bidirectional parallel protocol - Google Patents
Bidirectional parallel protocol Download PDFInfo
- Publication number
- CA2075774C CA2075774C CA002075774A CA2075774A CA2075774C CA 2075774 C CA2075774 C CA 2075774C CA 002075774 A CA002075774 A CA 002075774A CA 2075774 A CA2075774 A CA 2075774A CA 2075774 C CA2075774 C CA 2075774C
- Authority
- CA
- Canada
- Prior art keywords
- printer
- data
- host computer
- signal
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000002457 bidirectional effect Effects 0.000 title description 11
- 238000012546 transfer Methods 0.000 claims abstract description 50
- 230000007175 bidirectional communication Effects 0.000 claims abstract description 11
- 230000006854 communication Effects 0.000 claims description 42
- 238000004891 communication Methods 0.000 claims description 42
- 238000000034 method Methods 0.000 claims description 30
- 230000004044 response Effects 0.000 claims description 3
- 230000000977 initiatory effect Effects 0.000 claims description 2
- 239000000872 buffer Substances 0.000 description 11
- 239000012634 fragment Substances 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 101150091027 ale1 gene Proteins 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 230000007812 deficiency Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 101100070661 Caenorhabditis elegans hint-1 gene Proteins 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4265—Bus transfer protocol, e.g. handshake; Synchronisation on a point to point bus
- G06F13/4269—Bus transfer protocol, e.g. handshake; Synchronisation on a point to point bus using a handshaking protocol, e.g. Centronics connection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4204—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus
- G06F13/4221—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being an input/output bus, e.g. ISA bus, EISA bus, PCI bus, SCSI bus
- G06F13/4226—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being an input/output bus, e.g. ISA bus, EISA bus, PCI bus, SCSI bus with asynchronous protocol
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/12—Digital output to print unit, e.g. line printer, chain printer
- G06F3/1201—Dedicated interfaces to print systems
- G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
- G06F3/1211—Improving printing performance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/12—Digital output to print unit, e.g. line printer, chain printer
- G06F3/1201—Dedicated interfaces to print systems
- G06F3/1223—Dedicated interfaces to print systems specifically adapted to use a particular technique
- G06F3/1236—Connection management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/12—Digital output to print unit, e.g. line printer, chain printer
- G06F3/1201—Dedicated interfaces to print systems
- G06F3/1278—Dedicated interfaces to print systems specifically adapted to adopt a particular infrastructure
- G06F3/1284—Local printer device
Abstract
A protocol provides bidirectional communication capability between a host computer and a printer over a parallel interface, the host computer and the printer having a forward channel therebetween for the transfer of signals from the host computer to the printer. The protocol includes conventions for turning the forward channel around so as to establish a reverse channel to allow transfer of data from the printer to the host computer, conventions for controlling the transfer of data from the printer to the host computer over the reverse channel, and conventions for turning the reverse channel back around so as to re-establish the forward channel.
Description
BIDIRBCTIONAL PARALLEL BROTOCOL
FIELD OF THE INVENTION
The present invention relates to protocols and, more particularly, to protocols that enable bidirectional co~nunication through a parallel interface.
DESCRIPTION OF RELATED ART
Ports are well known to those skilled in the electronic arts as places of access to a device or network where energy may be supplied or withdrawn or where the device or network variables may be observed or measured. Ports may be classified into one of two categories:
serial, or parallel. As may be expected, serial ports involve time sequential processing or handling, and parallel ports involve simultaneous processing or handling.
Within the microprocessor arts the term "ports" encompasses gates" or openings for data to pass from the outside world to the microprocessor system, or vice versa. Microprocessors include both serial and parallel ports. Historically, the serial port has been widely recognized to be useful in communicating with modems, WRNS and the like, and a large variety of software has been developed that supports serial communication. Parallel ports, on the other hand, have traditionally been used only for relatively mundane tasks such as printing and plotting, primarily because they have been perceived as being unidirectional only.
Recently it has begun to be appreciated among those skilled in the art that a standard parallel port is bidirectional, that is, you can input or output on as many as twelve lines simultaneously. A serial card, on the other hand, can only input or output on a single line, one bit at a time. Comparing operation of the two reveals the relative power of the parallel port : it can output a byte and a half in the time it takes a serial port to determine whether it is time to cause a singular transaction.
.....
FIELD OF THE INVENTION
The present invention relates to protocols and, more particularly, to protocols that enable bidirectional co~nunication through a parallel interface.
DESCRIPTION OF RELATED ART
Ports are well known to those skilled in the electronic arts as places of access to a device or network where energy may be supplied or withdrawn or where the device or network variables may be observed or measured. Ports may be classified into one of two categories:
serial, or parallel. As may be expected, serial ports involve time sequential processing or handling, and parallel ports involve simultaneous processing or handling.
Within the microprocessor arts the term "ports" encompasses gates" or openings for data to pass from the outside world to the microprocessor system, or vice versa. Microprocessors include both serial and parallel ports. Historically, the serial port has been widely recognized to be useful in communicating with modems, WRNS and the like, and a large variety of software has been developed that supports serial communication. Parallel ports, on the other hand, have traditionally been used only for relatively mundane tasks such as printing and plotting, primarily because they have been perceived as being unidirectional only.
Recently it has begun to be appreciated among those skilled in the art that a standard parallel port is bidirectional, that is, you can input or output on as many as twelve lines simultaneously. A serial card, on the other hand, can only input or output on a single line, one bit at a time. Comparing operation of the two reveals the relative power of the parallel port : it can output a byte and a half in the time it takes a serial port to determine whether it is time to cause a singular transaction.
.....
Also very recently it has begun to be appreciated by those skilled in the art that there are certain advantages to using a parallel port for the sort of communication normally associated with a serial port. A number of these advantages are expressed by Ross Greenburg in a article entitled "Adapting the Parallel Port for Bidirectional Communication", which article can be found beginning on page 107 of the September 1990 issue of the Microsoft Systems Journal. In that article Mr. Greenberg points out that communication does not always need to be performed in ASCII.
Examples of such occasions would be when the ON/OFF condition of a sensor is being read or when a wire to a relay is turned ON or OFF.
It is wholly unnecessary to use a serial port in such cases -- the real world can be very easily connected to a parallel port. Mr.
Greenberg also notes that because a parallel port is able to get multiple bits in or out simultaneously, it should be able to provide faster I/O than a serial port. Of course, special code and protocols, such as the protocol taught herein, are required to take full advantage of the capabilities of a parallel port.
As the present invention specifically deals with communication involving a printer, it is appropriate to consider communication with such printers as part of the related art. In order to fully exploit the capabilities of a printer, such as a PostScript printer, a host computer must be able to send queries and receive the corresponding replies. Of course, as previously mentioned, bidirectional communication, here between a host computer and a printer, can be provided by a serial interface. However, as only very recently recognized, bidirectional communication at much higher speeds may also be provided by a parallel interface. Those skilled in the art have not yet tapped this latter capability to provide users of host computer and printer systems the functionality of the serial interface without sacrificing the ease of installation and higher transfer speeds of the parallel interface. Accordingly, it is a shortcoming and deficiency of the prior art that no one has heretofore developed a viable protocol to allow bidirectional communication between a host computer and a printer over s parallel interface.
Examples of such occasions would be when the ON/OFF condition of a sensor is being read or when a wire to a relay is turned ON or OFF.
It is wholly unnecessary to use a serial port in such cases -- the real world can be very easily connected to a parallel port. Mr.
Greenberg also notes that because a parallel port is able to get multiple bits in or out simultaneously, it should be able to provide faster I/O than a serial port. Of course, special code and protocols, such as the protocol taught herein, are required to take full advantage of the capabilities of a parallel port.
As the present invention specifically deals with communication involving a printer, it is appropriate to consider communication with such printers as part of the related art. In order to fully exploit the capabilities of a printer, such as a PostScript printer, a host computer must be able to send queries and receive the corresponding replies. Of course, as previously mentioned, bidirectional communication, here between a host computer and a printer, can be provided by a serial interface. However, as only very recently recognized, bidirectional communication at much higher speeds may also be provided by a parallel interface. Those skilled in the art have not yet tapped this latter capability to provide users of host computer and printer systems the functionality of the serial interface without sacrificing the ease of installation and higher transfer speeds of the parallel interface. Accordingly, it is a shortcoming and deficiency of the prior art that no one has heretofore developed a viable protocol to allow bidirectional communication between a host computer and a printer over s parallel interface.
SUMMARY OF THE INVENTION
The present invention overcomes the shortcomings and deficiencies of the prior art by providing a protocol for providing bidirectional communication capability between a host computer and a printer over a parallel interface, the host computer and the printer having a forward channel therebetween for the transfer of signals from the host computer to the printer. The protocol includes means for turning the forward channel around so as to establish a reverse channel to allow transfer of data from the printer to the host computer, means for controlling the transfer of data from the printer to the host computer over the reverse channel, and means for turning the reverse channel back around so as to re-establish the forward channel.
In embodiments of the present invention the means for turning the forward channel around is activated by the host computer. In those same and also in other embodiments of the present invention the means for turning the reverse channel back around so as to re- establish the forward channel is activated by the host computer.
In certain embodiments of the present invention the forward channel includes status lines which are used to transfer data between the printer and the host computer during reverse channel operation.
Further according to the teachings of the present invention the forward channel may be an input/output control channel which may be used to transfer control and status information between the printer and the host computer during reverse channel operation.
In embodiments of the present invention the means for turning the forward channel around is a means for the host computer to raise a *SLCTin signal and a means for the printer to lower a SLOT signal.
Still further according to the teachings of the present invention the means for controlling transfer of data may be a means for the host computer to request a packet of data, a means for the printer to indicate a packet of data is on the status lines, and a means for the host computer to read the packet of data from the status lines . In such embodiments of the present invention the packet of data may be a nibble of data, the means for the host computer to request a nibble of data may be a *STROBE signal, and Zp7 577 4 the means for the printer to indicate a nibble of data is on the status lines may be a SLCT signal. In such embodiments a low nibble of data may be requested via a lowered *STROBE signal and indicated to be transmitted via a raised SLCT signal; further, a high nibble of data may be requested via a raised *STROBE signal and indicated to be transmitted via a lowered SLCT signal.
Embodiments of the present invention may also include means for the printer to indicate to the host computer how many bytes of data are susceptible to be transmitted from the printer to the host computer. This means may be designed to act in response to the *SLCTin signal being raised and prior to the SLCT signal being lowered.
The present invention also overcomes the shortcomings and deficiencies of the prior art by providing a method for providing bidirectional communication capability between a host computer and a printer over a parallel interface, the host computer and the printer having a forward channel therebetween for the transfer of signals from the host computer to the printer. The method provided by the present invention includes the steps of turning the forward channel around so as to establish a reverse channel to allow transfer of data from the printer to the host computer over the reverse channel, and turning the reverse channel back around so as to reestablish the forward channel.
In embodiments of the method of the present invention either or both of the channel turning steps may be activated by the host computer.
According to the teachings of the present invention, the forward channel may include status lines which may be used to transfer data between the printer and the host computer during reverse channel operation. Further according to the teachings of the present invention, the forward channel may be an input/output control channel which may be used to transfer control and status information between the printer and the host computer during reverse channel operation.
In embodiments of the method of the present invention the step of turning the forward channel around may include the step of the host computer raising a *SLCTin signal and the step of the printer lowering a SLOT signal.
Still further according to the teachings of the present invention the step of controlling transfer of data may include the 5 step of the host computer requesting a packet of data, the step of the printer indicating a packet of data is on status lines, and the step of the host computer reading the packet of data from the status lines. In such embodiments of the method of the present invention the packet of data may be a nibble of data. Further, in such embodiments of the method of the present invention the step of the host computer requesting a nibble of data may involve a *STROBE
signal. Still further, in such embodiments of the method of the present invention the step of the printer indicating a nibble of data is on status lines may involve a SLCT signal. In embodiments as described above, a "low" nibble of data may be requested via a lowered *STROBE signal and indicated to be transmitted via a raised SLCT signal and, further, a "high" nibble of data may be requested via a raised *STROBE signal and indicated to be transmitted via a lowered SLCT signal.
Embodiments of the present invention may also include the step of the printer indicating to the host computer how many bytes of data are susceptible to be transmitted from the printer to the host computer. In such embodiments of the method of the present invention, this step may occur in response to the *SLCTin signal being raised and prior to the SLCT signal being lowered.
Accordingly, it is an object of the present invention to provide a bidirectional parallel protocol.
Another object of the present invention is to provide a protocol that can use existing PC parallel port hardware and cables.
Yet another object of the present invention is to provide a protocol having a host computer and a printer portion, which portions do not disrupt unilateral transmission when a protocol-equipped host computer or printer is connected to a non-protocol-equipped printer or host computer.
Still yet another object of the present invention is to provide a protocol that is transparent to ill-behaved software that drives that parallel port directly.
A further object of the present invention is to provide a protocol wherein the host computer can poll the printer quickly and efficiently to see if there is any data to be read.
Another object of the present invention is to provide a protocol that does not impose real-time constraints on the host computer.
Still yet another object of the present invention is to provide a robust, expandable protocol.
In accordance with the present invention, there is provided a method of providing a reverse channel communication capability between a computer and a printer over a parallel interface, said method comprising the steps of: a) providing, by said computer to said printer, a communication mode signal, said communication mode signal is for placing said printer in a communication mode; b) providing, by said computer to said printer, a first signal indicating said communication mode signal is ready to be read; c) providing, by said printer to said computer, a second signal indicating that said printer will provide a computer data in the communication mode indicated in step a); d) providing, by said printer to said computer, a ready signal indicating that said second signal is ready to be read; e) providing, by said computer to said printer, a third signal indicating that said computer is ready to receive a first data from said printer; f) providing, by _. 2075774 said printer to said computer, said first data; g) providing, by said printer to said computer; a fourth signal indicating that said first data is ready to be read; h) providing, by said computer to said printer, a fifth signal indicating that said computer is ready to receive more data; i) providing, by said printer to said computer, a second data; j) providing, by said printer to said computer, a sixth signal indicating that said second data is ready to be read.
In accordance with the present invention, there is further provided a method of turning around a parallel channel between a computer and a printer comprising the steps of: a) indicating, by said computer to said printer, a mode of data transfer that is acceptable to said computer, said mode comprises a data format mode; b) indicating, by said printer to said computer, that an acceptable mode of data transfer will be used by said printer, c) indicating, by said computer to said printer, that data will be accepted on a turned around status line; d) providing, by said printer to said computer on said turned around status line, data; e) turning around said turned around status line so that status signal can be sent from said computer to said printer.
In accordance with the present invention, there is further provided a protocol providing bidirectional communication capability between a host computer and a printer over a parallel interface, said host computer and said printer having a forward channel therebetween for transfer of signals from said host computer to said printer, wherein said forward channel comprises status lines and wherein said status lines 6a are used to transfer data from said printer to said host computer during a reverse channel operation, said protocol comprising: means for turning said forward channel around so as to establish a reverse channel to allow transfer of data from said printer to said host computer, said means for turning said forward channel around includes: means for determining number of bytes to be read from said printer by said host computer; means for opening a dialogue; and means for calculating a maximum number of bytes to be transmitted from said printer to said host computer, said maximum number represented by a loop control hint signal sent by said printer to said host computer via said reverse channel; means for controlling said transfer of data from said printer to said host computer over said reverse channel; and means for turning said reverse channel back around so as to reestablish said forward channel after said host computer reads the number of bytes determined by said determining means.
In accordance with the present invention, there is further provided a method for providing bidirectional communication capability between a host computer and a printer over a parallel interface, said host computer and said printer having a forward channel therebetween for transfer of signals from said host computer to said printer, wherein said forward channel comprises status lines and wherein said status lines are used to transfer data from said printer to said host computer during a reverse channel operation, said method comprising the steps of: turning said forward channel around so as to establish a reverse channel to allow transfer of data 6b from said printer to said host computer, said step of turning said forward channel around includes the steps of: determining number of bytes that the host computer wants to read from the printer; sending a dialogue initiating signal from said host computer to said printer for opening a dialogue, and sending a loop control hint signal from said printer to said host computer, said loop control hint signal indicating an upper limit on a number of bytes that can be sent during said opened dialogue; controlling said transfer of data from said printer to said host computer over said reverse channel in said dialogue; and turning said reverse channel back around so as to reestablish said forward channel after the host computer reads the number of bytes that is determined.
BRIEF DESCRIPTION OF THE DRAWINGS
Other objects, advantages and novel features of the present invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings wherein:
FIG. 1 is a block diagram of a prior art parallel printer adapter;
FIG. 2 is a diagram showing details of a parallel port interface; and FIG. 3 is a diagram illustrating signal transmission over time in a protocol according to the teachings of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
Referring now to the drawings wherein like or similar elements are designated with identical reference 6c numerals throughout the several views, and more particularly to FIG. 1, shown therein is a heretofore developed parallel printer adapter. This FIG. 1 clearly shows a number of details significant to the structure and practice of the present invention.
First, with special reference to FIG.1 it may be noted that a parallel port is one of the simplest components of a computer. There are four distinct parts of such a port:
an address decoding portion, a write logic portion, a physical input/output portion; and an input/output to bus transfer portion. In general, operation of the parallel port is as follows.
First, the address decoding portion 2 is activated when a specified address is on a bus 4. The write logic portion 6 takes the 6d data on the bus 4 and gives it to the physical input/output portion 8. The input/output to bus transfer portion makes the data from the input/output available to the bus when it is requested.
Four addresses enable the parallel port, together with the _ _ _ IOR or IOW bus lines 10, 12. The IOR and IOW bus lines 12, 14 indicate that a port input or output operation is taking place on the bus. Because normal memory reads and writes do not set the pins associated with these lines, the overall card ignores these types of operations.
The various combinations of wires allow for writing and reading the status and data lines on the DB-25 connector 14.
Referring now to FIG. 2, there is shown in block form the hardware and cable of a PC parallel port interface. This interface msy be seen to have three registers, all of which are directly manipulated by software. These three registers are a data register 24, a status register 26, and a control register 28. Each of these three registers 24, 26, 28 is discussed in an individual paragraph immediately below.
The data register 24 is an 8-bit read/write latch for output only. The latch can be read to determine the data most recently written to it. Although some schemes have heretofore been proposed for tricking this latch into being used for input, these schemes have been unreliable at best and hardware damaging at worst.
The status register 26 is not actually a register, but rather is an unlatched port for input. The term "status register" is used herein to prevent confusion over the term "port". To "read the status register" should be understood herein to mean to take a real-time sample of the status lines.
The control register 28 is similar to the data register 24 in that it is also a read/write latch for output only. The three unused bits in the upper part of the register 28 are traditionally read as ones, but should be written back as zeros. This prevents malfunction with certain newer implementations that use bit 5. Bit 4 is not actually a printer control line; it is used to enable/disable the interrupt.
s The polarity of the status end control lines can be a major source of confusion. To make matters worse, some of the lines are inverted at the interface. A good naming convention can save an implementor a lot of time and trouble.
An active-low signal is a condition indicated by low voltage rather than high voltage. We say that the *ACK signal is active low, because a low voltage on that line indicates an acknowledgement from the printer. The asterisk (*) is part of the name, and serves as a reminder that the signal is active-low.
The PC parallel port interface inverts the BUSY signal and makes the result available as bit 7 of the status register 26. We will call this bit -BUSY. This tilde (-) indicates that the signal is inverted with respect to the cable. The -*STROBE, -*AUTOLF, and -*SLCTi.n signals are both active low and inverted with respect to the cable.
It should be appreciated that some signals can be referenced in more than one way. For example, to say that *SLCTin is lowered is the same as saying that ~*SLCTin is raised. Discussions of the protocol usually reference the signal as it appears on the cable, rather than as it appears on the PC interface.
Another potential source of confusion is the cable itself, simply because in the example shown in FIG. 2 it has a DB-25 male connector on the PC end, and a Centronics 36-pin male connector on the printer end. For example, reference to a "pin k" is ambiguous because the connectors are not one-to-one. FIG. 2 is, therefore, a programmer's quick-reference guide to a PC parallel port. It shows the cable wiring with pin numbers for both connectors, the signal names associated with the wires, the registers accessible by the PC, and the inverters associated with the interface.
With the above background, a protocol according to the teachings of the present invention may now be discussed in detail.
For reasons that will become apparent, this protocol may be called a "nibble-mode reverse channel protocol".
Conventionally, the transfer of data from the host to the printer is accomplished via the forward channel. The bidirectional protocol according to the teachings of the present invention establishes a reverse channel for transferring data from the printer to the host.
Transfers on the forward channel occur one byte at a time;
each byte is transferred independently. The reverse channel is dialogue-oriented; any number of bytes (between 0 and 16384) can be transferred in a single dialogue.
The dialogue has an opening sequence and a closing sequence for the purpose of changing the channel direction, or "turning the channel around". This is necessary because the two channels share certain signals whose meaning depends on which channel is active.
There are not enough signals in the cable to allow both channels to be active simultaneously. FIG. 3 illustrates the reverse channel protocol.
Referring now to FIG. 3, it may be seen that the host initiates the dialogue by writing a hex Olh byte to the data lines, and then raising (de-activating) the *SLCTin signal. The Olh byte represents a communication mode number. Communication mode numbers will be discussed in greater detail hereinbelow.
The printer responds to the foregoing by placing a nibble of data, the loop control hint, on the status lines and then by lowering SLCT. When the host sees SLCT drop, it reads the status lines to get the loop control hint. This also is discussed further below. The dialogue is now open.
The next set of operations in a protocol according to the teachings of the present invention may be designated "data transfer loop operations". In this loop the host lowers *STROBE to request the low nibble of a byte. When SLCT goes high, the host can read the nibble from the status lines. In the example shown in FIG. 3, -BUSY is bit 3, *ACK is bit 2, PE is bit 1, and *ERR is bit 0.
Next, the host raises *STROBE to request the high nibble of the byte. When SLCT goes low, the host can read the nibble from the status lines. In the example shown in FIG. 3, -BUSY is bit 7, *ACK
is bit 6, PE is bit 5, and *ERR is bit 4.
With respect to the loop control hint, which has been mentioned briefly heretofore, during the opening sequence the host reads the loop control hint from the status lines (in this example, ~_ 2075774 -BUSY is bit 3, *ACK is bit 2, PE is bit 1, and *ERR is bit 0). The loop control hint is a four-bit unsigned integer that establishes an upper limit on the number of bytes that can be transferred in the newly-opened dialogue.
5 If the loop control hint is Oh, the printer has then no data to send, and the host is obligated to close the dialogue without attempting to transfer any data.
If the loop cont rol hint is not then the loop control Oh, limit is computed as raised to the (loop control hint 2 power -1).
10 The following table merates all possiblecombinations:
enu Loop control hint Loop contro l limit (bytes) Oh 0 lh 1 2h 2 3h 4 4h 8 5h 16 6h 32 7h 64 8h 128 9h 256 Ah 512 Bh 1024 (1KB) Ch 2048 (2KB) Dh 4096 (4KB) Eh 8192 (8KB) Fh 16384(16KB) The host is not obligated to read all of the available bytes.
The host may read any number of bytes from 0 to the loop control limit. If the host reads up to the limit, it must close the dialogue. If the host still wants more data, it may open another dialogue immediately. There may or may not be more data available.
As an example, suppose the host wants to read 80 bytes of data. Upon opening a dialogue, the host receives a loop control hint of 7h, indicating that it may read no more than 64 bytes. The host reads the 64 bytes, closes the dialogue, and then opens another dialogue. Suppose this time the loop control hint is 6h, indicating that 32 bytes are available. The host then reads 16 bytes (for a total of 80) and closes the dialogue.
The next, and bottommost, set of operations shown in FIG. 3 relate to closing the dialogue. It is the responsibility of the host to close the dialogue when it has read bytes up to the loop control limit, or when it has all the bytes it wants, whichever comes first.
The host closes the dialogue by lowering ~SLCTin and then waiting for SLCT to go high. The host must wait for SLCT to indicate that the status lines now carry status information and not data.
As an aside with respect to the example nibble-mode reverse channel protocol being presented herein, it should be noted that although most printers lower SLCT whenever they go off-line for any reason, if a printer is to support the example protocol presented herein, it must not exhibit this behavior. The SLCT signal must be completely dedicated to the protocol, and should not be used for anything else. When the printer goes off-line, it should raise BUSY
to prevent the host from sending data.
Another topic relating to the present invention that is appropriately discussed herein is protocol timeout errors. There are many places in the protocol where the host must wait indefinitely until a signal transition occurs. In these loops, a timer can be set to prevent hanging. The recommended timeout period is 2 seconds for each loop that is waiting on a signal transition from the printer. This should give the printer plenty of time to respond, yet allow the user to be notified promptly if the printer does not support the protocol at all.
If a wait loop on the host side times out while the dialogue is open, the host should attempt to close the dialogue. If a timeout occurs while closing the dialogue, then the host could reset the printer (using the *INIT pulse) to abort the dialogue. Upon receiving this signal, the printer may or may not take more drastic action, such as cancelling the current job. The host should always make sure that *SLCTin is low (active) before sending the *INIT
pulse; if *SLCTin is high after the ~INIT pulse, the printer will think that the host is trying to open a new dialogue. The host should never try to send data while a reverse channel dialogue is still open.
Now, with respect to host software, some 80x86 assembly-code fragments are presented hereinbelow to assist an implementor of the driver software on the host side. These code fragments are not included as part of the protocol specification, but are merely intended to provide efficient, non-obvious solutions in places where obvious solutions could be very inefficient.
A first fragment herein presented relates to reading the low nibble. When the PC reads the status register to get the low nibble of data, the bits are in the wrong order. This code fragment orders the bits correctly.
;Input: AL has contents of status register. The data bits are in the wrong order. Bit b3 of the data is in bit 7 of the register, b2 is in bit 6, bl is in bit 5, and b0 ; is in bit 3. Bit 4 will always have a 1 in it, because when the low nibble was read, the SLCT line s 2075774 was high.
So AL has: [ b3 b2 bl 1 b0 x x x ]
;Output: AH has the low nibble with the bits in the proper ; order, and the upper nibble is zeroed out.
So AH will have: [ 0 0 0 0 b3 b2 bl b0 ]
sub AL, 08h ; Move b0 into bit 4 (Recall that bit 4 was 1) We now have ( b3 b2 bl b0 x x x x ]
shr AL, 1 ;
shr AL, 1 shr AL, 1 shr AL, 1 mov AH, AL ; Save in AH for later use...
A second fragment herein presented relates to reading the high nibble.
When the PC reads the high nibble from the status register, the bits are again in the wrong order. This code fragment orders them prop erly and combines the high nibble with the low nibble.
;Input: AL has contents of status register. The data bits are in the wrong order. Bit b7 of the data is in bit 7 of the register, b6 is in bit 6, b5 is in bit 5, and b4 ; is in bit 3. Bit 4 is always 0, because when the high nibble was read, the SLCT line was low.
So AL has: [ b7 b6 b5 0 b4 x x x ]
AH should have the low nibble: [ 0 0 0 0 b3 b2 bl b0 ]
;
;Output: AL will have the byte with all the bits properly ordered.
add AL, 08h; Move b4 into bit 4. (Recall that bit 4 was 0) ; We now have [ b7 b6 b5 b4 x x x x ]
and AL, 11110000b ; Mask out junk bits or AL, AH ; Combine nibbles to form a complete byte.
This third code fragment computes the number of bytes to be read by using the loop control hint and the number of bytes the host wants.
;
;Input: BX has maximum number of bytes that the host wants to read. (Limit imposed by the host).
' 2075774 AL has the value of the status register at the time the loop control hint was transmitted. Bit 4 will be 0 because SLCT was low. [ b3 b2 bl 0 b0 x x x ]
;Output: CX will have the number of bytes that should be transferred before closing this dialogue.
BX will have the number of bytes that the host still needs after the dialogue is closed. If BX is nonzero, ; the host should open another dialogue and try to read more bytes.
add AL, 08h ; We now have ( b3 b2 bl b0 x x x x]
mov CL, 4 shr AL, CL ; We now have [ 0 0 0 0 b3 b2 bl b0 ]
AL has the loop control hint dec AL ; Any data available to read?
note that CX is NOT 0 here. Loop logic needs this ; info.
js close dialogue; CLOSE DIALOGUE IF NO DATA AVAILABLE
mov CL, AL ; Use loop control hint as shift count mov AX, 1 ; Get a bit to compute 2" (CL) shl AX, CL ; AX = 2" (loop control hint - 1) ; AX has the loop control limit Compute minimum of BX and loop control limit (AX) sub AX, BX ; CY if BX J AX; AX has delta sbb CX, CX ; 0 if no CY, all 1's if CY
and CX, AX ; 0 or delta add CX, BX ; CX has the minimum sub BX, CX ; BX >= 0 CX has count for transfer loop. Use the loop instruction.
; BX has number of bytes the host lacks after the loop.
The host will want to use two nested loops, one for the actual data transfer, and another to use as many dialogues as needed to get enough data to satisfy the ; host, or until a dialogue says there is no more data.
The loop logic goes something like this:
read_loop:
[ Code to transfer a byte goes here. ]
[ Preserve CX and BX. ]
loop read_loop Note that CX is 0 here...
; Host is obligated to close the dialogue now.
close dialogue:
[ Code to close the dialogue goes here. ]
[ Preserve CX and BX. ]
If BX > 0, open another dialogue and read more data.
or BX, BX
jz xfer done ; If BX is 0, host is satisfied.
5 ; BX has number of bytes host still lacks CX is nonzero if there is no more data available.
If CX is 0, there might be more data.
jcxz open dialogue 10 xfer_done:
If BX is 0, the desired number of bytes was read.
If BX > 0, (N - BX) bytes were read, if N is the number of bytes that were desired.
15 To this point, only a so-called nibble-mode reverse channel protocol has been discussed. The nibble-mode reverse channel protocol, as has heretofore been indicated, is just one of a set of protocols designed for bidirectional parallel communications. Other such protocols are also disclosed in this document.
With respect to the protocol heretofore discussed, the following four communication mode numbers have been assigned:
Mode Number Protocol 0 Version ID protocol 1 Nibble-mode reverse channel protocol 2 IOCTL write mode 3 IOCTL read using nibble-mode rev, ch.
protocol The remaining mode numbers 4-255 can be considered to be reserved for future use.
With respect to opening and closing a communication mode, each communication mode begins and ends in the same manner. To open a communication mode, the host puts the communication mode number on the data lines and then raises the *SLCTin signal. The printer acknowledges the mode by lowering the SLCT signal. All communications proceeding from this point must be according to the specified protocol. If the status lines are to be changed from their standard meanings, this change will happen before the SLCT
signal is lowered. This allows the meanings of the status lines to be multiplexed based on the communication mode.
To close a communications mode, the host lowers *SLCTiri and waits for the printer to raise SLCT to indicate that it is closed.
The meanings of the status lines are restored after the host lowers *SLCTin and before the printer raises SLCT. The host must wait for the SLCT to be raised before proceeding to prevent possible race conditions.
Another protocol according to the teachings of the present invention, which is herein designated a "version ID protocol", will now be described.
Since the bidirectional parallel protocol is expandable, it helps if the host can determine what version of the protocol is being utilized by the printer, or if the printer doesn't support the protocol at all. The version ID protocol provides this functionality.
The version ID protocol works in exactly the same manner as the nibble-mode reverse channel parallel protocol except for a few very important differences. First of all, the communication mode number is zero (0) instead of one (1). So the host must put a hex OOh on the data lines to begin.
The data read back is constant. The loop control hint will always be 2h, so the loop control limit will always be 2. There will always be exactly two bytes to read. The first byte will be hex SAh. The second byte will be the version number of the protocol.
The printer will be required to implement the protocol specified by the version number given in its entirety. Partial implementations will be non-conforming.
To clarify a point that might otherwise be ambiguous: the printer may return 1 for the version number and implement only communication modes 0 and 1, where mode 0 is the version ID protocol specified in a version of a document describing the protocol, and mode 1 is the reverse channel protocol specified in that same version of the document, so upward compatibility is maintained. The version 1 distinction is allowed for future printers that do not have an IOCTL channel.
It is now appropriate to discuss the IOCTL channel in some detail, beginning with a discussion of its purpose.
Often is it desirable or even necessary for host system software to interrogate the printer for detailed status information, or to send configuration commands. But the data stream to the printer (often from an unrelated application) cannot be disrupted by injecting new commands into it asynchronously. Likewise, it is not desirable for host system software to read data from the printer that was intended for an application in attempt to get status information. To complicate this matter, the printer's data buffer is likely to be full when the system software needs to send a status request.
The IOCTL (I/0 control) channel provides a separate logical channel for communicating with the printer. This channel is bidirectional just like the data channel, so that information may be passed both ways. Separate buffers are maintained for this channel so that control and status information can be transferred even when data buffers are saturated.
The format of the information transferred on the IOCTL channel is defined by the printer. Basically, the IOCTL channel is used to transfer control and status information. It is not typically used for sending page descriptions or other data. The data channel is more appropriately used for this purpose.
To read from the IOCTL channel, the host uses the exact same protocol used for the nibble-mode reverse channel protocol, except that the communication mode number is 3. So to open the IOCTL
channel for reading, the host first puts a hex 03h on the data lines and raises *SLCTin, and the dialogue continues just as in communication mode 1.
The information read on this channel is logically separate from the data read using communication mode 1. If there is no data to be read from the reverse (data) channel, that does not imply anything about whether there is information to be read from the IOCTL channel.
To Write to the IOCTL channel, the host must use communication mode 2. To begin the transfer, the host writes a hex 02h on the data lines and then raises *SLCTin. The printer will then put the status of the IOCTL channel on the status lines, and lower SLCT.
When the host sees SLCT go low, it knows that the status lines now reflect the status of the IOCTL channel, not the data channel.
Thus, even if the data channel were busy, the IOCTL channel may not be.
Once communication mode 2 is opened, information is transferred from the host to the printer in the exact same fashion that data is transferred on the data channel, using the data lines, BUSY, *STROBE, *ACK, and the other status lines.
After the control information is transferred to the printer, the host must close the communication mode. The host lowers *SLCTin and waits for SLCT to go high. The printer will restore the status lines to reflect the status of the data channel, and then raise SLCT. The closing is complete when the host sees SLCT go high.
While writing data to the IOCTL channel, often the host will have to wait on BUSY, as is the standard convention. This wait is not constrained by the same 2 second timeout that was discussed above for the nibble-mode reverse channel protocol. The timeout value here is left to the discretion of the host. If the host nets impatient waiting on the BUSY signal and decides to time out, the host should first attempt to close the communication mode in the normal manner.
Moving to a new topic, the standard BIOS INT 17h support for parallel printer communications is very limited in functionality.
The following extensions are proposed to allow software to use the new protocols without re-implementing them. These extensions are proposed as examples only, to facilitate practice of the present invention but not to limit it.
The "identify version" function provides a way to tell that the following extended functions are available for use.
Input:
AX = 80A5h On return:
AX is SASAh BX will have the version number The version number returned will correspond to the version number of an appropriate document describing the protocol. The version number is in the format "H.L." where the "H" portion is returned in BH and the "L" portion is returned in BL. The revision history at the 10 beginning of the appropriate document should provide additional information on version numbers.
Ideally, all future changes to BIOS extensions will be upwardly compatible.
The "write data" function sends a buffer of data to the 15 printer.
Input:
AX = S100h DX = Printer port number (0 to 2 for LPT1 to LPT3) CX = Number of bytes to write 20 DS:SI --> buffer of data On return:
CX contains the number of bytes sent.
Result code is in AX.
If AX is 0: Successfully sent.
-1: Invalid printer port number or port not installed.
-2: The pointer specified is NULL.
-3: Timeout: reason unknown.
-4: Timeout: the printer is probably not connected.
-5: Timeout: the printer is connected but probably not turned on.
The "IOCTL write" function sends a buffer of I/0 control information to the printer. The data is written to the IOCTL
channel instead of the data channel.
Input:
x.2075774 AX = 8101h DX = Printer port number (0 to 2 for LPT1 to LPT3) CX = Number of bytes to write DS:SI --J buffer to send On return:
CX contains the number of bytes sent.
Result code is in AX.
If AX is 0: Successfully sent.
-1: Invalid printer port number or port not installed.
-2: The pointer specified is NULL.
-3: Timeout: reasons unknown.
-4: Timeout: the printer is probably not connected.
-5: Timeout: the printer is connected but probably not turned on.
The "read data" function reads a buffer of data from the printer.
Input:
AX = 8200h DX = Printer port number (0 to 2 for LPT1 to LPT3) CX = Maximum number of bytes to read ES: DI --> buffer area to store incoming data.
On return:
CX contains the number of bytes actually read.
Result code is in AX.
If AX is 0: Successfully sent.
-1: Invalid printer port number or port not installed.
-2: The pointer specified is NULL.
-3: Timeout: reason unknown.
-4: Timeout: the printer is probably not connected.
-5: Timeout: the printer is connected but probably not turned on.
-6: Timeout: printer (probably) does not support the bidirectional protocol.
The "IOCTL read" function reads a buffer of I/0 control information from the printer. The data is read from the I/0 control channel instead of the data channel.
Input:
AX = 8201h DX = Printer port number (0 to 2 for LPT1 to LPT3) CX = Maximum number of bytes to read ES: DI -- buffer area to store incoming data.
On return:
CX contains the number of bytes actually read.
Result code is in AX.
If AX is 0: Successfully sent.
-1: Invalid printer port number or port not installed.
-2: The pointer specified is NULL.
-3: Timeout: reason unknown.
-4: Timeout: the printer is probably not connected.
-5: Timeout: the printer is connected but probably not turned on.
-6: Timeout: printer (probably) does not support the bidirectional protocol.
As a last extension, with respect to read/set timeout value for writes:
Input:
AH = 83h AL = 0 to read, to set DX = Printer port number 2 for LPT1 to LPT3) (0 to BX = Timeout valuein secondsfor writes. 0 means infinite (no timeout).Default 0 (no timeout).
is CX = Timeout valuein secondsfor IOCTL writes. Default is 0 Note: a Ctrl-Break sequence from the operator causes a timeout even if the timeout value is set to 0.
Note 2: This timeout value does not affect reads from either channel.
Those skilled in the art should now appreciate that the present invention provides a bidirectional parallel protocol that is robust, expandable, and well-suited to operate between a host computer and an attached printer. The protocol according to the teachings of the present invention can use existing PC parallel port hardware and cables but is transparent to ill-behaved application software and the like. Still further, the protocol according to the w2075 774 teachings of the present invention allows for rapid polling while not imposing problematic real-time constraints.
Those skilled in the art will recognize that many modifications and variations besides those specifically mentioned may be made in the techniques described herein without departing substantially from the concept of the present invention.
Accordingly, within the scope of the appended claims, the present invention may be practiced otherwise than as specifically described herein.
The present invention overcomes the shortcomings and deficiencies of the prior art by providing a protocol for providing bidirectional communication capability between a host computer and a printer over a parallel interface, the host computer and the printer having a forward channel therebetween for the transfer of signals from the host computer to the printer. The protocol includes means for turning the forward channel around so as to establish a reverse channel to allow transfer of data from the printer to the host computer, means for controlling the transfer of data from the printer to the host computer over the reverse channel, and means for turning the reverse channel back around so as to re-establish the forward channel.
In embodiments of the present invention the means for turning the forward channel around is activated by the host computer. In those same and also in other embodiments of the present invention the means for turning the reverse channel back around so as to re- establish the forward channel is activated by the host computer.
In certain embodiments of the present invention the forward channel includes status lines which are used to transfer data between the printer and the host computer during reverse channel operation.
Further according to the teachings of the present invention the forward channel may be an input/output control channel which may be used to transfer control and status information between the printer and the host computer during reverse channel operation.
In embodiments of the present invention the means for turning the forward channel around is a means for the host computer to raise a *SLCTin signal and a means for the printer to lower a SLOT signal.
Still further according to the teachings of the present invention the means for controlling transfer of data may be a means for the host computer to request a packet of data, a means for the printer to indicate a packet of data is on the status lines, and a means for the host computer to read the packet of data from the status lines . In such embodiments of the present invention the packet of data may be a nibble of data, the means for the host computer to request a nibble of data may be a *STROBE signal, and Zp7 577 4 the means for the printer to indicate a nibble of data is on the status lines may be a SLCT signal. In such embodiments a low nibble of data may be requested via a lowered *STROBE signal and indicated to be transmitted via a raised SLCT signal; further, a high nibble of data may be requested via a raised *STROBE signal and indicated to be transmitted via a lowered SLCT signal.
Embodiments of the present invention may also include means for the printer to indicate to the host computer how many bytes of data are susceptible to be transmitted from the printer to the host computer. This means may be designed to act in response to the *SLCTin signal being raised and prior to the SLCT signal being lowered.
The present invention also overcomes the shortcomings and deficiencies of the prior art by providing a method for providing bidirectional communication capability between a host computer and a printer over a parallel interface, the host computer and the printer having a forward channel therebetween for the transfer of signals from the host computer to the printer. The method provided by the present invention includes the steps of turning the forward channel around so as to establish a reverse channel to allow transfer of data from the printer to the host computer over the reverse channel, and turning the reverse channel back around so as to reestablish the forward channel.
In embodiments of the method of the present invention either or both of the channel turning steps may be activated by the host computer.
According to the teachings of the present invention, the forward channel may include status lines which may be used to transfer data between the printer and the host computer during reverse channel operation. Further according to the teachings of the present invention, the forward channel may be an input/output control channel which may be used to transfer control and status information between the printer and the host computer during reverse channel operation.
In embodiments of the method of the present invention the step of turning the forward channel around may include the step of the host computer raising a *SLCTin signal and the step of the printer lowering a SLOT signal.
Still further according to the teachings of the present invention the step of controlling transfer of data may include the 5 step of the host computer requesting a packet of data, the step of the printer indicating a packet of data is on status lines, and the step of the host computer reading the packet of data from the status lines. In such embodiments of the method of the present invention the packet of data may be a nibble of data. Further, in such embodiments of the method of the present invention the step of the host computer requesting a nibble of data may involve a *STROBE
signal. Still further, in such embodiments of the method of the present invention the step of the printer indicating a nibble of data is on status lines may involve a SLCT signal. In embodiments as described above, a "low" nibble of data may be requested via a lowered *STROBE signal and indicated to be transmitted via a raised SLCT signal and, further, a "high" nibble of data may be requested via a raised *STROBE signal and indicated to be transmitted via a lowered SLCT signal.
Embodiments of the present invention may also include the step of the printer indicating to the host computer how many bytes of data are susceptible to be transmitted from the printer to the host computer. In such embodiments of the method of the present invention, this step may occur in response to the *SLCTin signal being raised and prior to the SLCT signal being lowered.
Accordingly, it is an object of the present invention to provide a bidirectional parallel protocol.
Another object of the present invention is to provide a protocol that can use existing PC parallel port hardware and cables.
Yet another object of the present invention is to provide a protocol having a host computer and a printer portion, which portions do not disrupt unilateral transmission when a protocol-equipped host computer or printer is connected to a non-protocol-equipped printer or host computer.
Still yet another object of the present invention is to provide a protocol that is transparent to ill-behaved software that drives that parallel port directly.
A further object of the present invention is to provide a protocol wherein the host computer can poll the printer quickly and efficiently to see if there is any data to be read.
Another object of the present invention is to provide a protocol that does not impose real-time constraints on the host computer.
Still yet another object of the present invention is to provide a robust, expandable protocol.
In accordance with the present invention, there is provided a method of providing a reverse channel communication capability between a computer and a printer over a parallel interface, said method comprising the steps of: a) providing, by said computer to said printer, a communication mode signal, said communication mode signal is for placing said printer in a communication mode; b) providing, by said computer to said printer, a first signal indicating said communication mode signal is ready to be read; c) providing, by said printer to said computer, a second signal indicating that said printer will provide a computer data in the communication mode indicated in step a); d) providing, by said printer to said computer, a ready signal indicating that said second signal is ready to be read; e) providing, by said computer to said printer, a third signal indicating that said computer is ready to receive a first data from said printer; f) providing, by _. 2075774 said printer to said computer, said first data; g) providing, by said printer to said computer; a fourth signal indicating that said first data is ready to be read; h) providing, by said computer to said printer, a fifth signal indicating that said computer is ready to receive more data; i) providing, by said printer to said computer, a second data; j) providing, by said printer to said computer, a sixth signal indicating that said second data is ready to be read.
In accordance with the present invention, there is further provided a method of turning around a parallel channel between a computer and a printer comprising the steps of: a) indicating, by said computer to said printer, a mode of data transfer that is acceptable to said computer, said mode comprises a data format mode; b) indicating, by said printer to said computer, that an acceptable mode of data transfer will be used by said printer, c) indicating, by said computer to said printer, that data will be accepted on a turned around status line; d) providing, by said printer to said computer on said turned around status line, data; e) turning around said turned around status line so that status signal can be sent from said computer to said printer.
In accordance with the present invention, there is further provided a protocol providing bidirectional communication capability between a host computer and a printer over a parallel interface, said host computer and said printer having a forward channel therebetween for transfer of signals from said host computer to said printer, wherein said forward channel comprises status lines and wherein said status lines 6a are used to transfer data from said printer to said host computer during a reverse channel operation, said protocol comprising: means for turning said forward channel around so as to establish a reverse channel to allow transfer of data from said printer to said host computer, said means for turning said forward channel around includes: means for determining number of bytes to be read from said printer by said host computer; means for opening a dialogue; and means for calculating a maximum number of bytes to be transmitted from said printer to said host computer, said maximum number represented by a loop control hint signal sent by said printer to said host computer via said reverse channel; means for controlling said transfer of data from said printer to said host computer over said reverse channel; and means for turning said reverse channel back around so as to reestablish said forward channel after said host computer reads the number of bytes determined by said determining means.
In accordance with the present invention, there is further provided a method for providing bidirectional communication capability between a host computer and a printer over a parallel interface, said host computer and said printer having a forward channel therebetween for transfer of signals from said host computer to said printer, wherein said forward channel comprises status lines and wherein said status lines are used to transfer data from said printer to said host computer during a reverse channel operation, said method comprising the steps of: turning said forward channel around so as to establish a reverse channel to allow transfer of data 6b from said printer to said host computer, said step of turning said forward channel around includes the steps of: determining number of bytes that the host computer wants to read from the printer; sending a dialogue initiating signal from said host computer to said printer for opening a dialogue, and sending a loop control hint signal from said printer to said host computer, said loop control hint signal indicating an upper limit on a number of bytes that can be sent during said opened dialogue; controlling said transfer of data from said printer to said host computer over said reverse channel in said dialogue; and turning said reverse channel back around so as to reestablish said forward channel after the host computer reads the number of bytes that is determined.
BRIEF DESCRIPTION OF THE DRAWINGS
Other objects, advantages and novel features of the present invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings wherein:
FIG. 1 is a block diagram of a prior art parallel printer adapter;
FIG. 2 is a diagram showing details of a parallel port interface; and FIG. 3 is a diagram illustrating signal transmission over time in a protocol according to the teachings of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
Referring now to the drawings wherein like or similar elements are designated with identical reference 6c numerals throughout the several views, and more particularly to FIG. 1, shown therein is a heretofore developed parallel printer adapter. This FIG. 1 clearly shows a number of details significant to the structure and practice of the present invention.
First, with special reference to FIG.1 it may be noted that a parallel port is one of the simplest components of a computer. There are four distinct parts of such a port:
an address decoding portion, a write logic portion, a physical input/output portion; and an input/output to bus transfer portion. In general, operation of the parallel port is as follows.
First, the address decoding portion 2 is activated when a specified address is on a bus 4. The write logic portion 6 takes the 6d data on the bus 4 and gives it to the physical input/output portion 8. The input/output to bus transfer portion makes the data from the input/output available to the bus when it is requested.
Four addresses enable the parallel port, together with the _ _ _ IOR or IOW bus lines 10, 12. The IOR and IOW bus lines 12, 14 indicate that a port input or output operation is taking place on the bus. Because normal memory reads and writes do not set the pins associated with these lines, the overall card ignores these types of operations.
The various combinations of wires allow for writing and reading the status and data lines on the DB-25 connector 14.
Referring now to FIG. 2, there is shown in block form the hardware and cable of a PC parallel port interface. This interface msy be seen to have three registers, all of which are directly manipulated by software. These three registers are a data register 24, a status register 26, and a control register 28. Each of these three registers 24, 26, 28 is discussed in an individual paragraph immediately below.
The data register 24 is an 8-bit read/write latch for output only. The latch can be read to determine the data most recently written to it. Although some schemes have heretofore been proposed for tricking this latch into being used for input, these schemes have been unreliable at best and hardware damaging at worst.
The status register 26 is not actually a register, but rather is an unlatched port for input. The term "status register" is used herein to prevent confusion over the term "port". To "read the status register" should be understood herein to mean to take a real-time sample of the status lines.
The control register 28 is similar to the data register 24 in that it is also a read/write latch for output only. The three unused bits in the upper part of the register 28 are traditionally read as ones, but should be written back as zeros. This prevents malfunction with certain newer implementations that use bit 5. Bit 4 is not actually a printer control line; it is used to enable/disable the interrupt.
s The polarity of the status end control lines can be a major source of confusion. To make matters worse, some of the lines are inverted at the interface. A good naming convention can save an implementor a lot of time and trouble.
An active-low signal is a condition indicated by low voltage rather than high voltage. We say that the *ACK signal is active low, because a low voltage on that line indicates an acknowledgement from the printer. The asterisk (*) is part of the name, and serves as a reminder that the signal is active-low.
The PC parallel port interface inverts the BUSY signal and makes the result available as bit 7 of the status register 26. We will call this bit -BUSY. This tilde (-) indicates that the signal is inverted with respect to the cable. The -*STROBE, -*AUTOLF, and -*SLCTi.n signals are both active low and inverted with respect to the cable.
It should be appreciated that some signals can be referenced in more than one way. For example, to say that *SLCTin is lowered is the same as saying that ~*SLCTin is raised. Discussions of the protocol usually reference the signal as it appears on the cable, rather than as it appears on the PC interface.
Another potential source of confusion is the cable itself, simply because in the example shown in FIG. 2 it has a DB-25 male connector on the PC end, and a Centronics 36-pin male connector on the printer end. For example, reference to a "pin k" is ambiguous because the connectors are not one-to-one. FIG. 2 is, therefore, a programmer's quick-reference guide to a PC parallel port. It shows the cable wiring with pin numbers for both connectors, the signal names associated with the wires, the registers accessible by the PC, and the inverters associated with the interface.
With the above background, a protocol according to the teachings of the present invention may now be discussed in detail.
For reasons that will become apparent, this protocol may be called a "nibble-mode reverse channel protocol".
Conventionally, the transfer of data from the host to the printer is accomplished via the forward channel. The bidirectional protocol according to the teachings of the present invention establishes a reverse channel for transferring data from the printer to the host.
Transfers on the forward channel occur one byte at a time;
each byte is transferred independently. The reverse channel is dialogue-oriented; any number of bytes (between 0 and 16384) can be transferred in a single dialogue.
The dialogue has an opening sequence and a closing sequence for the purpose of changing the channel direction, or "turning the channel around". This is necessary because the two channels share certain signals whose meaning depends on which channel is active.
There are not enough signals in the cable to allow both channels to be active simultaneously. FIG. 3 illustrates the reverse channel protocol.
Referring now to FIG. 3, it may be seen that the host initiates the dialogue by writing a hex Olh byte to the data lines, and then raising (de-activating) the *SLCTin signal. The Olh byte represents a communication mode number. Communication mode numbers will be discussed in greater detail hereinbelow.
The printer responds to the foregoing by placing a nibble of data, the loop control hint, on the status lines and then by lowering SLCT. When the host sees SLCT drop, it reads the status lines to get the loop control hint. This also is discussed further below. The dialogue is now open.
The next set of operations in a protocol according to the teachings of the present invention may be designated "data transfer loop operations". In this loop the host lowers *STROBE to request the low nibble of a byte. When SLCT goes high, the host can read the nibble from the status lines. In the example shown in FIG. 3, -BUSY is bit 3, *ACK is bit 2, PE is bit 1, and *ERR is bit 0.
Next, the host raises *STROBE to request the high nibble of the byte. When SLCT goes low, the host can read the nibble from the status lines. In the example shown in FIG. 3, -BUSY is bit 7, *ACK
is bit 6, PE is bit 5, and *ERR is bit 4.
With respect to the loop control hint, which has been mentioned briefly heretofore, during the opening sequence the host reads the loop control hint from the status lines (in this example, ~_ 2075774 -BUSY is bit 3, *ACK is bit 2, PE is bit 1, and *ERR is bit 0). The loop control hint is a four-bit unsigned integer that establishes an upper limit on the number of bytes that can be transferred in the newly-opened dialogue.
5 If the loop control hint is Oh, the printer has then no data to send, and the host is obligated to close the dialogue without attempting to transfer any data.
If the loop cont rol hint is not then the loop control Oh, limit is computed as raised to the (loop control hint 2 power -1).
10 The following table merates all possiblecombinations:
enu Loop control hint Loop contro l limit (bytes) Oh 0 lh 1 2h 2 3h 4 4h 8 5h 16 6h 32 7h 64 8h 128 9h 256 Ah 512 Bh 1024 (1KB) Ch 2048 (2KB) Dh 4096 (4KB) Eh 8192 (8KB) Fh 16384(16KB) The host is not obligated to read all of the available bytes.
The host may read any number of bytes from 0 to the loop control limit. If the host reads up to the limit, it must close the dialogue. If the host still wants more data, it may open another dialogue immediately. There may or may not be more data available.
As an example, suppose the host wants to read 80 bytes of data. Upon opening a dialogue, the host receives a loop control hint of 7h, indicating that it may read no more than 64 bytes. The host reads the 64 bytes, closes the dialogue, and then opens another dialogue. Suppose this time the loop control hint is 6h, indicating that 32 bytes are available. The host then reads 16 bytes (for a total of 80) and closes the dialogue.
The next, and bottommost, set of operations shown in FIG. 3 relate to closing the dialogue. It is the responsibility of the host to close the dialogue when it has read bytes up to the loop control limit, or when it has all the bytes it wants, whichever comes first.
The host closes the dialogue by lowering ~SLCTin and then waiting for SLCT to go high. The host must wait for SLCT to indicate that the status lines now carry status information and not data.
As an aside with respect to the example nibble-mode reverse channel protocol being presented herein, it should be noted that although most printers lower SLCT whenever they go off-line for any reason, if a printer is to support the example protocol presented herein, it must not exhibit this behavior. The SLCT signal must be completely dedicated to the protocol, and should not be used for anything else. When the printer goes off-line, it should raise BUSY
to prevent the host from sending data.
Another topic relating to the present invention that is appropriately discussed herein is protocol timeout errors. There are many places in the protocol where the host must wait indefinitely until a signal transition occurs. In these loops, a timer can be set to prevent hanging. The recommended timeout period is 2 seconds for each loop that is waiting on a signal transition from the printer. This should give the printer plenty of time to respond, yet allow the user to be notified promptly if the printer does not support the protocol at all.
If a wait loop on the host side times out while the dialogue is open, the host should attempt to close the dialogue. If a timeout occurs while closing the dialogue, then the host could reset the printer (using the *INIT pulse) to abort the dialogue. Upon receiving this signal, the printer may or may not take more drastic action, such as cancelling the current job. The host should always make sure that *SLCTin is low (active) before sending the *INIT
pulse; if *SLCTin is high after the ~INIT pulse, the printer will think that the host is trying to open a new dialogue. The host should never try to send data while a reverse channel dialogue is still open.
Now, with respect to host software, some 80x86 assembly-code fragments are presented hereinbelow to assist an implementor of the driver software on the host side. These code fragments are not included as part of the protocol specification, but are merely intended to provide efficient, non-obvious solutions in places where obvious solutions could be very inefficient.
A first fragment herein presented relates to reading the low nibble. When the PC reads the status register to get the low nibble of data, the bits are in the wrong order. This code fragment orders the bits correctly.
;Input: AL has contents of status register. The data bits are in the wrong order. Bit b3 of the data is in bit 7 of the register, b2 is in bit 6, bl is in bit 5, and b0 ; is in bit 3. Bit 4 will always have a 1 in it, because when the low nibble was read, the SLCT line s 2075774 was high.
So AL has: [ b3 b2 bl 1 b0 x x x ]
;Output: AH has the low nibble with the bits in the proper ; order, and the upper nibble is zeroed out.
So AH will have: [ 0 0 0 0 b3 b2 bl b0 ]
sub AL, 08h ; Move b0 into bit 4 (Recall that bit 4 was 1) We now have ( b3 b2 bl b0 x x x x ]
shr AL, 1 ;
shr AL, 1 shr AL, 1 shr AL, 1 mov AH, AL ; Save in AH for later use...
A second fragment herein presented relates to reading the high nibble.
When the PC reads the high nibble from the status register, the bits are again in the wrong order. This code fragment orders them prop erly and combines the high nibble with the low nibble.
;Input: AL has contents of status register. The data bits are in the wrong order. Bit b7 of the data is in bit 7 of the register, b6 is in bit 6, b5 is in bit 5, and b4 ; is in bit 3. Bit 4 is always 0, because when the high nibble was read, the SLCT line was low.
So AL has: [ b7 b6 b5 0 b4 x x x ]
AH should have the low nibble: [ 0 0 0 0 b3 b2 bl b0 ]
;
;Output: AL will have the byte with all the bits properly ordered.
add AL, 08h; Move b4 into bit 4. (Recall that bit 4 was 0) ; We now have [ b7 b6 b5 b4 x x x x ]
and AL, 11110000b ; Mask out junk bits or AL, AH ; Combine nibbles to form a complete byte.
This third code fragment computes the number of bytes to be read by using the loop control hint and the number of bytes the host wants.
;
;Input: BX has maximum number of bytes that the host wants to read. (Limit imposed by the host).
' 2075774 AL has the value of the status register at the time the loop control hint was transmitted. Bit 4 will be 0 because SLCT was low. [ b3 b2 bl 0 b0 x x x ]
;Output: CX will have the number of bytes that should be transferred before closing this dialogue.
BX will have the number of bytes that the host still needs after the dialogue is closed. If BX is nonzero, ; the host should open another dialogue and try to read more bytes.
add AL, 08h ; We now have ( b3 b2 bl b0 x x x x]
mov CL, 4 shr AL, CL ; We now have [ 0 0 0 0 b3 b2 bl b0 ]
AL has the loop control hint dec AL ; Any data available to read?
note that CX is NOT 0 here. Loop logic needs this ; info.
js close dialogue; CLOSE DIALOGUE IF NO DATA AVAILABLE
mov CL, AL ; Use loop control hint as shift count mov AX, 1 ; Get a bit to compute 2" (CL) shl AX, CL ; AX = 2" (loop control hint - 1) ; AX has the loop control limit Compute minimum of BX and loop control limit (AX) sub AX, BX ; CY if BX J AX; AX has delta sbb CX, CX ; 0 if no CY, all 1's if CY
and CX, AX ; 0 or delta add CX, BX ; CX has the minimum sub BX, CX ; BX >= 0 CX has count for transfer loop. Use the loop instruction.
; BX has number of bytes the host lacks after the loop.
The host will want to use two nested loops, one for the actual data transfer, and another to use as many dialogues as needed to get enough data to satisfy the ; host, or until a dialogue says there is no more data.
The loop logic goes something like this:
read_loop:
[ Code to transfer a byte goes here. ]
[ Preserve CX and BX. ]
loop read_loop Note that CX is 0 here...
; Host is obligated to close the dialogue now.
close dialogue:
[ Code to close the dialogue goes here. ]
[ Preserve CX and BX. ]
If BX > 0, open another dialogue and read more data.
or BX, BX
jz xfer done ; If BX is 0, host is satisfied.
5 ; BX has number of bytes host still lacks CX is nonzero if there is no more data available.
If CX is 0, there might be more data.
jcxz open dialogue 10 xfer_done:
If BX is 0, the desired number of bytes was read.
If BX > 0, (N - BX) bytes were read, if N is the number of bytes that were desired.
15 To this point, only a so-called nibble-mode reverse channel protocol has been discussed. The nibble-mode reverse channel protocol, as has heretofore been indicated, is just one of a set of protocols designed for bidirectional parallel communications. Other such protocols are also disclosed in this document.
With respect to the protocol heretofore discussed, the following four communication mode numbers have been assigned:
Mode Number Protocol 0 Version ID protocol 1 Nibble-mode reverse channel protocol 2 IOCTL write mode 3 IOCTL read using nibble-mode rev, ch.
protocol The remaining mode numbers 4-255 can be considered to be reserved for future use.
With respect to opening and closing a communication mode, each communication mode begins and ends in the same manner. To open a communication mode, the host puts the communication mode number on the data lines and then raises the *SLCTin signal. The printer acknowledges the mode by lowering the SLCT signal. All communications proceeding from this point must be according to the specified protocol. If the status lines are to be changed from their standard meanings, this change will happen before the SLCT
signal is lowered. This allows the meanings of the status lines to be multiplexed based on the communication mode.
To close a communications mode, the host lowers *SLCTiri and waits for the printer to raise SLCT to indicate that it is closed.
The meanings of the status lines are restored after the host lowers *SLCTin and before the printer raises SLCT. The host must wait for the SLCT to be raised before proceeding to prevent possible race conditions.
Another protocol according to the teachings of the present invention, which is herein designated a "version ID protocol", will now be described.
Since the bidirectional parallel protocol is expandable, it helps if the host can determine what version of the protocol is being utilized by the printer, or if the printer doesn't support the protocol at all. The version ID protocol provides this functionality.
The version ID protocol works in exactly the same manner as the nibble-mode reverse channel parallel protocol except for a few very important differences. First of all, the communication mode number is zero (0) instead of one (1). So the host must put a hex OOh on the data lines to begin.
The data read back is constant. The loop control hint will always be 2h, so the loop control limit will always be 2. There will always be exactly two bytes to read. The first byte will be hex SAh. The second byte will be the version number of the protocol.
The printer will be required to implement the protocol specified by the version number given in its entirety. Partial implementations will be non-conforming.
To clarify a point that might otherwise be ambiguous: the printer may return 1 for the version number and implement only communication modes 0 and 1, where mode 0 is the version ID protocol specified in a version of a document describing the protocol, and mode 1 is the reverse channel protocol specified in that same version of the document, so upward compatibility is maintained. The version 1 distinction is allowed for future printers that do not have an IOCTL channel.
It is now appropriate to discuss the IOCTL channel in some detail, beginning with a discussion of its purpose.
Often is it desirable or even necessary for host system software to interrogate the printer for detailed status information, or to send configuration commands. But the data stream to the printer (often from an unrelated application) cannot be disrupted by injecting new commands into it asynchronously. Likewise, it is not desirable for host system software to read data from the printer that was intended for an application in attempt to get status information. To complicate this matter, the printer's data buffer is likely to be full when the system software needs to send a status request.
The IOCTL (I/0 control) channel provides a separate logical channel for communicating with the printer. This channel is bidirectional just like the data channel, so that information may be passed both ways. Separate buffers are maintained for this channel so that control and status information can be transferred even when data buffers are saturated.
The format of the information transferred on the IOCTL channel is defined by the printer. Basically, the IOCTL channel is used to transfer control and status information. It is not typically used for sending page descriptions or other data. The data channel is more appropriately used for this purpose.
To read from the IOCTL channel, the host uses the exact same protocol used for the nibble-mode reverse channel protocol, except that the communication mode number is 3. So to open the IOCTL
channel for reading, the host first puts a hex 03h on the data lines and raises *SLCTin, and the dialogue continues just as in communication mode 1.
The information read on this channel is logically separate from the data read using communication mode 1. If there is no data to be read from the reverse (data) channel, that does not imply anything about whether there is information to be read from the IOCTL channel.
To Write to the IOCTL channel, the host must use communication mode 2. To begin the transfer, the host writes a hex 02h on the data lines and then raises *SLCTin. The printer will then put the status of the IOCTL channel on the status lines, and lower SLCT.
When the host sees SLCT go low, it knows that the status lines now reflect the status of the IOCTL channel, not the data channel.
Thus, even if the data channel were busy, the IOCTL channel may not be.
Once communication mode 2 is opened, information is transferred from the host to the printer in the exact same fashion that data is transferred on the data channel, using the data lines, BUSY, *STROBE, *ACK, and the other status lines.
After the control information is transferred to the printer, the host must close the communication mode. The host lowers *SLCTin and waits for SLCT to go high. The printer will restore the status lines to reflect the status of the data channel, and then raise SLCT. The closing is complete when the host sees SLCT go high.
While writing data to the IOCTL channel, often the host will have to wait on BUSY, as is the standard convention. This wait is not constrained by the same 2 second timeout that was discussed above for the nibble-mode reverse channel protocol. The timeout value here is left to the discretion of the host. If the host nets impatient waiting on the BUSY signal and decides to time out, the host should first attempt to close the communication mode in the normal manner.
Moving to a new topic, the standard BIOS INT 17h support for parallel printer communications is very limited in functionality.
The following extensions are proposed to allow software to use the new protocols without re-implementing them. These extensions are proposed as examples only, to facilitate practice of the present invention but not to limit it.
The "identify version" function provides a way to tell that the following extended functions are available for use.
Input:
AX = 80A5h On return:
AX is SASAh BX will have the version number The version number returned will correspond to the version number of an appropriate document describing the protocol. The version number is in the format "H.L." where the "H" portion is returned in BH and the "L" portion is returned in BL. The revision history at the 10 beginning of the appropriate document should provide additional information on version numbers.
Ideally, all future changes to BIOS extensions will be upwardly compatible.
The "write data" function sends a buffer of data to the 15 printer.
Input:
AX = S100h DX = Printer port number (0 to 2 for LPT1 to LPT3) CX = Number of bytes to write 20 DS:SI --> buffer of data On return:
CX contains the number of bytes sent.
Result code is in AX.
If AX is 0: Successfully sent.
-1: Invalid printer port number or port not installed.
-2: The pointer specified is NULL.
-3: Timeout: reason unknown.
-4: Timeout: the printer is probably not connected.
-5: Timeout: the printer is connected but probably not turned on.
The "IOCTL write" function sends a buffer of I/0 control information to the printer. The data is written to the IOCTL
channel instead of the data channel.
Input:
x.2075774 AX = 8101h DX = Printer port number (0 to 2 for LPT1 to LPT3) CX = Number of bytes to write DS:SI --J buffer to send On return:
CX contains the number of bytes sent.
Result code is in AX.
If AX is 0: Successfully sent.
-1: Invalid printer port number or port not installed.
-2: The pointer specified is NULL.
-3: Timeout: reasons unknown.
-4: Timeout: the printer is probably not connected.
-5: Timeout: the printer is connected but probably not turned on.
The "read data" function reads a buffer of data from the printer.
Input:
AX = 8200h DX = Printer port number (0 to 2 for LPT1 to LPT3) CX = Maximum number of bytes to read ES: DI --> buffer area to store incoming data.
On return:
CX contains the number of bytes actually read.
Result code is in AX.
If AX is 0: Successfully sent.
-1: Invalid printer port number or port not installed.
-2: The pointer specified is NULL.
-3: Timeout: reason unknown.
-4: Timeout: the printer is probably not connected.
-5: Timeout: the printer is connected but probably not turned on.
-6: Timeout: printer (probably) does not support the bidirectional protocol.
The "IOCTL read" function reads a buffer of I/0 control information from the printer. The data is read from the I/0 control channel instead of the data channel.
Input:
AX = 8201h DX = Printer port number (0 to 2 for LPT1 to LPT3) CX = Maximum number of bytes to read ES: DI -- buffer area to store incoming data.
On return:
CX contains the number of bytes actually read.
Result code is in AX.
If AX is 0: Successfully sent.
-1: Invalid printer port number or port not installed.
-2: The pointer specified is NULL.
-3: Timeout: reason unknown.
-4: Timeout: the printer is probably not connected.
-5: Timeout: the printer is connected but probably not turned on.
-6: Timeout: printer (probably) does not support the bidirectional protocol.
As a last extension, with respect to read/set timeout value for writes:
Input:
AH = 83h AL = 0 to read, to set DX = Printer port number 2 for LPT1 to LPT3) (0 to BX = Timeout valuein secondsfor writes. 0 means infinite (no timeout).Default 0 (no timeout).
is CX = Timeout valuein secondsfor IOCTL writes. Default is 0 Note: a Ctrl-Break sequence from the operator causes a timeout even if the timeout value is set to 0.
Note 2: This timeout value does not affect reads from either channel.
Those skilled in the art should now appreciate that the present invention provides a bidirectional parallel protocol that is robust, expandable, and well-suited to operate between a host computer and an attached printer. The protocol according to the teachings of the present invention can use existing PC parallel port hardware and cables but is transparent to ill-behaved application software and the like. Still further, the protocol according to the w2075 774 teachings of the present invention allows for rapid polling while not imposing problematic real-time constraints.
Those skilled in the art will recognize that many modifications and variations besides those specifically mentioned may be made in the techniques described herein without departing substantially from the concept of the present invention.
Accordingly, within the scope of the appended claims, the present invention may be practiced otherwise than as specifically described herein.
Claims (22)
1. A method of providing a reverse channel communication capability between a computer and a printer over a parallel interface, said method comprising the steps of:
a) providing, by said computer to said printer, a communication mode signal, said communication mode signal is for placing said printer in a communication mode;
b) providing, by said computer to said printer, a first signal indicating said communication mode signal is ready to be read;
c) providing, by said printer to said computer, a second signal indicating that said printer will provide a computer data in the communication mode indicated in step a);
d) providing, by said printer to said computer, a ready signal indicating that said second signal is ready to be read;
e) providing, by said computer to said printer, a third signal indicating that said computer is ready to receive a first data from said printer;
f) providing, by said printer to said computer, said first data;
g) providing, by said printer to said computer, a fourth signal indicating that said first data is ready to be read;
h) providing, by said computer to said printer, a fifth signal indicating that said computer is ready to receive more data;
i) providing, by said printer to said computer, a second data;
j) providing, by said printer to said computer, a sixth signal indicating that said second data is ready to be read.
a) providing, by said computer to said printer, a communication mode signal, said communication mode signal is for placing said printer in a communication mode;
b) providing, by said computer to said printer, a first signal indicating said communication mode signal is ready to be read;
c) providing, by said printer to said computer, a second signal indicating that said printer will provide a computer data in the communication mode indicated in step a);
d) providing, by said printer to said computer, a ready signal indicating that said second signal is ready to be read;
e) providing, by said computer to said printer, a third signal indicating that said computer is ready to receive a first data from said printer;
f) providing, by said printer to said computer, said first data;
g) providing, by said printer to said computer, a fourth signal indicating that said first data is ready to be read;
h) providing, by said computer to said printer, a fifth signal indicating that said computer is ready to receive more data;
i) providing, by said printer to said computer, a second data;
j) providing, by said printer to said computer, a sixth signal indicating that said second data is ready to be read.
2. The method of claim 1, wherein said first data is a low nibble.
3. The method of claim 2, wherein said second data is a high nibble.
4. The method of claim 1, wherein said communication mode is a reverse channel communication mode.
5. The method of claim 1, wherein said communication mode is an input/output control mode.
6. The method of claim 1, wherein said communication mode is a reverse channel nibble mode.
7. A method of turning around a parallel channel between a computer and a printer comprising the steps of:
a) indicating, by said computer to said printer, a mode of data transfer that is acceptable to said computer, said mode comprises a data format mode;
b) indicating, by said printer to said computer, that an acceptable mode of data transfer will be used by said printer, c) indicating, by said computer to said printer, that data will be accepted on a turned around status line;
d) providing, by said printer to said computer on said turned around status line, data;
e) turning around said turned around status line so that status signal can be sent from said computer to said printer.
a) indicating, by said computer to said printer, a mode of data transfer that is acceptable to said computer, said mode comprises a data format mode;
b) indicating, by said printer to said computer, that an acceptable mode of data transfer will be used by said printer, c) indicating, by said computer to said printer, that data will be accepted on a turned around status line;
d) providing, by said printer to said computer on said turned around status line, data;
e) turning around said turned around status line so that status signal can be sent from said computer to said printer.
8. The method of claim 7, wherein said step d) comprises the steps of sending said data in at least two data nibbles.
9. The method of claim 7, wherein said mode of data transfer is a nibble mode.
10. A protocol for providing bidirectional communication capability between a host computer and a printer over a parallel interface, said host computer and said printer having a forward channel therebetween for transfer of signals from said host computer to said printer, wherein said forward channel comprises status lines and wherein said status lines are used to transfer data from said printer to said host computer during a reverse channel operation, said protocol comprising:
means for turning said forward channel around so as to establish a reverse channel to allow transfer of data from said printer to said host computer, said means for turning said forward channel around includes:
means for determining number of bytes to be read from said printer by said host computer;
means for opening a dialogue; and means for calculating a maximum number of bytes to be transmitted from said printer to said host computer, said maximum number represented by a loop control hint signal sent by said printer to said host computer via said reverse channel;
means for controlling said transfer of data from said printer to said host computer over said reverse channel; and means for turning said reverse channel back around so as to reestablish said forward channel after said host computer reads the number of bytes determined by said determining means.
means for turning said forward channel around so as to establish a reverse channel to allow transfer of data from said printer to said host computer, said means for turning said forward channel around includes:
means for determining number of bytes to be read from said printer by said host computer;
means for opening a dialogue; and means for calculating a maximum number of bytes to be transmitted from said printer to said host computer, said maximum number represented by a loop control hint signal sent by said printer to said host computer via said reverse channel;
means for controlling said transfer of data from said printer to said host computer over said reverse channel; and means for turning said reverse channel back around so as to reestablish said forward channel after said host computer reads the number of bytes determined by said determining means.
11. The protocol as recited in claim 10, wherein said means for turning said forward channel around is activated by said host computer.
12. The protocol as recited in claim 11, wherein said means for turning said reverse channel back around so as to reestablish said forward channel is activated by said host computer.
13. The protocol as recited in claim 10, wherein said forward channel comprises an input/output control channel, and wherein said input/output control channel is used to transfer control and status information between said printer and said host computer during reverse channel operation.
14. The protocol as recited in claim 10, wherein said means for turning said forward channel around comprises means for said host computer to raise a *SLCTin signal, and means for said printer to lower a SLCT signal, wherein the "*" indicates that the signal is "active low".
15. The protocol as recited in claim 10, wherein said means for controlling transfer of data from said printer to said host computer comprises means for said host computer to request a packet of data, means for said printer to indicate a packet of data is on the status lines, and means for said host computer to read the packet of data from the status lines.
16. The protocol as recited in claim 15, wherein said packet of data comprises a nibble of data wherein said means for said host computer to request a nibble of data comprises a *STROBE signal, wherein the "*" indicates that signal is "active low", and wherein said means for said printer to indicate a nibble of data is on the status lines comprises a SLCT signal, whereby a first nibble of data is requested via a lowered *STROBE signal and indicated ready to be transmitted via a raised SLCT signal and whereby a second nibble of data is requested via a raised *STROBE signal and indicated ready to be transmitted via a lowered SLCT signal.
17. The protocol as recited in claim 16, wherein said loop control hint signal transmitted from said printer to said host computer acts in response to said *SLCTin signal being raised and prior to said SLCT signal being lowered.
18. A method for providing bidirectional communication capability between a host computer and a printer over a parallel interface, said host computer and said printer having a forward channel therebetween for transfer of signals from said host computer to said printer, wherein said forward channel comprises status lines and wherein said status lines are used to transfer data from said printer to said host computer during a reverse channel operation, said method comprising the steps of:
turning said forward channel around so as to establish a reverse channel to allow transfer of data from said printer to said host computer, said step of turning said forward channel around includes the steps of:
determining number of bytes that the host computer wants to read from the printer;
sending a dialogue initiating signal from said host computer to said printer for opening a dialogue, and sending a loop control hint signal from said printer to said host computer, said loop control hint signal indicating an upper limit on a number of bytes that can be sent during said opened dialogue;
controlling said transfer of data from said printer to said host computer over said reverse channel in said dialogue; and turning said reverse channel back around so as to reestablish said forward channel after the host computer reads the number of bytes that is determined.
turning said forward channel around so as to establish a reverse channel to allow transfer of data from said printer to said host computer, said step of turning said forward channel around includes the steps of:
determining number of bytes that the host computer wants to read from the printer;
sending a dialogue initiating signal from said host computer to said printer for opening a dialogue, and sending a loop control hint signal from said printer to said host computer, said loop control hint signal indicating an upper limit on a number of bytes that can be sent during said opened dialogue;
controlling said transfer of data from said printer to said host computer over said reverse channel in said dialogue; and turning said reverse channel back around so as to reestablish said forward channel after the host computer reads the number of bytes that is determined.
19. The method as recited in claim 18, wherein the step of turning said forward channel around is activated by said host computer.
20. The method as recited in claim 19, wherein the step of turning said reverse channel back around so as to reestablish said forward channel is activated by said host computer.
21. The method as recited in claim 18, wherein the forward channel comprises an input/output control channel, and wherein the input/output control channel is used to transfer control and status information between said printer and said host computer during reverse channel operation.
22. The method as recited in claim 18, wherein the step of turning said forward channel around comprises the step of said host computer raising a SLCTin signal. and the step of said printer lowering a SLCT signal, wherein the "*" indicates that signal is "active low".
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US75062591A | 1991-08-27 | 1991-08-27 | |
| US750,625 | 1991-08-27 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2075774A1 CA2075774A1 (en) | 1993-02-28 |
| CA2075774C true CA2075774C (en) | 2000-10-17 |
Family
ID=25018609
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002075774A Expired - Fee Related CA2075774C (en) | 1991-08-27 | 1992-08-11 | Bidirectional parallel protocol |
Country Status (16)
| Country | Link |
|---|---|
| US (2) | US5507003A (en) |
| EP (1) | EP0529887B1 (en) |
| JP (1) | JP3103216B2 (en) |
| KR (1) | KR930004868A (en) |
| CN (1) | CN1044414C (en) |
| AT (1) | ATE214172T1 (en) |
| AU (1) | AU645920B2 (en) |
| BR (1) | BR9203330A (en) |
| CA (1) | CA2075774C (en) |
| DE (1) | DE69232456T2 (en) |
| IE (1) | IE922610A1 (en) |
| IL (1) | IL102823A (en) |
| MX (1) | MX9204892A (en) |
| MY (1) | MY153949A (en) |
| NZ (1) | NZ243927A (en) |
| TW (1) | TW203673B (en) |
Families Citing this family (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5706411A (en) * | 1992-11-09 | 1998-01-06 | Microsoft Corporation | Printer status user interface and methods relating thereto |
| US5542071A (en) * | 1992-11-13 | 1996-07-30 | Video Associates Labs, Inc. | System for determining communication speed of parallel printer port of computer by using start timer and stop timer commands within data combined with embedded strobe |
| US6208906B1 (en) * | 1993-11-08 | 2001-03-27 | Seiko Epson Corporation | Printing apparatus with a cash drawer control function, and a control method therefor |
| JP3201141B2 (en) * | 1994-06-02 | 2001-08-20 | セイコーエプソン株式会社 | Data receiving method |
| JP3563793B2 (en) * | 1994-12-21 | 2004-09-08 | キヤノン株式会社 | Data processing method and apparatus |
| JPH08185292A (en) * | 1994-12-27 | 1996-07-16 | Nec Corp | Bidirectional printer interface |
| JPH096720A (en) * | 1995-06-15 | 1997-01-10 | Canon Inc | Method and system for transmitting information |
| JP3495865B2 (en) * | 1996-01-09 | 2004-02-09 | キヤノン株式会社 | PRINTING APPARATUS, INFORMATION PROCESSOR CONNECTING THE PRINTING APPARATUS, AND CONTROL METHOD THEREOF |
| DE69837356T2 (en) | 1997-02-14 | 2007-11-29 | Canon K.K. | Apparatus, system and method for data transmission and apparatus for image processing |
| SG74611A1 (en) * | 1997-02-14 | 2000-08-22 | Canon Kk | Data communication apparatus and method |
| DE69840972D1 (en) | 1997-02-14 | 2009-08-27 | Canon Kk | Apparatus, system and method for data transmission and apparatus for image processing |
| EP0859326A3 (en) | 1997-02-14 | 1999-05-12 | Canon Kabushiki Kaisha | Data transmission apparatus, system and method, and image processing apparatus |
| US6006284A (en) * | 1997-03-31 | 1999-12-21 | Sun Microsystems, Inc. | Method and apparatus for driving a parallel part to provide multiple modes of communications between a host and a peripheral |
| US6614545B1 (en) | 1997-05-09 | 2003-09-02 | Lexmark International, Inc | Communication scheme for imaging systems including printers with intelligent options |
| JP3786152B2 (en) * | 1997-11-14 | 2006-06-14 | セイコーエプソン株式会社 | Printing system, printing method, and printer |
| JPH11168524A (en) * | 1997-12-05 | 1999-06-22 | Canon Inc | Communication controller, data processing method for the communication controller and storage medium storing program readable by computer |
| US6064492A (en) * | 1998-05-29 | 2000-05-16 | Xerox Corporation | Image data interface between digital front end and printer |
| US6717694B1 (en) * | 1998-07-31 | 2004-04-06 | Canon Kabushiki Kaisha | Data transmission apparatus, system and method, and recording medium |
| US6124938A (en) * | 1998-09-24 | 2000-09-26 | Xerox Corporation | Submitting software upgrades to a digital printer through a standard port |
| US6295538B1 (en) * | 1998-12-03 | 2001-09-25 | International Business Machines Corporation | Method and apparatus for creating metadata streams with embedded device information |
| JP3652153B2 (en) * | 1999-01-18 | 2005-05-25 | キヤノン株式会社 | Image output apparatus and control method thereof |
| SE9900517L (en) * | 1999-02-17 | 2000-08-18 | Axis Ab | Interface and method of communication |
| CN1145876C (en) * | 1999-03-29 | 2004-04-14 | 精工爱普生株式会社 | Network system and network interface card |
| JP4306118B2 (en) * | 2000-02-21 | 2009-07-29 | セイコーエプソン株式会社 | Printer and printer control method |
| US6725304B2 (en) * | 2000-12-19 | 2004-04-20 | International Business Machines Corporation | Apparatus for connecting circuit modules |
| JP2006079138A (en) * | 2004-09-07 | 2006-03-23 | Ricoh Co Ltd | Status acquisition method, printer driver, and information processor |
| CN103067641B (en) * | 2012-12-13 | 2016-04-27 | 珠海赛纳打印科技股份有限公司 | Image forming apparatus and method |
| CN103942015A (en) * | 2014-04-25 | 2014-07-23 | 长春工业大学 | Computer and printer bidirectional parallel communicating method based on data package |
| JP6439797B2 (en) * | 2014-07-03 | 2018-12-19 | ソニー株式会社 | Interface circuit, transmission system, transmission direction control method and program |
| JP7145752B2 (en) * | 2018-12-27 | 2022-10-03 | セイコーインスツル株式会社 | PRINTING SYSTEM, HOST DEVICE, PRINT CONTROL METHOD, AND PROGRAM |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3827357A (en) * | 1973-09-12 | 1974-08-06 | Sperry Rand Corp | On-the-fly printer with shortened print cycle |
| US4452136A (en) * | 1979-10-19 | 1984-06-05 | International Business Machines Corporation | Printer subsystem with dual cooperating microprocessors |
| US4388686A (en) * | 1980-10-20 | 1983-06-14 | General Electric Company | Communication system for distributed control arrangement |
| US4641263A (en) * | 1982-05-17 | 1987-02-03 | Digital Associates Corporation | Controller system or emulating local parallel minicomputer/printer interface and transferring serial data to remote line printer |
| JPS5933527A (en) * | 1982-08-20 | 1984-02-23 | Pioneer Electronic Corp | Interface device |
| US4703450A (en) * | 1982-08-20 | 1987-10-27 | Pioneer Electronic Corporation | Interface device |
| JPS60157353A (en) * | 1984-01-26 | 1985-08-17 | Citizen Watch Co Ltd | Communication system for inquiry of printer information |
| US4697232A (en) * | 1984-11-30 | 1987-09-29 | Storage Technology Corporation | I/O device reconnection in a multiple-CPU, dynamic path allocation environment |
| US4661902A (en) * | 1985-03-21 | 1987-04-28 | Apple Computer, Inc. | Local area network with carrier sense collision avoidance |
| US4745602A (en) * | 1985-09-20 | 1988-05-17 | Minolta Camera Company, Ltd. | Printer error and control system |
| US4745597A (en) * | 1986-05-14 | 1988-05-17 | Doug Morgan | Reconfigurable local area network |
| AU2220288A (en) * | 1987-09-15 | 1989-03-16 | Twelve Metre Research Pty. Ltd. | A computer interface system |
| US4866609A (en) * | 1988-06-22 | 1989-09-12 | International Business Machines Corporation | Byte count handling in serial channel extender with buffering for data pre-fetch |
| US4922491A (en) * | 1988-08-31 | 1990-05-01 | International Business Machines Corporation | Input/output device service alert function |
| US5123089A (en) * | 1989-06-19 | 1992-06-16 | Applied Creative Technology, Inc. | Apparatus and protocol for local area network |
| US5163138A (en) * | 1989-08-01 | 1992-11-10 | Digital Equipment Corporation | Protocol for read write transfers via switching logic by transmitting and retransmitting an address |
| US5333286A (en) * | 1989-12-13 | 1994-07-26 | Joseph Weinberger | Two way copier monitoring system |
| US5133055A (en) * | 1990-01-16 | 1992-07-21 | Physio Systems, Inc. | Signal processor for personal computers |
| US5299314A (en) * | 1990-03-22 | 1994-03-29 | Xircom, Inc. | Network adapter using status inlines and data lines for bi-directionally transferring data between lan and standard p.c. parallel port |
| US5075875A (en) * | 1990-04-20 | 1991-12-24 | Acuprint, Inc. | Printer control system |
| US5179555A (en) * | 1990-09-11 | 1993-01-12 | Microcom Systems, Inc. | High speed data compression and transmission for wide area network connections in LAN/bridging applications |
| US5200958A (en) * | 1990-09-28 | 1993-04-06 | Xerox Corporation | Method and apparatus for recording and diagnosing faults in an electronic reprographic printing system |
| JPH05189104A (en) * | 1990-10-31 | 1993-07-30 | Ricoh Co Ltd | Parallel interface |
| US5239627A (en) * | 1991-03-26 | 1993-08-24 | International Business Machines Corporation | Bi-directional parallel printer interface |
| GB9108599D0 (en) * | 1991-04-22 | 1991-06-05 | Pilkington Micro Electronics | Peripheral controller |
-
1992
- 1992-08-11 CA CA002075774A patent/CA2075774C/en not_active Expired - Fee Related
- 1992-08-12 NZ NZ243927A patent/NZ243927A/en unknown
- 1992-08-13 DE DE69232456T patent/DE69232456T2/en not_active Expired - Fee Related
- 1992-08-13 AT AT92307429T patent/ATE214172T1/en not_active IP Right Cessation
- 1992-08-13 AU AU21023/92A patent/AU645920B2/en not_active Ceased
- 1992-08-13 EP EP92307429A patent/EP0529887B1/en not_active Expired - Lifetime
- 1992-08-16 IL IL10282392A patent/IL102823A/en not_active IP Right Cessation
- 1992-08-17 MY MYPI92001472A patent/MY153949A/en unknown
- 1992-08-25 JP JP24858292A patent/JP3103216B2/en not_active Expired - Lifetime
- 1992-08-25 MX MX9204892A patent/MX9204892A/en unknown
- 1992-08-26 BR BR929203330A patent/BR9203330A/en not_active IP Right Cessation
- 1992-08-26 IE IE261092A patent/IE922610A1/en not_active IP Right Cessation
- 1992-08-26 KR KR1019920015443A patent/KR930004868A/en not_active Application Discontinuation
- 1992-08-27 CN CN92110174A patent/CN1044414C/en not_active Expired - Lifetime
- 1992-08-29 TW TW081106856A patent/TW203673B/zh active
-
1994
- 1994-11-14 US US08/338,885 patent/US5507003A/en not_active Expired - Lifetime
-
1996
- 1996-01-03 US US08/582,524 patent/US5666558A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| MY153949A (en) | 2015-04-15 |
| NZ243927A (en) | 1995-09-26 |
| IL102823A0 (en) | 1993-01-31 |
| JP3103216B2 (en) | 2000-10-30 |
| US5507003A (en) | 1996-04-09 |
| EP0529887A3 (en) | 1993-09-22 |
| DE69232456D1 (en) | 2002-04-11 |
| CA2075774A1 (en) | 1993-02-28 |
| IL102823A (en) | 1996-03-31 |
| EP0529887A2 (en) | 1993-03-03 |
| IE922610A1 (en) | 1993-03-10 |
| EP0529887B1 (en) | 2002-03-06 |
| MX9204892A (en) | 1993-04-01 |
| TW203673B (en) | 1993-04-11 |
| AU645920B2 (en) | 1994-01-27 |
| JPH05341923A (en) | 1993-12-24 |
| KR930004868A (en) | 1993-03-23 |
| US5666558A (en) | 1997-09-09 |
| CN1044414C (en) | 1999-07-28 |
| AU2102392A (en) | 1993-03-04 |
| BR9203330A (en) | 1993-04-06 |
| DE69232456T2 (en) | 2002-09-26 |
| ATE214172T1 (en) | 2002-03-15 |
| CN1070497A (en) | 1993-03-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2075774C (en) | Bidirectional parallel protocol | |
| US5600793A (en) | Method and system of bi-directional parallel port data transfer between data processing systems | |
| US7058748B1 (en) | ATA device control via a packet-based interface | |
| CA2297084C (en) | A universal serial bus device controller | |
| JP4377603B2 (en) | Bus communication system and communication control method thereof | |
| WO1998015896A1 (en) | High speed heterogeneous coupling of computer systems using channel-to-channel protocol | |
| US5838995A (en) | System and method for high frequency operation of I/O bus | |
| US6128311A (en) | Method and system for interfacing parallelly interfaced devices through a serial bus | |
| US5754881A (en) | Method of controlling a PC parallel port switch for connecting multiple peripherals to the same parallel port | |
| US5710939A (en) | Bidirectional parallel data port having multiple data transfer rates, master, and slave operation modes, and selective data transfer termination | |
| US6425071B1 (en) | Subsystem bridge of AMBA's ASB bus to peripheral component interconnect (PCI) bus | |
| US6058440A (en) | Programmable and adaptive resource allocation device and resource use recorder | |
| CA2234635C (en) | Method and device for exchanging data | |
| US5218683A (en) | Method and apparatus for concealing the enablement of a device by modifying a status word | |
| US5539666A (en) | Data communications method and system coupling device | |
| EP0501489A1 (en) | Advanced functionality parallel port interface | |
| US6112259A (en) | Integrated circuit for direct memory access | |
| KR950012501B1 (en) | Method for increasing data input/output speed in a personal computer | |
| CA2025511C (en) | Method and apparatus for concealing the enablement of a device by modifying a status word | |
| Frock | IEEE 1284–Updating the PC Parallel Port | |
| KR0170742B1 (en) | Data transfer method using mbus | |
| TW502171B (en) | Data transmitting system | |
| KR20030044373A (en) | Universal serial bus device for using direct memory access interface | |
| JP3423376B2 (en) | Information processing apparatus and control method therefor | |
| JP2000155738A (en) | Data processor |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |