Skip to content
FreeDOSDeep Dive Published Updated 6 min readViews unavailable

FreeDOS and IEEE 1284 ECP: FIFO Modes, Register Ownership, and DMA Boundaries

A chipset-scoped FreeDOS guide to IEEE 1284 ECP negotiation, FIFO modes, register ownership, DMA constraints, and safe hardware triage.

Enhanced Capability Port (ECP) is not a faster spelling of the original PC printer handshake. It combines IEEE 1284 negotiation, direction changes, hardware FIFO behavior, and optional DMA. A DOS program that writes the familiar data register may be using only the Standard Parallel Port (SPP) path, even when the Super I/O controller supports ECP. Conversely, changing a controller into an ECP mode without coordinating the attached peripheral can change the meaning of the same port offsets and control signals.

This is a hardware-level, chipset-scoped guide for FreeDOS developers and maintainers. It is not a claim that FreeDOS exposes one portable ECP programming API, or that every LPT connector, cable, BIOS, or peripheral supports ECP. For any USB printer adapter, do not assume it exposes PC-style port registers unless its vendor documentation confirms that interface. The register example below uses Microchip’s SCH5127 datasheet as one chipset-specific architecture reference, not as a recommendation to source that chip.

Establish the device before touching the ports

First identify the actual adapter and the I/O base, mode, IRQ, and DMA resources assigned by firmware or the board’s configuration utility. Do not hard-code 0x378 merely because it is a conventional LPT address. Super I/O configuration can move or disable a port, and a machine may not have a legacy parallel interface at all.

The SCH5127 datasheet places its Extended Control Register (ECR) at parallel-port base + 0x402, and its ECP data FIFO at base + 0x400 when ECP mode is selected. The ECR’s bits 7:5 select the mode on this controller. In its table, 000 is SPP, 001 is bidirectional PS/2 mode, 011 is ECP, and 100 is EPP only if the configuration option is enabled. 101 is reserved. These values are not a universal register contract for every Super I/O chip: the device’s own datasheet and configuration state are authoritative.

In ECP mode, the SCH5127 maps the address/RLE FIFO at base + 0x000 and the data FIFO at base + 0x400. The same offsets have different functions in other modes. Its datasheet explicitly states that operation in modes other than those defined for a register is undefined. A driver should therefore track mode as owned state, not treat each offset as a permanent alias for an SPP register.

Negotiation and direction are part of the protocol

For the documented SCH5127 sequence, software first performs IEEE 1284 negotiation in a compatible mode under programmed I/O. ECP hardware takes over the automatic handshake while data moves through the FIFO; the host still owns negotiation and the mode transitions around that data phase. The controller documentation describes setting the forward direction and the required control-line state before entering ECP mode.

The data path is asymmetric. In the forward direction, writes to the data FIFO are transmitted by the controller, and address/RLE bytes use the address FIFO. Reverse transfers fill the data FIFO from the peripheral. The controller’s documented transition rules permit changing direction only in mode 001: switch to that mode, negotiate the channel, set direction, then return to ECP mode. Do not flip a direction bit while still in ECP mode because it appears convenient.

Termination also has a state contract. For a forward transfer, the documented controller requires the FIFO to be empty before returning to SPP or bidirectional mode. For reverse traffic, consume buffered bytes and transition back through the permitted mode and direction sequence. Switching modes with unread bytes or a half-finished handshake can discard data or leave the peripheral and host disagreeing about bus state.

Choose programmed I/O or DMA deliberately

ECP does not require every transfer to use DMA. The SCH5127 datasheet describes FIFO transfers through programmed I/O as well as DMA. Programmed I/O is slower but lets a small diagnostic tool avoid claiming an ISA DMA channel. If DMA is used, the host must configure the appropriate PC DMA controller channel, memory address, and transfer count, then coordinate the ECR’s dmaEn and serviceIntr bits. The chip requests transfers through its DMA-request signaling and uses terminal count to complete them.

The Super I/O datasheet cannot tell a FreeDOS program which DMA channel this particular motherboard wired to the LPT function, whether another driver owns it, or which buffer addresses are safe for the platform. Resolve those resources from the actual firmware and hardware documentation. Apply the ordinary ISA DMA constraints only when the system truly uses that DMA path; do not infer them from a printer’s ECP logo. The ECR is not a replacement for a DOS driver, a verified DMA allocation, or the peripheral’s channel negotiation.

A safe bring-up record

Before an experiment, capture a read-only inventory and agree on who owns the interface. A useful lab record looks like this:

Field Record from the target, not from convention
Host controller Chip marking and documented revision
Port base Firmware or controller configuration result
Selected mode Controller configuration and current owner
Peer path Peripheral model, cable, and any bridge
Direction and negotiation Expected IEEE 1284 channel and success/failure evidence
Transfer method Programmed I/O or verified DMA channel and buffer constraints
Recovery Stop transfer, reach a documented idle state, restore prior configuration

Use a spare controller and peripheral for development. Begin with identification and non-destructive status checks. Do not probe a live printer by writing arbitrary values to ECR or FIFO ports; mode bits are read/write control, and FIFO accesses can start transfers. Keep a BIOS/DOS print path for ordinary output and use direct ECP code only when the application truly needs that protocol.

Distinguish protocol failure from a FreeDOS print failure

Debug in layers: the DOS application’s printer-language output, the DOS-visible LPT device, controller assignment, IEEE 1284 negotiation, and the peripheral’s actual mode support. A successful MODE command or an INT 17h status result does not prove that an ECP channel was negotiated. Likewise, an ECP-capable host cannot make an SPP-only cable path behave like this Super I/O interface.

The existing SPP register guide covers the classic compatibility path; this article deliberately moves below that abstraction to one documented ECP-capable controller. Keep that distinction in code, test notes, and bug reports so that a mode mismatch is not “fixed” by changing unrelated IRQs or filesystem settings.

Related:

Sources:

Comments