As I mentioned before,
most people are generally aware of the relationship between
CPU performance and system performance. However, every
system is only as strong as its weakest component. Therefore, the expansion
bus also sets limits on the system performance.

There were several drawbacks with the original expansion
bus in the original IBM PC. First, it was limited to only 8
data lines, which meant that only 8 bits could be transferred at a time.
Second, the expansion bus was, in a way, directly connected
to the CPU. Therefore, it operated at the same speed as
the CPU, which meant that to improve performance with the CPU, the expansion bus
had to be altered as well. The result would have been that existing expansion
cards would be obsolete.

In the early days of PC computing, IBM was not
known to want to cut its own throat. It has already developed quite a following
with the IBM PC among users and developers. If it decided to change the design
of the expansion bus, developers would have to re-invent
the wheel and users would have to buy all new equipment. There was the risk that
users and developers would switch to another platform instead of sticking with
IBM.

Rather than risk that, IBM decided that backward compatibility was
a paramount issue. One key change was severing the direct connection between
the expansion bus and CPU. As a
result, expansion boards could operate at a different speed than the CPU,
enabling users to keep existing hardware and enabling manufacturers to keep
producing their expansion cards. As a result, the IBM standard became the
industry standard, and the bus architecture became known as the Industry
Standard Architecture, or ISA.

