MS-DOS 6.22 and Real-Mode ISA Network Adapters

This article explains how MS-DOS 6.22 communicates with 16-bit real-mode Industry Standard Architecture (ISA) network interface cards (NICs). Because MS-DOS lacks native networking subsystems and runs strictly in 16-bit real mode, connecting to a network requires direct hardware resource allocation, specialized real-mode device drivers, and intermediate driver specifications like Packet Drivers, NDIS, or ODI to bridge the gap between network applications and physical hardware.

Hardware Resource Allocation on the ISA Bus

The ISA bus does not inherently support the automated configuration found in modern buses. While later ISA cards supported ISA Plug and Play (PnP), classic ISA network cards rely on physical jumpers or software EEPROM utilities to configure three primary hardware resources before MS-DOS boots:

  • I/O Base Address: Typically ranges such as 0x300h or 0x320h. This serves as the command and data exchange window through which the CPU reads and writes to the NIC's internal registers using x86 IN and OUT assembly instructions.
  • Interrupt Request (IRQ): Typically IRQ 3, 5, 10, or 11. When the NIC finishes sending a frame or receives an inbound packet from the wire, it raises this line to signal the CPU via the 8259 Programmable Interrupt Controller (PIC).
  • Base Memory Address (Shared RAM) or DMA: Some high-performance ISA NICs map internal packet buffers into the Upper Memory Area (UMA) between 0xC8000 and 0xEFFFF (such as 0xD000h), allowing real-mode memory-mapped I/O. Others rely on Programmed I/O (PIO) or Direct Memory Access (DMA channels 1 or 3) to move frame buffers between system RAM and card memory.

Real-Mode Memory Constraints and MS-DOS Execution

MS-DOS 6.22 operates within the 1 MB address space of the 8086 architecture. In real mode, programs have direct, unrestricted access to physical memory and hardware registers, but must operate within the constraints of 640 KB of conventional memory.

Because all networking stacks must reside within this footprint, users typically manage memory using HIMEM.SYS (Extended Memory Manager) and EMM386.EXE (Expanded Memory Manager). Network drivers and protocol stacks are commonly loaded into Upper Memory Blocks (UMBs) via DEVICEHIGH in CONFIG.SYS or LH (LoadHigh) in AUTOEXEC.BAT to preserve conventional memory for user applications.

Real-Mode Network Driver Architectures

MS-DOS communicates with the NIC through real-mode software shims. Three primary driver standards facilitate this interaction:

1. Packet Drivers (The Clarkson/Crynwr Standard)

The packet driver standard is the simplest, most lightweight solution for MS-DOS.

  • Mechanism: The driver is loaded as a TSR (Terminate and Stay Resident) executable in AUTOEXEC.BAT. It hooks a software interrupt vector, typically INT 0x60h through INT 0x6Fh.
  • Interaction: Networking software (such as mTCP or WATTCP applications) issues software interrupts to this vector to transmit packets or register a memory buffer to receive incoming frames. The driver manages the ISA card directly, abstracting the physical hardware.

2. NDIS (Network Driver Interface Specification)

Co-developed by Microsoft and 3Com, NDIS 2.0 is the standard used by the Microsoft Network Client for MS-DOS.

  • Components: Requires a protocol manager (PROTMAN.DOS), a hardware-specific Media Access Control driver (e.g., ELNK3.DOS for 3Com EtherLink III), and a protocol stack (such as MS TCP/IP or NetBEUI).
  • Configuration: Configured via CONFIG.SYS and an initialization file named PROTOCOL.INI, which explicitly defines the IRQ, I/O port, and memory windows for the driver.

Developed by Novell for NetWare environments.

  • Components: Uses the Link Support Layer (LSL.COM), a hardware-specific Multiple Link Interface Driver (MLID, such as 3C509.COM), and a transport protocol like IPXODI.COM.
  • Configuration: Configured through a NET.CFG file defining hardware parameters. Like NDIS, it decouples the hardware driver from the protocol engine.

The Packet Transmission and Reception Cycle

The operational lifecycle of a network packet in an MS-DOS 6.22 environment follows a deterministic, synchronous sequence:

  1. Initialization: During boot, the driver executes, reads the card's EEPROM or probed I/O port to confirm hardware parameters, resets the NIC controller, and hooks the designated hardware IRQ vector in the Interrupt Vector Table (IVT).
  2. Transmission: An application passes an Ethernet frame to the driver stack. The driver copies the frame data byte-by-byte (or word-by-word) through the configured I/O port directly to the card's on-board FIFO transmit buffer, or moves it to shared memory. The driver then writes to a command register on the NIC to trigger the physical transmission onto the network cable.
  3. Reception:
    • The NIC receives a frame from the wire, validates the CRC checksum, and stores it in its local buffer.
    • The NIC asserts its assigned ISA IRQ line.
    • The CPU halts current execution and calls the Interrupt Service Routine (ISR) mapped in the IVT by the network driver.
    • The real-mode ISR reads the frame header, copies the packet data from the card's buffer into system RAM, and invokes the protocol layer to process the payload.
    • The driver issues an End of Interrupt (EOI) command to the 8259 PIC and executes an IRET instruction, returning control to MS-DOS.