Nope, not the issue. Surely for some of the very fastest applications in slower style computers the extra bus transfer protocol overhead may be a small performance issue but that is the least of the problems around PCI and PCIe add-in type parallel boards.

The main issue with parallel port adapter boards and why they are such an issue for system designers and developers is that when the original ISA board parallel port designs were "expanded" to support EPP and ECP modes there was a very dumb thing done. As many will know the original parallel ports in standard mode (SPP) used one of the I/O base addresses of 0x378, 0x278 or 0x3BC. When the extended modes were "invented" an extra set of registers were added to accomodate the additional features. Instead of finding a clever way to bank in the new registers into the existing port space allocations the designers instead decided to create a hole in the legacy I/O space by decoding more ports at BASE+0x400. This means that a parallel port adapter that wants to work in legacy manner at one of the legacy I/O port address ranges will also suck up addresses at 0x778, 0x678, or 0x7BC.

It turns out that when PCI and Plug-n-Play were designed the mechanism was given the capability that I/O boards and PCI style devices would be given a base address configured by BIOS and/or the OS. The standard PCI configurable device was meant to be able to be assigned either an IO Base address or a MEM Base address depending upon what was suitable to the adapter or device interface. Only one address range is typically configured. Vendors that have made PCI type parallel port expander chips have tried to make them so that EPP and ECP modes can be used and so the method is to make the adapter device ask for two PCI address range assignments. A basic problem comes into play because the BIOS / OS P-n-P port assignment logic is never required that it would assign separate device I/O addresses at two areas that are guarenteed to be exactly 0x400 (1K) I/O addresses apart. As a matter of fact the P-n-P configurator software is often further hampered by block alignment and mapping issues. As CPU busses of modern day devices route through chipsets they have to pass through PCIe to PCIe, PCIe to PCI, or PCI to LPC bridges. These bridges also need to be configured as to what ranges of memory and I/O address space each will own. It is common to see the address block modularity at this level to be limited to decoding block sizes of 4K. As such it is very difficult to support devices like legacy parallel ports, with their fixed offset kludge, in any kind of sane manner.

Recent research that I have done points to this as being the main reason that parallel ports and the I/O address range they consume have been such a millstone around system designer's necks. What this does mean is that it is surely possible to add in a parallel port board to a modern day PCI or PCIe slot but in order to make use of it you must either live with the I/O address that P-n-P assigns to the board OR you must accept using a device driver that maps the port in a logical manner to an software type interface under the OS. Such device driver interface can host a data flow interface to some strange numbered LPTn: "port" but the using application software does not concern itself with hardware I/O ports and instead sends data through an Open/Write/Read/Close type file interface.

Similar to the discussion in the other posting regarding USB parallel adapters the main needs that folks have for parallel ports on machines is to support them at their legacy I/O port range so that old non-PCI P-n-P aware software can still work with OUT DX,AL and IN AL,DX type software instructions at the known legacy addresses at 378-278-3BC.

In the slow march of PCs away from legacy ISA style devices at fixed I/O addresses there has been a continual effort to retain some type of backward compatibility. This is clearly one of the main reasons that PCs have retained popularity over many many years. If at the advent of PCI and P-n-P there had been a move by system architects, chips set designers and computer manufacturers to make a clean cut away from ISA and legacy support from the '80s and early '90s the PC would not be in the same place as today. Legacy compatibility has had a huge part in keeping down costs of both hardware and software. That said however there will come a day soon, driven mostly by the closed nature of most new systems (i.e. laptops, netbooks, and smart phones) that legacy support will vanish entirely.

Per is right in suggesting that the use of a PCMCIA type card is one of the last vestiges of ways to add legacy type devices to modern hardware platforms. These device connections in hardware have been blest with I/O address mapping that still supports some of the legacy I/O address decode ranges. The chip sets on PC platforms however are often designed in an manner that limits the number of legacy I/O ranges that will be allowed. For example a chipset may limit to one floppy address range, just two comm port ranges or a single lpt port range. And then, since these often need to be enabled at BIOS boot time inside the chip set, it is essential that the BIOS allow the mapping for such devices. Keep in mind as systems become more and more closed BIOSs will not enable these and future chipsets will start to purge much of the legacy port decode and support logic.

Michael Karas