In addition to this
change, IBM added more address and data lines. They doubled
the data lines to 16 and increased the address lines to 24. This meant that the
system could address up to 16 megabytes of memory, the maximum that the 80286
CPU (Intel's newest central processor at the time) could
handle.

When the 80386 came out, the connection between the
CPU and bus clocks were severed
completely because no expansion board could operate at the 16MHz or more that
the 80386 could. The bus speed does not need to be an exact fraction of the CPU
speed, but an attempt has been made to keep it there because by keeping the bus
and CPU synchronized, it is easier to transfer data. The CPU will only accept
data when it coincides with its own clock. If an attempt is made to speed the
bus a little, the data must wait until the right moment in the CPUs clock cycle
to pass the data. Therefore, nothing has been gained by making it faster.

One method used to speed up the transfer of data is
Direct Memory Access, or
DMA. Although DMA existed in the IBM
XT, the ISA-Bus provided some extra lines. DMA enables the system to move data
from place to place without the intervention of the CPU.
In that way, data can be transferred from, lets say, the hard disk to memory
while the CPU is working on something else. Keep in mind that to make the
transfer, the DMA controller must have complete control of both the data and the
address lines, so the CPU itself cannot access
memory at this time. What DMA access looks like graphically we see in Figure
0-1.

Image -
Direct Memory Access (interactive)

Lets step back here
a minute. It is somewhat incorrect to say that a DMA
transfer occurs without intervention from the CPU, as it is
the CPU that must initiate the transfer. Once the transfer is started, however,
the CPU is free to continue with other activities. DMA controllers on ISA-Bus
machines use "pass-through" or "fly-by" transfers. That is, the data is not
latched or held internally but rather is simply passed through the controller.
If it were latched, two cycles would be needed: one to latch into the DMA
controller and another to pass it to the device or memory (depending on which
way it was headed).

Devices tell the DMA controller
that they wish to make DMA transfers through one of three "DMA Request" lines,
numbered 13. Each of these lines is given a priority based on its number, 1
being the highest. The ISA-Bus includes two sets of DMA controllers: four 8-bit
channels and four 16-bit channels. The channels are labeled 07, 0 having the
highest priority.

Each device on the system capable of doing
DMA transfers is given its own DMA channel. The channel is
set on the expansion board usually by means of jumpers. The pins to which these
jumpers are connected are usually labeled DRQ, for DMA Request.

The two
DMA controllers (both Intel 8237), each with four DMA
channels, are cascaded together. The master DMA controller is the one connected
directly to the CPU. One of its DMA channels is used to
connect to the slave controller. Because of this, there are actually only seven
channels available.

Everyone who has had a baby knows what an
interrupt-driven operating system like Linux goes through
on a regular basis. Just like a baby when it needs its diaper changed, when a
device on the expansion bus needs servicing, it tells the
system by generating an interrupt (the baby cries). For
example, when the hard disk has transferred the requested data to or from
memory, it signals the CPU by means of an interrupt. When
keys are pressed on the keyboard, the keyboard interface also generates an
interrupt.

On receiving such an interrupt, the
system executes a set of functions commonly referred to as an
Interrupt Service Routine, or ISR.
Because the reaction to a key being pressed on the keyboard is different from
the reaction when data is transferred from the hard disk, there needs to be
different ISRs for each device. Although the behavior of ISRs is different under
DOS than UNIX, their functionality is
basically the same. For details on how this works under Linux, see the chapter
on the kernel.

On the CPU,
there is a single interrupt request line. This does not
mean that every device on the system is connected to the CPU via this single
line, however. Just as a DMA controller handles DMA
requests, an interrupt controller handles interrupt requests. This is the Intel
8259 Programmable Interrupt Controller, or PIC.

On
the original IBM PC, there were five "Interrupt Request" lines, numbered 27.
Here again, the higher the number, the lower the priority. (Interrupts 0 and 1
are used internally and are not available for expansion cards.)

The
ISA-Bus also added an additional PIC, which is "cascaded"
off the first PIC. With this addition, there were now 1615
interrupt values on the system (2x8-1 because the second is
cascaded of the first). However, not all of these were available to devices.
Interrupts 0 and 1 were still used internally, but so were interrupts 8 and 13.
Interrupt 2 was something special. It, too, was reserved for system use, but
instead of being a device of some kind, an interrupt on
line 2 actually meant that an interrupt was coming from the
second PIC, similar to the way cascading works on the
DMA controller.

A question I brought up when I
first started learning about interrupts was "What happens when the system is
servicing an interrupt and another one comes in?" Two
mechanism can help in this situation .

Remember that the 8259 is a
"programmable" interrupt controller. There is a machine
instruction called Clear Interrupt Enable, or CLI. If a program is executing
what is called a critical section of code (a section that should not be
stopped in the middle), the programmer can call the CLI instruction and disable
acknowledgment of all incoming interrupts. As soon as the critical section is
finished and closed, the program should execute a Set Interrupt Enable, or STI,
instruction somewhat shortly afterward.

I say "should" because the
programmer doesn't have to do this. A CLI instruction could be in the middle of
a program somewhere and if the STI is never called, no more interrupts will be
serviced. Nothing, aside from common sense, prevents the programmer from doing
this. Should the program take too long before it calls the STI, interrupts could
get lost. This is common on busy systems when characters from the keyboard
"disappear."

The second mechanism is that the interrupts are priority
based. The lower the interrupt request level, or
IRQ, the higher the priority. This has an interesting side
effect because the second PIC (or slave) is bridged off the first
PIC (or master) at IRQ2. The interrupts on the first PIC
are numbered 07, and on the second PIC the interrupts are
numbered 8-15. However, the slave PIC is attached to the master at
interrupt 2. Therefore, the actual priority is 0, 1, 8-15,
3-7.

There's one thing you should consider when dealing with interrupts.
On XT machines, IRQ 2 was a valid
interrupt. Now on AT machines, IRQ 2 is bridged to the
second PIC. So, to ensure that devices configured to IRQ 2
work properly, the IRQ 2 pin on the all the expansion slots are connected to
the IRQ 9 input of the second PIC. In addition, all the devices attached to the
second PIC are associated with an IRQ value where they are attached to the PIC,
and they generate an IRQ 2 on the first PIC.

The PICs on an
ISA machine are edge-triggered, which
means that they react only when the interruptsignal is making the transition from low to high, that is,
when it is on a transition edge. This becomes an issue when you attempt
to share interrupts, that is, where two devices use the same interrupt.

Assume you have both a serial port and floppy controller at
interrupt 6. If the serial port generates an interrupt, the
system will "service" it. If the floppy controller generates an interrupt before
the system has finished servicing the interrupt for the serial port, the
interrupt from the floppy is lost. There is another way to react to interrupts
called "level triggered," which I will get to shortly.

As I mentioned
earlier, a primary consideration in the design of the AT Bus (as the changed
PC-Bus came to be called) was that its maintain compatibility with it
predecessors. It maintains compatibility with the PC expansion cards but takes
advantage of 16-bit technology. To do this, connectors were not changed, only
added. Therefore, you could slide cards designed for the 8-bit PC-Bus right into
a 16-bit slot on the ISA-Bus, and no one would know the difference.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved. The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use
and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look
here