MS-DOS 6.22 IPX/SPX Network Card Interaction

MS-DOS 6.22 lacks a native networking stack and relies on modular Terminate-and-Stay-Resident (TSR) software components to communicate with local network interface cards (NICs). By utilizing Novell's Open Data-Link Interface (ODI) architecture or monolithic drivers, the operating system bridges the gap between hardware registers and application-level network requests. This article explains the exact mechanisms, architectural layers, and interrupt calls that allow MS-DOS 6.22 to send and receive data over a local network using the IPX/SPX protocol suite.

The Network Layer Architecture in MS-DOS

Because MS-DOS operates in real mode with single-tasking constraints, networking functionality is injected into memory at boot time via CONFIG.SYS and AUTOEXEC.BAT. The interaction between the operating system, the IPX/SPX protocols, and the physical network card generally follows the Novell ODI model, which separates the hardware driver from the protocol stack using three distinct tiers:

  1. Hardware Driver (MLID): The Multiple Link Interface Driver (e.g., NE2000.COM, 3C509.COM) communicates directly with the physical network card.
  2. Link Support Layer (LSL): Handled by LSL.COM, this acts as an intermediary routing switch between the network card driver and multiple protocol engines.
  3. Protocol Engine: Handled by IPXODI.COM, this layer manages Internetwork Packet Exchange (IPX) and Sequenced Packet Exchange (SPX) formatting, routing, and error checking.

(Note: Older configurations used a monolithic IPX.COM generated via Novell’s WSGEN or SHGEN utilities, which hardcoded the specific NIC driver and its hardware parameters directly into the protocol stack, bypassing the LSL layer entirely.)

Hardware Initialization and Port Access

Communication begins with the MLID interacting with the physical network card over the system bus (typically ISA or PCI). When loaded, the driver uses configuration settings defined in a file named NET.CFG:

  • I/O Port Base: (e.g., 0x300) The memory-mapped I/O registers through which DOS sends read and write commands to the card.
  • Interrupt Request (IRQ): (e.g., IRQ 3 or IRQ 5) The hardware line asserted by the NIC when incoming network frames are ready to be read.
  • Base Memory/DMA: Memory buffer addresses used by the card to transfer packet data directly to system RAM without excessive CPU overhead.

The MLID writes to the NIC’s command registers to place the card in a receiving state, configuring its MAC address filters and media type (such as 10BASE-T or 10BASE2 Coaxial).

Packet Transmission Flow

When a DOS application (such as a multi-node database, network utility, or multiplayer game) wants to send an IPX packet, the flow proceeds as follows:

  1. Application Interface: The program accesses the IPX stack directly via software interrupt INT 7Ah or through higher-level redirectors (such as Novell’s NETX.EXE or VLM.EXE via INT 21h).
  2. Buffer Preparation: The application populates an Event Control Block (ECB) and an IPX Header structure in conventional memory, specifying the destination network, node (MAC address), and socket number.
  3. Protocol Processing: IPXODI.COM calculates checksums, sets packet transport controls, and passes the formatted frame down to LSL.COM.
  4. Driver Passing: LSL.COM hands the frame to the specific MLID associated with the target network adapter.
  5. Hardware Dispatch: The MLID copies the packet bytes into the NIC's on-board ring buffer via I/O instructions (OUT operations) or shared memory transfer, then toggles the NIC’s transmit bit to send the raw Ethernet frame onto the physical wire.

Packet Reception Flow

The receiving process is event-driven through hardware interrupts:

  1. Hardware Assertion: The NIC receives a valid frame, stores it in its local buffer, and asserts its assigned IRQ line.
  2. Interrupt Service Routine (ISR): The CPU suspends the current DOS task and executes the MLID's ISR.
  3. Packet Retrieval: The driver queries the NIC to determine the packet size, reads the data out of the NIC buffer using IN CPU instructions or DMA, and passes it upward to LSL.COM.
  4. Protocol Demultiplexing: LSL.COM inspects the frame's EtherType or IEEE 802.2/802.3 packet header. Identifying it as IPX (typically frame type ETHERNET_802.2 or ETHERNET_802.3), it transfers the frame to IPXODI.COM.
  5. Completion Notification: IPXODI.COM locates the listening socket, copies the packet payload into the application's waiting memory buffer, marks the associated ECB as complete, and returns control to the primary DOS execution thread.