Chapter 33. 38. Network Interface Cards
These are the 3 configuration types of Network Interface Cards (NIC):
jumper configurable
software configurable
Plug n Play (PnP)
Jumper configurable cards have physical jumpers that you use to select the IRQ, I/O address, upper memory block, and transceiver types (10BaseT, 10Base2 or 10Base5). Older cards will also allow selecting DMA channel - this was used with XT and 286 PCs.
Software configurable NICs have a proprietary software program that sets the NIC's "internal jumpers". They are usually menu driven, and have an auto configuration mode where the program will attempt to determine the most suitable configuration. These programs are not foolproof: you still need to have a thorough knowledge of the PC's architecture.
Plug n Play NICs will attempt to auto-configure themselves during the boot up sequence --immediately after installation. They also come with a proprietary software program, in case anything goes wrong and you have to manually configure them.
A combination (combo) NIC has the option of connecting to the network using either Twisted Pair (10BaseT), Coax (10Base2) or AUI (Attachment Unit Interface for 10Base5). The NIC can only connect to one medium type at a time: the configuration software allows you to select which medium interface to connect to. Newer NICs will auto detect the cabling type used.
IRQs, DMAs and Base Addresses
When a NIC is configured, you are setting the parameters. These parameters tell the computer network software where to find the adapter (base address), and who is "tapping the CPU on the shoulder" (IRQ). The base address is the pointer to the rest of the world that says: "Here I am at base address xxx!." The IRQ is the "tap on the shoulder" to the CPU that says: "Hey, it's IRQx. I've got something important to say!". The Upper Memory Block is the NIC's BIOS, (actual program in the NIC's ROM). It is set to a free area of memory in the PC's upper memory: this serves to avoid conflicts with other devices (e.g. video cards, internal modems, SCSI drivers, etc.).
IRQ - Interrupt Requests
IRQ is the acronym for Interrupt ReQuest. It is a "tap on the shoulder" to the CPU--by a peripheral card that's plugged into an ISA slot-- to tell the CPU that the peripheral has something to say (also used by both EISA and MCA slots). Common peripherals are modems, NICs, sound cards, SCSI adapters, hard disk controllers, floppy drive controllers, COM ports and printer ports.
An IRQ is a hardware interrupt: there is a physical line run to each of the ISA slots on the motherboard. There are 2 types of ISA slots, 8 bit and 16 bit. The 16 bit consists of the 8 bit slot plus a 16 bit extension slot. There are 8 IRQ (IRQ0-7) lines that run to the 8 bit ISA slot. There are 8 more (IRQ8-15) that run to the 16 bit ISA extension slot. This provides a total of 16 IRQs in a typical ISA-bus PC.
IRQ0 has the highest priority, and IRQ7 the lowest priority. IRQ8-15s have "special" priority; this will now be explained. When IBM introduced the AT computer, they added IRQ8-15. In order to make AT (286) PCs backward-compatible with 8 bit XT (8088) PCs, and to "up" the priority of the new IRQ lines, they cascaded two interrupt controllers. This resulted in IRQ8-15 having the same priority as IRQ2. Priority means if two IRQs are active at the same time, the one with the higher priority is serviced first.
IMPORTANT: An IRQ can be assigned to only ONE active device at a time. If 2 devices share the same IRQ, it's called a CONFLICT. This means that when the IRQ line becomes active, the CPU does not know which device needs to "talk".
For example, a conflict can occur if a modem and a NIC both use IRQ5. When the modem had some information that needed to be passed on to the CPU, it would set IRQ5 to active. The CPU would not know if it should talk to either the NIC or to the modem. The computer may hang, or nothing may happen.
*** IRQ conflicts are the NUMBER 1 source of PC problems! ***
Here is a table that is used as a rule of thumb (guideline) in selecting IRQs for PCs. The IRQs are listed in order of priority (Note that not all IRQ lines go to the card slots).
IRQFunctionPhysical Line ISA BusIRQ0System TimerNoIRQ1Keyboard
ControllerNo-IRQ2Cascaded to IRQ8-15No-IRQ8Real-time clockNo-IRQ9*-Available(IRQ2)
Yes8/16 bitIRQ10NICYes16 bitIRQ11SCSI adapterYes16 bitIRQ12Motherboard mouse/available
Yes16 bitIRQ13Math coprocessorNo-IRQ14Primary IDE controllerYes16 bitIRQ15Secondary IDE controller
Yes16 bitIRQ3Com2/Com4Yes8 bitIRQ4Com1/Com3Yes8 bitIRQ5Sound card/LPT2Yes8 bitIRQ6Floppy drive controller
Yes8 bitIRQ7Parallel port LPT1Yes8 bit
*- IRQ9 appears as if it is IRQ2. Normally, not used because it can cause interesting problems to appear. Is it really IRQ9, or is it the IRQ2 cascaded to IRQ9? Which do you set it to? What if you are using an 8 bit ISA modem in a 16 bit ISA slot? See what I mean....
The preceding table is a rule of thumb or guideline for selecting IRQs for your peripherals. For example, if the PC does not use a SCSI adapter, then IRQ11 is available for use for another NIC card (or another device). Most auto detecting software or operating systems expect to see the IRQs assigned as above.
Standard COM Port Assignment
Note that COM1 (DB9 on the back of the PC) and COM3 share IRQ4. This is allowed as long as only one device is active at a time. This means that if you are running a mouse on COM1, then you cannot use COM3 for an internal modem: you'll run into a conflict.
Some communication packages will allow you to do this, but most will choke or cause flaky operation. A common symptom occurs when you move the mouse and see garbage on your terminal program. COM2 (DB25 on the back of the PC) and COM4 have a similar problem except that most people don't use COM2. It is usually safe to configure an internal modem to COM4. If COM2 is used, it is typically used for either an external modem or a plotter. Usually, both are not active at the same time.
PortIRQFunctionCOM14MouseCOM23Not used or plotter or external modemCOM34Not used
(conflicts with mouse)COM43Not used or internal modem
DMA -Direct Memory Access
DMA stands for Direct Memory Access. This is a method that allows channels to be opened by the peripheral (to read/write directly to memory without going through the CPU). This off-loads some of the work from the CPU to allow it to do more important tasks.
There are 8 DMA channels available in the PC: DMA0-7. They are divided into 8 bit channels and 16 bit channels, based on the 8 bit ISA slot and 16 bit ISA slot. Here is a table that is used as a rule of thumb for selecting DMA channels:
DMAFunctionPhysical LineISA Bus
Channel WidthDMA0AvailableYes16 bit8 bitsDMA1Soundcard
Yes8 bit8 bitsDMA2Floppy Disk controller
Yes8 bit8 bitsDMA3ECP Parallel Port
Yes8 bit8 bitsDMA4* - Not usedNo-16 bitDMA5Soundcard
Yes16 bit16 bitDMA6SCSIYes16 bit16 bitDMA7Available
Yes16 bit16 bit
* - DMA4 is cascaded to the first 8 bit DMA controller, and is not available.
Note: DMA0 is on the 16 bit ISA bus, but is only 8 bits wide.
*** DMA conflicts are the NUMBER 2 source of PC problems! ***
Like IRQs, you are only allowed to assign one DMA channel to an active device at a time. Otherwise, you will have a conflict, and things will not work properly. You may have one DMA channel assigned to two devices ONLY if one device is active at a time.
Base Addresses
Base addresses are also called I/O ports, I/O addresses, I/O port addresses and base ports. They are memory locations that provide an interface between the operating system and the I/O device (peripheral). The peripheral communicates with the operating system through the base address. Each peripheral must have a UNIQUE base address. Standard Base Address assignments (h - hexadecimal):
Base AddressFunction060h + 064hKeyboard controller170h
+ 376hSecondary IDE hard disk controller1F0h
+ 3F6hPrimary IDE hard disk controller220hSound Card2A0hToken Ring
NIC300hEthernet NIC330hSCSI adapter3F2hFloppy Drive
Controller3F8hCOM12F8hCOM23E8hCOM32E8hCOM4378hLPT1278hLPT2
*** Base Address conflicts are the NUMBER 3 source of PC problems! ***
Unfortunately, the above table is only a small part of the Base Addresses used. The base addresses used will depend on what has been installed on the PC.
Legacy NICs
Before installing a legacy (polite way of saying old) NIC, a PC diagnostic program (Checkit or MSD) should be run to determine available IRQs, Base Addresses and UMBs. After determining which IRQs, Base Addresses and UMBs are available, you would configure the NIC (hopefully) to the rule of thumb tables listed previously. In the case of the Upper Memory Block, you would also allocate that memory block using EMM386.EXE in config.sys (x800 block size).
Ex: device=c:\dos\emm386.exe x=C000-C800
This would ensure that EMM386.EXE does not allow any other program, Windows, or TSR from using the same memory block--thus avoiding memory conflicts. This is used as a typical job interviewer's question: "What do you do to config.sys when installing a legacy network card?".
NIC Diagnostic Tools
NICs come with software diagnostic tools that allow you to check the operation of the NIC. They are usually called Internal Diagnostics, Loopback Test and Echo Server Test. The Internal Diagnostics checks the internal hardware on the NIC card. It usually checks about a dozen or more different aspects of the network card (up to the transmit/receive circuitry).
Internal Diagnostics
Loopback Test checks to see if the NIC can transmit and receive data properly. This test is usually applicable to 10Base2 (coax) only, as a BNC TEE with 2 terminations is required. There is no 10BaseT loopback test because you can't terminate at the NIC.
Loopback Test
Note: The first two diagnostic routines are performed while not connected to the physical network. This prevents faulty NICs from disrupting normal network traffic. The last diagnostic routine is the Echo Server, or Network test. Two NICs are required: a known working NIC acts as an Echo Server and the NIC under test is the Echo client. The echo client sends a packet to the echo server, who then echoes the packet back. This is tested on the network, and can be used for any cabling type (not just 10Base2 as per the example).
Echo Server Test
Network Interface Card Drivers
Network Interface Card Drivers are the software interface between the Network Card Hardware/Firmware and the Network Operating System Data Link layer. The Network Card device driver is a device driver loaded in config.sys. The Network Card consists of Firmware and Hardware.
The Firmware is the program stored on the network card's ROM (BIOS), and configuration information stored in E2ROM. The configuration information would be the IRQ, Base Memory Address, Transceiver Type, etc. for the Network Card. The Hardware would be the physical components: ICs, connectors, and so on.
There are basically 3 types of Network Card Drivers:
NDIS
ODI
Packet drivers
NDIS stands for Network Driver Interface Specification. NDIS drivers are used by Microsoft based Network Operating Systems, such as Microsoft LAN Manager, Windows NT, Windows for Work Groups and IBM's OS/2.
ODI stands for Open Datalink Interface. ODI drivers are used by Novell's Network Operating System and Apple.
Packet drivers use software interrupts to interface to the network card. Many non-commercial programs (shareware and freeware) use Crnywr packet driver interfaces.
The three Network Driver Types are not compatible with each other but most Network Operating Systems (Novell, WFWG, etc.) can use either NDIS or ODI. The NOS (Network Operating System) determines which type of Network Driver can be used. Regardless of the Network Driver type used, all have a network device driver loaded into memory during boot up (and a network protocol bound to the network card).
The purpose of the Network Drivers is to decouple the network adapter's device driver from the higher layer protocols. The higher layer protocols can be IPX/SPX for Novell, Netbios for Microsoft, TCP/IP for Unix and so on.
Traditional Network Card Device Driver Problems (pre-1990)
Traditionally (in the old days, circa 1990), the Network Card Device Driver and NOS' Data Link layer were generated as 1 software program--specific to the computer that it was generated on.
For example: with Novell 3.11 and earlier, a special program (called WSGen: workstation generator) was run, that would generate a Workstation Shell. The Workstation Shell would be a software program running as a TSR. The TSR would be a combination of the Network Card Device Driver and Novell's IPX protocol. The Workstation Shell was specific to the computer that it was generated on, and could not be used on another computer. This meant that every PC in a network would need to have its Workstation Shell recompiled with every new version of Novell! In a small network, this would not be a problem, but in large networks (100+ PCs), it becomes a logistic nightmare!
Another problem emerged: the Workstation Shells directly controlled the network card, and were specific to only one NOS. This meant that only one NOS protocol could be run. In Novell's case, the protocol was IPX. Therefore, interconnecting Networks became a major problem.
Still another problem arose when trying to run more than 1 network card in a computer (this is done typically in bridges, routers and servers). The Workstation Shells did not have the provision to easily allow the NOS Protocol to "bind" to more than one Network Card.
The NIDS and ODI Network Card Driver specifications were implemented to address the following specific areas:
Provide a standard separate interface between the Network Card Device Driver and the Data Link Layer.
Allow more than one NOS Protocol to access the Network Card Device Driver.
Allow the NOS to "bind" to more than one Network Card Device Driver.
NDIS Drivers
The NDIS (Network Driver Interface Specification) standard was developed jointly (by Microsoft and 3Com) for implementation in Microsoft's NOS and IBM's OS/2.
The Microsoft implementation of NDIS modifies the config.sys file, autoexec.bat file, and makes two important initialization files: SYSTEM.INI and PROTOCOL.INI.
Microsoft loads the IFSHLP.SYS file as a device driver in the CONFIG.SYS file. The IFSHLP.SYS is the installable file system helper file, and contains the network redirector for the NDIS interface. The LASTDRIVE command (in the config.sys file) identifies (to the operating system) the last available drive that can be used for mapping network drives.
The SYSTEM.INI file contains information similar to the following:
[network]sizworkbuf=1498filesharing=noprintsharing=noautologon=
yescomputername=E237-12lanroot=C:\NETuser name=EBLANCHARDworkgroup=
WORKGROUPreconnect=yesdospophotkey=Nlmlogon=1logondomain=
T217PROJECTpreferredredir=fullautostart=fullmaxconnections=8[network drivers]netcard=
elnk3.dostransport=ndishlp.sys,*netbeuidevdir=C:\NETLoadRMDrivers=
yes[Password Lists]*Shares=C:\NET\Shares.PWLEBLANCHARD=C:\NET\EBLANCHA.PWL
The PROTOCOL.INI file contains protocol-specific information and the virtual network card interface. A typical netbeui NDIS protocol.ini looks like the following:
[network.setup]version=0x3110netcard=ms$elnk3,1,MS$ELNK3,1transport=
ms$ndishlp,MS$NDISHLPtransport=ms$netbeui,MS$NETBEUIlana0=ms$elnk3,1,ms$netbeuilana1=
ms$elnk3,1,ms$ndishlp[protman]DriverName=PROTMAN$PRIORITY=MS$NDISHLP[MS$ELNK3]DriverName=
ELNK3$IOADDRESS=0x300[MS$NDISHLP]
DriverName=ndishlp$BINDINGS=MS$ELNK3[MS$NETBEUI]DriverName=
netbeui$SESSIONS=10NCBS=12BINDINGS=MS$ELNK3LANABASE=0
ODI Drivers
The Open Datalink Interface (ODI) is a software standard developed by Novell and Apple Corporation. It provides a layered approach to comply with the ISO Open System Interconnect (OSI) model --for the Physical, Datalink and Network layers.
The Open Datalink Interface was developed to overcome the several limitations of the previous network interface card driver software. Previous to the ODI standard, each workstation was required to "compile" its own workstation's IPX.COM shell (using Novell's "WSGEN" program, or workstation generation program). This resulted in a single program that contained the network card driver, Datalink interface and Network layer protocol (IPX/SPX: commonly called the "workstation shell").
This approach limited the workstation to 1network card, and only 1 Network layer protocol. Multiple network cards and Network layer protocols were not allowed under "WSGEN".
The ODI standard broke the "workstation shell" into manageable parts that permits multiple network cards and protocols. For example, one workstation/client can have an Ethernet 10BaseT card running IPX/SPX protocols (Novell), and a Farallon Localtalk card for running Appletalk (Macintosh).
A comparison of the ODI standard vs. the OSI Model is shown below:
OSI= Open System InterconnectODI= Open Datalink InterfaceSPX =
Sequenced Packet ExchangeIPX= Internetwork Packet ExhangeLSL =
Link Suppport LayerVLM = Virtual Loadable ModulesMLID =
Multiple Link Interface DriverMSM = Media Support ModuleHSM = Hardware Support Module
Novell Lite (very old and defunct) is Novell's peer-to-peer Network Operating system. Peer-to-peer Networks use DOS's File Allocation Table (FAT), and Novell Lite is no exception (Novell Netware has its own high performance disk operating system). Novell Lite follows Novell's Netware structure for the Network, Datalink, and Physical layers. It is an excellent example of an ODI compliant NOS (Network Operating System). At the Transport layer, it uses peer-to-peer Client and Server software instead of Novell's Netware Transport layer software.
A typical Novell client is loaded from the DOS prompt, or from a STARTNET.BAT file as follows:
SET NWLANGUAGE= ENGLISHLSL.COMLink Support Layer Software3C509.COM3C509
Network Interface Card Driver (MLID) ODI CompliantIPXODIIPX
Network layer protocol driverVLMLoads client software
NET.CFG is the network configuration file used by the above-mentioned files. It is a text file, and contains the following basic section:
Link Driver 3C5X9(NIC drivername)INT 10(IRQ #)PORT 300(Base memory address in hexadecimal)
FRAME Ethernet_802.2(Frame type on Netware 3.12 & newer)
FRAME Ethernet_802.3(Frame type on Netware 3.11 and older)
FRAME Ethernet_II(Frame type used by UNIX)FRAME Ethernet_SNAP
(Frame type used by Appletalk)NetWare DOS Requester
FIRST NETWORK DRIVE = F USE DEFAULTS = OFF VLM = CONN.VLM
VLM = IPXNCP.VLM VLM = TRAN.VLM
VLM = SECURITY.VLM; VLM = NDS.VLM(used for Netware 4.11 NDS services)
VLM = BIND.VLM VLM = NWP.VLM
VLM = FIO.VLM VLM = GENERAL.VLMVLM = REDIR.VLM VLM = PRINT.VLM
VLM = NETX.VLM
Packet Drivers
Packet drivers use software interrupts to identify the network cards to the data link layer. Packet drivers are free software drivers. They were developed to address the problems of running multiple protocols over one network card. NDIS and ODI are proprietary schemes-- that have been developed by 3COM/Microsoft and Novell/Apple respectively--to address this problem.
The Crynwr Software collection of packet drivers are available throughout the Internet. They are free to use, unlike shareware and commercial products.
Advantages:
Run multiple applications across the same board: TCP/IP, NetBIOS, Netware
One board fits all, no buying different boards for different applications.
No more reconfiguring and rebooting to change applications.
Connect to a Novell File Server (or servers) and still run TCP/IP or PC-NFS, or with the Novell systems remaining active and available for file serving and printing.
The Packet Driver acts as a fast and smart secretary, bothering clients only when packets arrive specifically for them.
Software Interrupts
Software interrupts are interrupts generated by software (unlike hardware interrupts that are physical lines running to each device). Software interrupts that are available are 0x60 to 0x66. Table xx-1 lists the software interrupts and their assignments.
The packet drivers are assigned software interrupts to the network interface card during the bootup process (usually in the autoexec.bat file). For a 3c503 card, the autoexec.bat file would have this line:
3c503 0x60 5 0x300
where:
3c509 calls up the packet driver 3c509.com
0x60 is the software interrupt assigned to the NIC
5 is the hardware interrupt of the NIC
0x300 is the I/O address of the NIC
Any network traffic received--or transmitted--from the NIC would be addressed by the software interrupt 0x60. Complete documentation is available from the Crynwr collection under the files. Important files to read are install.doc and packet.doc.
Software Interrupt Assignments
60 -- -- reserved for user interrupt 61 -- -- reserved for user interrupt 62 --
-- reserved for user interrupt 63 -- -- reserved for user interrupt 64 -- -- reserved for user interrupt 65 --
-- reserved for user interrupt 66 -- -- reserved for user interrupt 67 -- -- LIM EMS 68 01 -- APPC/PC 69
-- -- unused 6A -- -- unused 6B -- -- unused 6C -- -- DOS 3.2 Realtime Clock update 6D -- -- VGA
- internal 6E -- -- unused 6F -- -- Novell NetWare 70 -- -- IRQ8 - AT/XT286/PS50+ -
REAL-TIME CLOCK 71 -- -- IRQ9 - AT/XT286/PS50+ - LAN ADAPTER 1 72 -- -- IRQ10 -
AT/XT286/PS50+ - RESERVED 73 -- -- IRQ11 - AT/XT286/PS50+ - RESERVED 74 -- -- IRQ12 -
PS50+ - MOUSE INTERRUPT 75 -- -- IRQ13 - AT/XT286/PS50+ - 80287 ERROR 76 -- -- IRQ14 -
AT/XT286/PS50+ - FIXED DISK 77 -- -- IRQ15 - AT/XT286/PS50+ - RESERVED 78 -- -- not used 79 --
-- not used 7A -- -- Novell NetWare - LOW-LEVEL API 7A -- -- AutoCAD Device Interface 7B --
-- not used 7C -- -- not used 7D -- -- not used 7E -- -- not used7F -- -- HDILOAD.EXE -
8514/A VIDEO CONTROLLER INTERFACE 80 -- -- reserved for BASIC
If this section was helpful, why not donate to further development?