Industry Standard Architecture ISA

Industry Standard Architecture ISA

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 8259A Programmable Interrupt Controller, or PIC.

On newer machines the 8259A PIC has been replaced by the Advanced Programmable Interrupt Controller (APIC) such as the 82489DX or the 82093AA. In fact, Microsoft when so far as to make the APIC a required of the PC 2001 design specification. One importance difference between the two is that the APIC allows for a much more complex priority scheme, which is particularly important on system with multiple processes. Originally, SMP capable systems had a proprietary interrupt mechanism. This was then standardized by the implementation of the APIC.

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 (2×8-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.

Table 0-2 contains a list of the standard interrupts.

Table -2 Default Interrupts

0 System timer
1 Keyboard
2 Second level interrupt
3 COM 2
4 COM 1
5Printer 2
6 Floppy
7Printer 1
8 Clock
9 Not assigned
10 Not assigned
11 Not assigned
12 Not assigned
13 Math coprocessor
14 Hard Disk
15 Hard Disk

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 interrupt signal 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.