Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
GetNetWise: You
e One Click Away

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> The Computer Itself

· The Expansion Bus
· Industry Standard Architecture ISA
· MCA
· Extended Industry Standard Architecture EISA
· The Small Computer Systems Interface SCSI
· Termination
· PCI
· AGP

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Recommend Us
Surveys

Features
HOWTOs
News
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 197 guest(s) and 1 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  
Linux Tutorial - The Computer Itself - The Expansion Bus - Industry Standard Architecture ISA
  The Expansion Bus ---- MCA  


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

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

Table -2 Default Interrupts

IRQDevice
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.

 Previous Page
The Expansion Bus
  Back to Top
Table of Contents
Next Page 
MCA


MoreInfo

Test Your Knowledge

User Comments:


You can only add comments if you are logged in.

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.
  
Help us cut cost by not downloading the whole site!
Use of automated download sofware ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and therefore is expressedly prohibited. For more details on this, take a look here

Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
You can choose larger fonts by selecting a different themes.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

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

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.18 Seconds