PPBUS(4)

💖 PPBUS(4) 💖 — Kernel Interfaces Manual, but make it cute

okay bestie, sit down, hydrate, because we're about to talk about the Parallel Port Bus system and it's lowkey a whole vibe. ✨

---

🌸 NAME 🌸

ppbus — the Parallel Port Bus system. that's it, that's the name, she's iconic 💅

---

✨ SYNOPSIS ✨

device ppbus

device vpo

device lpt
device plip
device ppi
device pps
device lpbb

look at all those little device declarations, they're giving big family energy 🫶

---

🦋 DESCRIPTION 🦋

The ppbus system hands you a uniform, modular, and architecture-independent situation for implementing drivers that control all kinds of parallel devices — and for using all the different parallel port chipsets out there. no cap, it's the friend group that gets along with everybody. 💖

---

🎀 DEVICE DRIVERS 🎀

So if you wanna write brand new drivers, or port the ones that already exist, ppbus has your back with these facilities:

• architecture-independent macros or functions to access parallel ports ✨
• a mechanism so that different devices can share the same parallel port — sharing is caring, bestie 🫶
• a user interface named ppi(4) that lets you access the parallel port from outside the kernel without conflicting with kernel-in drivers 🔥

🌈 Developing new drivers 🌈

The ppbus system was literally designed to support standard and non-standard software development. here's the roster:

• vpo — VPI0 parallel to Adaptec AIC-7110 SCSI controller driver. It uses standard and non-standard parallel port accesses. versatile queen 👑
• ppi — Parallel port interface for general I/O
• pps — Pulse per second Timing Interface ⏱️
• lpbb — Philips official parallel port I2C bit-banging interface

🧚 Porting existing drivers 🧚

Another approach to the ppbus system is to port drivers that already exist. Various drivers have already been ported, so you're in good company:

• lpt — lpt printer driver
• plip — lp parallel network interface driver

And honestly? ppbus should let you port any other software — even stuff from other operating systems that provide similar services. it's giving multilingual, it's giving diplomacy 🌍✨

---

💜 PARALLEL PORT CHIPSETS 💜

Parallel port chipset support is provided by ppc(4). shoutout to ppc, we love her 🎀

The ppbus system gives you functions and macros to allocate a new parallel port bus, then initialize it and the upper peripheral device drivers.

ppc does the chipset detection and initialization, and then it calls the ppbus attach functions to initialize the ppbus system. the way that it hands off the baton… obsessed 🏃♀️💨

---

🌸 PARALLEL PORT MODEL 🌸

The logical parallel port model that was chosen for the ppbus system is the PC's parallel port model. So for the i386 implementation of ppbus, most of the services provided by ppc are just macros for inb() and outb() calls. easy, breezy, beautiful 💅

But heads up — for another architecture, accessing one of our logical registers (data, status, control…) might take more than one I/O access. no drama, just logistics 🙈

⭐ Description ⭐

The parallel port may operate in the following modes:

• compatible mode, also called Centronics mode
• bidirectional 8/4-bits mode, also called NIBBLE mode
• byte mode, also called PS/2 mode
• Extended Capability Port mode, ECP
• Enhanced Parallel Port mode, EPP
• mixed ECP+EPP or ECP+PS/2 modes

six modes, six personalities, all valid 🌈

🖨️ Compatible mode 🖨️

This mode defines the protocol that most PCs use to transfer data to a printer. In this mode, data is placed on the port's data lines, the printer status gets checked to make sure there are no errors and that it isn't busy, and then a data Strobe is generated by the software to clock the data to the printer.

Lots of I/O controllers have implemented a mode that uses a FIFO buffer to transfer data with the Compatibility mode protocol. This mode is referred to as "Fast Centronics" or "Parallel Port FIFO mode". fast and furious but make it printers 💨

🔄 Bidirectional mode 🔄

The NIBBLE mode is the most common way to get reverse channel data from a printer or peripheral. Combine it with the standard host-to-printer mode and boom — you've got a complete bidirectional channel. communication is key, bestie 🫶

In this mode, outputs are 8-bits long. Inputs are accomplished by reading 4 of the 8 bits of the status register. half the bits, twice the drama 💀

🌊 Byte mode 🌊

