How to talk to a device that is connected to a parallel port?

Question

Say I have a parallel port in my computer, now the parallel port will have some memory associated with it that the CPU can access (not sure if parallel ports use memory-mapped IO or port-mapped IO).

Now if I want to send a signal to the parallel port or receive a signal from the parallel port, I would have to write to or read from the memory associated with the parallel port.

Now say I have a printer connected to the parallel port, the printer will also have some memory (for example: it could have a buffer that it uses to store the data it should print).

My question is, can the CPU access the memory for the printer directly, for example, can the CPU write directly to the printer's buffer? or is the only way to talk to the printer is indirectly through the parallel port?

Answer 1

Traditional PC parallel ports use port I/O with in/out, not MMIO. The external signal lines are mapped directly to an I/O register, so a single out instruction will set all 8 signal lines. You can wire up LEDs + resistors and try it. (Fun project.)

This page has Linux, Windows, and DOS programs that use outb to put a byte on the pins of the parallel port. It also has a lot of introductory stuff about parallel ports, including an important point that USB parallel ports have the same external interface, but a different internal software interface. A USB parport won't work with in / out instructions.

---

can the CPU access the memory for the printer directly

No. I think you're asking if you can run an x86 instruction that stores from a CPU register all the way to printer memory. If the printer happens to be in the middle of receiving a burst of data, then putting a byte on the pins of that parallel port will result in it copying that byte into its memory. But to set that up, you need to send commands in whatever communication protocol the printer understands.

Imagine an FTP or web server. You can read or write remote files, but you have to send commands first to start the transfer, and then the communication link (the network socket) just carries the data being transferred. You're talking to a program on the remote computer, not reading its disk contents or RAM directly.

---

As Wikipedia's nice parallel port article points out, flow-control for computer -> printer is achieved by the printer de-asserting the BUSY pin. The computer can then put the next byte on the data pins and set the STROBE pin with an out to the control register. (The Wikipedia article has pin to register-bit mappings). Then in software you poll until you see the BUSY line go high and then low again.

Stuffing bytes one at a time into an I/O port is called "programmed I/O". It's slow, and uses all your CPU time doing just that.

There are other ways to program the parallel ports in modern (and not-so-modern) computers. For example, ECP is an entirely separate way of programming the same physical parallel port. It can use DMA, so you give the hardware a buffer of bytes and it does the hardware hand-shaking for you, so the CPU can be doing something else instead of polling the parport. Whether or not the printer stores them into its memory or not is a separate question.

---

Technically, the CPU can't even access the parallel port directly; it has to access it via the southbridge. But hardware takes care of that when a CPU core runs an in or out instruction.

---

And BTW, PC parports are bidirectional. Before ethernet was widely available, it was not uncommon to connect two computers with a serial or parallel port to transfer files. (Or use the link for carrying IP packets, as an alternative to ethernet.) Parallel ports (especially with ECP) are much faster than serial (2.5MB/s vs. 115 kbit/s on typical PC hardware). A parallel port is potentially even faster than 10Mbit/s ethernet. I remember doing this on occasion on Linux, since it had good kernel drivers for PLIP.

---

Footnote:

"Direct" copying from local to remote memory (or vice versa) is called Remote DMA (RDMA). It mostly means that hardware takes care of the protocol stuff for starting a copy command, and that no access-control happens on the remote side. (i.e. you can crash the remote side by writing to the wrong memory address.) InfiniBand is one well-known hardware interface associated with RDMA for high-performance computing and/or storage servers.

Firewire controllers also support RDMA. See https://en.wikipedia.org/wiki/DMA_attack for a description in the context of an untrusted device reading/writing host memory it shouldn't.