| |
LW1DSE > TECH 16.01.18 14:11l 336 Lines 18612 Bytes #999 (0) @ WW
BID : 1134-LW1DSE
Read: GUEST
Subj: PC Parallel Port data
Path: IW8PGT<IZ3LSV<ED1ZAC<LU4ECL<LW2DQC<LU9DCE<LU1DBQ<LU7DQP
Sent: 180116/1147Z @:LU7DQP.#LAN.BA.ARG.SOAM #:27482 [Lanus Oeste] FBB7.00i
From: LW1DSE@LU7DQP.#LAN.BA.ARG.SOAM
To : TECH@WW
[――― TST HOST 1.43c, UTC diff:5, Local time: Mon Nov 20 19:00:49 2017 ®®®]
A Guide to Parallel Ports:
-------------------------
This document describes the range of parallel ports fitted to IBM PC
and compatible computers, and how to use them in applications other than just
straight printing. If all you want to do is print some text from a commercial
application, then this document is not for you. However if you want to get
the most out of the parallel port on your machine, then read on.
1) Introduction.
The Parallel port has come a long way since its original
implementation on the IBM PC in the early eighties. It was originally designed
to allow faster output to printers than the serial port. It did this by
transferring 8 bits of data at a time instead of one. Although this is still
the most common use for the parallel port, it is also put to many more uses,
and provides vastly superior methods for data transfer to those who wish to
spend a little time and effort. This document is intended to give the reader
a good grounding in the way the parallel port appears to a systems programmer
in an attempt to reduce this learning curve. All of the information contained
here has come from either the list of books given at the end of this document,
or by experimentation.
2) Table of Contents.
2.1) The History of the Parallel Port
2.2) Which Type Have I Got?
2.3) How Do I Talk To It?
2.4) What Problems Am I Likely To Encounter?
2.5) Bibliography
2.1) The History Of The Parallel Port.
In the beginning was the Centronics Printer Interface. This was
adapted by IBM in the early eighties to produce the parallel port for their
new desktop computer - The IBM PC. Its purpose was simple; to supply data to
printers quickly and to allow the status of the printer to be read. It used a
25-way D type connector, although only 17 of the pins were used to carry
signals, the remaining 8 being ground. Twelve of the pins are output only, 4
input only, and one bi-directional signal. This type of port is known as a
Standard Parallel Port (or SPP for short). The only way of reading data from
this type of port was to use the four input pins as datapins, and perform two
reads in order to build up a byte of data. Of course this relies on the
peripheral at the other end co-operating with this mode of communication.
This mode of operation is termed 'Nibble Mode' for obvious reasons.
This was quite adequate for a lot of applications where the main transfer of
data was from the PC to the peripheral, with small amounts of data in the
reverse direction.
When the IBM PS/2 arrived on the scene it brought with it an enhanced
parallel port. Each of the eight data signals could now be used for either
input or output, and their use changed dynamically under software control.
In all other respects this type of port was the same as the earlier SPP ports.
This mode of operation is 'Byte Mode' or sometimes 'PS/2 Mode'. The former is
preferable because it is no longer limited to PS/2 computers.
The next evolution of the parallel port came when Intel, Zenith, and
Xircom, collaborated to produce the Enhanced Parallel Port. This too provided
bi-directional transfers in bytes. However its main advantage was that now a
byte could be transferred in a single ISA bus cycle, with the parallel port
hardware performing all necessary handshaking, instead of the handshaking
being performed under software control as in the previous two modes. An EPP
port can support transfer rates up to about 2 Megabytes per second. Using the
port in this mode is, not surprisingly, called 'EPP Mode'.
In a separate move Microsoft and Hewlett Packard got together to
produce the ultimate parallel port. The hardware would support DMA transfers
and would include a 16-byte FIFO for non-DMA data transfers. Each byte would
be transferred in a single ISA bus cycle. Not only that, it would support the
old modes as well. But, and it's a big but, Microsoft decided not to support
EPP mode (after all it was developed by their rival IBM). This type of port
is called an Enhanced Capabilities Port (or ECP port ). ECP mode transfers
require some help from the driving software as it doesn't automatically
handle timeouts on data transfers.
Finally the IEEE got involved in an attempt to standardise all of
these port types and transfer modes. Basically all they did was to formally
document the hardware and protocols already in use. The only significant
addition being that they allow ECP ports to optionally support EPP mode
transfers as well. The relevant standard is the snappily titled
"IEEE Std.1284-1994 Standard Signaling Method for a Bi-directional Parallel
Peripheral Interface for Personal Computers".
2.2) Which Type Have I Got?
OK, so now you know what the different types of parallel port are,
how do you know which one you have? Easy question, long answer! The first
thing to realise is that the capabilities of the parallel port hardware are
limited by the BIOS settings for the parallel port. Each chipset has a set of
registers that allow the hardware capabilities to be configured. Unfortunately
each chipset uses different registers to perform this, so you can't
interrogate the chipset directly. Nor is there a mode register that can be
read. The only way that software can determine the capabilities of the port
is to interrogate the standard registers under controlled conditions and
examine the results. Not only is the method for interrogating the registers
complicated, but the order in which tests are performed is also critical in
order to produce reliable results.
2.3) Where are the parallel ports?
The first thing you need to do is to claim the parallel port
resources. From a Windows 95 or NT device driver the easiest way to do this
is to call the existing parallel port driver to open the port for exclusive
use. Assuming this succeeds you then have total control over the parallel
port. As far as I am aware, opening the port will cause the hardware to be
set into a stable state (although this may be done by the BIOS). From a DOS
program you can just access the port I/O addresses directly. But to do this
you need to know where the parallel port lives in I/O space. In DOS and
Windows 95 this information can only be obtained by looking at the BIOS data
area at linear address 40:8 onwards. Starting at this location are a series
of words giving the I/O base address for up to three LPT ports (or 4 on a
PS/2). If the address is zero then no port hardware exists.
2.3.1) IEEE-1284 protocol negotiation
IEEE-1284 defines a handshaking protocol used to negotiate a protocol
that the host and peripheral will use. However this assumes that the
peripheral contains either hardware or firmware which supports this
negotiation. As we (nearly) always know what modes are supported by the
peripherals we are talking to, and none of them (to my knowledge) support the
negotiation protocol, I am not going to discuss this further here.
2.3.2) Testing for ECP ports
As this is the most capable mode, it makes sense to check for this
first. Having opened the port the hardware should have been initialised. If
an ECP port is fitted then its FIFO will have been cleared. So, the first
check is to see whether the FIFO status bits indicate that the FIFO is empty.
If they indicate that the FIFO isn't empty then you don't have an ECP Port.
If the status bits report that the FIFO is empty, this does not guarantee
that an ECP port is fitted, it may just be that the bits at the I/O address
happen to be in the right state. On an ECP port, the ECP specific registers
are located at an offset of 0x400 from the parallel port's base address. On
some early machines, the address lines weren't fully decoded and the port
could be accessed at base address, base address + 0x400, base address + 0x800,
and so on. This leads us to our second test. If we write to base address +
0x400 and base address also gets updated, then the address lines aren't being
fully decoded and so this can't be an ECP port.
An ECP port contains a control register at offset 0x402 from the
port's base address. Two of these bits are read-only, which gives us our
final test. If we write to this register with these two bits inverted, and
they get modified then this is not an ECP mode port. Otherwise the chances
are that this is an ECP mode capable port. The only sure-fire way of knowing
is to perform an ECP mode transfer an see whether it works.
There is one additional point to note. Even if your software doesn't
support fully ECP mode transfers, it is possible to use an ECP port in one of
its compatibility modes. However as the EPP compatibility mode doesn't have
to be supported to be IEEE-1284 compliant, you have to test for this in the
same way as you would test for a normal EPP mode port (see below). The
compatibility modes are selected by setting the mode bits in the ECP Control
Register.
2.3.3) Testing for EPP ports
These are the most difficult of all to detect, because they only have
two registers which don't exist in older mode ports, and both of those
registers cause information to be transferred across the parallel link.
Therefore the only way to test for an EPP port is to write to the EPP_Address
and EPP_Data registers, and see whether the hardware handshaking completed
successfully, or whether the transfer timed out. This test relies on there
being an EPP compatible peripheral connected to the parallel port.
Warning: Depending upon the peripheral, you may be restricted to which
peripheral addresses you can attempt to read and write safely. This makes a
general purpose port detection utility almost impossible to write.
2.3.4) Testing for SPP ports
"Hang on a minute!" I hear you say, "What about PS/2 ports? Surely
they come next?". Well there is a good reason for testing in this order.
Because SPP and byte-mode ports use the same set of registers, and require
the same control from the software, the only test you can do is to write to
the port, and see what you read back. If you have an SPP only port, and you
write to the data register, you should read back the same value. If you don't
then you don't have an operational parallel port of any kind.
2.3.5) Testing for Byte-mode ports
Having determined that there is a parallel port of kinds present we
can check for Byte mode. To do this we place the port into 'input' mode and
write to the data register. If we read back a different value then we have a
bi-directional (and therefore byte-mode) port. If we read back the same value
then the port is output only (SPP). Of course you would need to try different
bit patterns just to avoid 'detection by coincidence'.
3) How Do I Talk To It?
The only sensible way to drive the parallel port is to build yourself
an environment in which you can read and write to the hardware registers
directly. In Windows® NT this means writing a device driver, as this is the
only environment in which you have sufficient priviledge. Under DOS you can
just use IN and OUT instructions directly from the application program. In
Windows 95 you have the option of doing either. However it is much cleaner
to write a device driver and export a suitable API using a DLL. Each of the
modes requires the controlling software to behave differently, so I will take
each one in turn.
3.1) EPP Mode
This is by far and away the easiest mode to use, as a lot of the work
is done for you by the hardware. There isn't flow control to worry about, and
no actions are required in order to turn the link around. To read or write
data to a logical address on the peripheral, that address is first written to
the EPP_ADDRESS register. (It is up to the peripheral how many bytes of
address are required, the address being written a byte at a time.) It is then
simply a case of either reading from or writing to the EPP_DATA register to
transfer the data. Most peripherals will auto-increment the address for each
byte read, although this isn't required by IEEE-1284.
3.2) ECP Mode
Actually I'm going to cop out of this one to some extent. Because ECP
mode ports support other modes as well, you only really need ECP mode if you
require the high throughput in one direction afforded by the FIFO, or you are
going to make use of DMA transfers. The FIFO is really only of any use if you
are transfering data in large blocks in one direction. As not many
applications would use this I amn't going to discuss it further here.
Similarly DMA transfers only have an advantage when transfering large blocks
of data. For most applications a 'dialogue' exists between the host and the
peripheral. In this case it is better to use the EPP sub-mode of ECP, or if
that isn't supported then Byte-Mode.
3.3) Byte Mode
a) The host disables outputs on the port using a bit in the control
register.
b) The host brings HostBusy low to indicate that it is now ready to
receive data.
c) The peripheral places the data on D0 through D7 and brings PtrClk
low.
d) When the host sees PtrClk going low, it reads the data and brings
HostBusy high. It then brings HostClk low.
e) The peripheral will then set the status bits as follows:
- PtrBusy high if the peripheral is busy, low otherwise
- nDataAvail low if another byte is ready to be sent, high
otherwise
- AckDataReq is set to match nDataAvail
f) The peripheral then brings PtrClk high
g) The host then brings HostClk high to indicate that it has read
the byte. The host may then:
- Bring HostBusy low and wait for more data
- Leave HostBusy high to prevent the peripheral from sending
another byte
3.4) Nibble Mode
Nibble mode uses four of the status lines to transfer data from the
peripheral to the host. Early port drivers used varying combinations of
status bits to represent the data bits. IEEE-1284 standardized the bits to be
used as S3, S4, S5 and S7. S6 isn't used as that is often ties to an
interrupt line. The sequence of events is as follows:
* The host brings HostBusy low to say that it's ready to accept the first
nibble.
a) The peripheral writes the first nibble to the status lines and
brings PtrClk low to indicate that the nibble is available.
b) The host reads the first nibble and brings HostBusy high to
indicate that it has read the data.
c) The peripheral brings PtrClk high.
d) When the host is ready for the second nibble it brings HostBusy
low.
e) The peripheral place the second nibble on the status lines.
f) The host reads the second nibble and brings HostBusy high.
g) The peripheral then sets the status bits to indicate its state
(busy, more data available, etc).
h) The peripheral brings PtrClk high
i) The host can now read the peripheral status from the status
register.
4) What Problems Am I Likely To Encounter?
a) If you use ECP mode then you have to manually turn the port around.
It seems that this can only be done by switching into Byte mode,
turning the port around, and then returning to ECP mode.
Answer: don't use ECP mode alone, but use another supported mode.
b) Gaining access to the parallel port's resources can be tricky
depending on which operating system you are using. Under '95 you
have to request the use of the port from the operating system. If
another process is already using it, you won't have access to the
port. Also under '95 and DOS there isn't service which tells you
which IRQ the parallel port is using. You have to detect it
yourself. I have code to do this but it is outside the scope of
this document.
c) Debugging the handshaking can be a nightmare. A logic analyser or
storage 'scope is the only real answer, so its best to just get it
right first time!
d) Lack of information. That's why I've spent the time preparing this
so that you don't have to go through the mental torture I went
through. The bibliography below gives pointers to where to obtain
further information if I can't answer your question.
5) Bibliography
[1] Parallel Port Complete, Jan Axelson, Lakeview Research, ISBN
0-9650819-1-5, email:jaxelson@lvr.com,http://www.lvr.com
[2] Warp Nine Engineering, http://www.fapo.com
6) Pinning.
# Pin Signal Active
1 STROBE L
2 DATA BIT 1 H
3 " 2 H
4 " 3 H
5 " 4 H
6 " 5 H
7 " 6 H
8 " 7 H " 7 H
9 " 8 H " 7 H
10 AKNOWLEDGE L
11 BUSY H
12 OUT OF PAPER H
13 SELECT H
14 AUTO FEED L
15 ERROR L
16 RESET L
17 SELECT INPUT L
18 to 25 GROUND 0
ΙΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝ»
Ί Osvaldo F. Zappacosta. Barrio Garay (GF05tg) Alte. Brown, Bs As, Argentina.Ί
Ί Mother UMC ζPC:AMD486@120MHz 32MbRAM HD SCSI 8.4Gb MSDOS 7.10 TSTHOST1.43C Ί
Ί 6 celdas 2V 150AH. 18 paneles solares 10W. Ί
Ί lw1dse@yahoo.com ; lw1dse@gmail.com Ί
ΘΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΌ
Read previous mail | Read next mail
| |