In this mode, the data register is used for both outputs and inputs. So any transfer is 8-bits long. equal opportunity register, we love to see it ✨

📦 Extended Capability Port mode 📦

The ECP protocol was proposed as an advanced mode for communicating with printer and scanner type peripherals. Like the EPP protocol, ECP mode provides a high performance bidirectional communication path between the host adapter and the peripheral. it's giving main character energy 👑

ECP protocol features include:

• Run_Length_Encoding (RLE) data compression for host adapters
• FIFOs for both the forward and reverse channels
• DMA as well as programmed I/O for the host register interface.

⚡ Enhanced Parallel Port mode ⚡

The EPP protocol was originally developed as a way to provide a high performance parallel port link that would still be compatible with the standard parallel port. glow up without leaving the old friends behind 💖

The EPP mode has two types of cycle: address and data. What makes the difference at the hardware level is the strobe of the byte placed on the data lines. Data are strobed with nAutofeed, addresses are strobed with nSelectin signals. iykyk 😌

A particularity of the ISA implementation of the EPP protocol is that an EPP cycle fits in an ISA cycle. In this fashion, parallel port peripherals can operate at close to the same performance levels as an equivalent ISA plug-in card. no cap, that's actually wild 🔥

At the software level, you may implement the protocol you wish, using data and address cycles however you want. This is for the IEEE1284 compatible part. Then, peripheral vendors may implement protocol handshake with the following status lines: PError, nFault and Select. Try to know how these lines toggle with your peripheral, allowing the peripheral to request more data, stop the transfer, and so on. do your homework, bestie, it pays off 📚✨

At any time, the peripheral may interrupt the host with the nAck signal without disturbing the current transfer. rude? no. iconic? yes. 💅

🧬 Mixed modes 🧬

Some manufacturers, like SMC, have implemented chipsets that support mixed modes. With such chipsets, mode switching is available at any time by accessing the extended control register. commitment issues but make it hardware 😭

---

🌈 IEEE1284-1994 Standard 🌈

📖 Background 📖

This standard is also named "IEEE Standard Signaling Method for a Bidirectional Parallel Peripheral Interface for Personal Computers". a whole mouthful, we know 🙈

It defines a signaling method for asynchronous, fully interlocked, bidirectional parallel communications between hosts and printers or other peripherals. It also specifies a format for a peripheral identification string and a method of returning this string to the host outside of the bidirectional data stream. sneaky but organized ✨

This standard is architecture independent and only specifies dialog handshake at the signal level. One should refer to architecture specific documentation in order to manipulate machine dependent registers, mapped memory, or other methods to control these signals. do your own research for the machine-specific bits 🔍

The IEEE1284 protocol is fully oriented with all supported parallel port modes. The computer acts as master and the peripheral as slave. the computer is the main character, sorry not sorry 👑

Any transfer is defined as a finite state automaton. It allows software to properly manage the fully interlocked scheme of the signaling method. The compatible mode is supported "as is" without any negotiation because, well, it's compatible. Any other mode must be firstly negotiated by the host to check that the peripheral supports it, and then to enter one of the forward idle states. consent first, transfer later 🫶

At any time, the slave may want to send data to the host. This is only possible from forward idle states (nibble, byte, ecp…). So, the host must have previously negotiated to permit the peripheral to request transfer. Interrupt lines may be dedicated to the requesting signals to prevent time consuming polling methods. nobody has time for polling, bestie ⏰

But peripheral requests are only a hint to the master host. If the host accepts the transfer, it must firstly negotiate the reverse mode and then start the transfer. At any time during reverse transfer, the host may terminate the transfer, or the slave may drive wires to signal that no more data is available. boundaries! we love boundaries! 💜

🛠️ Implementation 🛠️

IEEE1284 Standard support has been implemented at the top of the ppbus system as a set of procedures that perform high level functions like negotiation, termination, and transfer in any mode — all without bothering you with the low level characteristics of the standard. they handle the drama so you don't have to 💅

IEEE1284 interacts with the ppbus system as little as possible. That means you still have to request the ppbus when you want to access it — the negotiate function does not do it for you. And of course, release it later. you gotta ask nicely and then say thank you 🎀

---

🏗️ ARCHITECTURE 🏗️

🧱 adapter, ppbus and device layers 🧱

First, there is the adapter layer, the lowest of the ppbus system. It provides chipset abstraction through a set of low level functions that map the logical model to the underlying hardware.

Secondly, there is the ppbus layer that provides functions to:

1. share the parallel port bus among the daisy-chain like connected devices
2. manage devices linked to ppbus
3. propose an arch-independent interface to access the hardware layer.

Finally, the device layer gathers the parallel peripheral device drivers. three layers, three aesthetics, all serving looks 🌈

🔀 Parallel modes management 🔀

We have to differentiate operating modes at various ppbus system layers. Actually, ppbus and adapter operating modes on one hand — and for each one, current and available modes are separated. yes, keep them separate, they need their space 🙈

With this level of abstraction, a particular chipset may commute from any native mode to any other mode emulated with extended modes without disturbing upper layers. For example, most chipsets support NIBBLE mode as native and emulated with ECP and/or EPP. flexible, adaptable, thriving 🦋

This architecture should support IEEE1284-1994 modes. periodt. 💅

---

✨ FEATURES ✨

okay bestie, here's the fun part — what this whole thing actually does 💖

🌸 The boot process 🌸

so it all kicks off with the probe stage of the ppc(4) driver, during ISA bus (PC architecture) initialization. iconic, honestly.

when the ppc driver attaches, a brand new ppbus structure gets allocated — main character allocation moment — and then probe and attachment for this new bus node are called. that's the whole ritual, no cap.

ppbus attachment then tries to detect any PnP parallel peripheral (per the Plug and Play Parallel Port Devices draft from (c)1993-4 Microsoft Corporation — yes, that Microsoft, 1993-4, we're going vintage 💅), and then it probes and attaches known device drivers.

and during probe? device drivers are supposed to request the ppbus and try to set their operating mode. that mode gets saved in the context structure and handed back every single time the driver asks for the ppbus again. lowkey a whole memory-keeping situation, we love consistency 🫶

💅 Bus allocation and interrupts 💅

ppbus allocation is mandatory, fr fr — if you don't do it, you'll corrupt the I/O of other devices. not a vibe. you can also use ppbus allocation to reserve the port and receive incoming interrupts. two-for-one deal ✨

high level interrupt handlers get connected to the ppbus system thanks to the newbus BUS_SETUP_INTR() and BUS_TEARDOWN_INTR() functions. but — and this is the plot twist 😭 — to attach a handler, drivers must own the bus. so a ppbus request is mandatory to call those functions at all (go look at the existing drivers for more info, iykyk).

cute little bonus detail: the interrupt handler is automatically released when the ppbus is released. self-cleaning, we stan a low-maintenance queen 👑

🦋 Microsequences 🦋

microsequences = a general purpose mechanism that lets you do fast low-level manipulation of the parallel port. they can be used for either standard transfers (in IEEE1284 modes) or non-standard transfers, dealer's choice 💫

the philosophy here? avoid the overhead of the ppbus layer and do most of the job at adapter level. efficiency queen energy, periodt.

a microsequence is an array of opcodes and parameters. each opcode codes an operation (and all the opcodes are described over in microseq(9) if you wanna go read them, bestie). standard I/O operations are implemented at ppbus level, whereas basic I/O operations and the microseq language are coded at adapter level for efficiency. slay 💅

as an example — the vpo(4) driver uses microsequences to implement:

• a modified version of the NIBBLE transfer mode
• various I/O sequences to initialize, select and allocate the peripheral

literally so much heavy lifting going on in there and nobody says thank you 😭

---

👀 SEE ALSO 👀

• lpt(4)
• plip(4)
• ppc(4)
• ppi(4)
• vpo(4)

go read those too, they're all part of the same friend group 🌈

---

🎀 HISTORY 🎀

the ppbus manual page first appeared in FreeBSD 3.0. a classic. a legend. an icon 💖

---

🫶 AUTHORS 🫶

this manual page was written by Nicolas Souchu. thank you for your service king 👑

---

and that's the whole page, bestie!! 💖✨ this one's the Debian edition of PPBUS(4), dated March 1, 1998 — yes, 1998, before some of us were even born, and it's still out here doing its thing. mwah, love that for us 🎀🦋💅