|
Written by Tuan "Solace" Nguyen Monday, October 23, 2000
|
|
|
|
|
|
Page 1 of 3 Introduction
Before we begin, if you have questions on how something in or around your computer works, feel free to jump to our Articles section. There you’ll find a handful of How It Works articles explaining some of the most asked about hardware devices.
This time around instead of addressing questions about how a piece of hardware physically works, we’re going to address something a little more digital.
Have you ever wondered how information from one device travels to another device in your system? Have you ever purchased a hard drive and wondered what PIO mode or DMA mode is? Well Tweak3D is where you’re going to find answers. Let’s take a look at how PIO and DMA work.
PIO Mode Transfer
The data transfer method requiring the least amount of hardware is called Programmed input/output or PIO. PIO was used by the WD1003, the hard disk controller used by the first PC/AT. PIO employs the CPU to move data between the peripheral controller card and the computer's memory. The 80286, 80386 and 80486 microprocessors used in PCs are well suited to this task since they can move blocks of data with a single String Move instruction. This fast data move instruction allows PIO transfers to reach speeds of about 2.5 Mbytes/sec.
While not in use anymore, PIO mode transfers were used in older hard drives back a few years ago when DMA and UltraDMA mode transfers didn’t exist. This is true for CD-ROM drives too. Let’s take a look at how PIO mode would work if you were copying information from your CD’s to your hard drive.

First the data is read from your CD and sent down the IDE bus into the controller. From there the data is retrieved by the CPU and stored into its registers. Registers are allocation units inside a processor that stores data to be executed and processed. From there, instructions stored in software (either in BIOS or Operating System) dictate which way and how that data is to be used and is then directed into system memory to be used by other devices.
This is called Programmed I/O because programmable software instructions can command data from a peripheral device into the appropriate data path. At first this seems like a swell idea because of the control but because the CPU is the middleman in the dataflow, it slows down traffic. Of course, if you have a burly CPU, you don’t really notice any slowdown but that’s because you haven’t experienced DMA.
A typical path for let’s say, CD data to get from your reader to your hard drive is:
Reader > IDE Controller > CPU > System RAM > CPU > IDE Controller > hard drive.
That’s a lot of steps! This is very inefficient and there is a better way of transferring data to and from devices. The same condition would hold true for information that is already stored in system memory and needs to be directed to some device.
Using PIO mode transfer, a packet or segment of data that needs to be transferred is associated with specific instructions that are coded in software. A set of command and direction instructions is used to send data a device to the CPU and back. Furthermore, if you wanted the data to be transferred to system memory, more instructions are needed. Since all this data transferring is done by software programmed instructions, the CPU must monitor what is going on and that takes a toll on CPU cycles too. Some of the things that the CPU needs to monitor are whether a transfer can take place between what device and it needs to check whether or not the device sending the data is ready for I/O data.
One way to alleviate stress from the CPU is to use the I/O controller. The I/O controller will do all the necessary controlling and commanding of peripheral devices and will only rely on the CPU on special conditions such as “go ahead” signals. The I/O controller can request CPU attention by using an IRQ or Interrupt Request.
The following is how data would be transferred on a system using PIO mode transfer on its hard drives.
The PIO protocol used by the original WD1003 controller, as well as today's IDE drives, was originally designed for low-end DOS environments. With this protocol, once the CPU has given a command to the disk controller, it waits for an interrupt from the controller indicating that one 512-byte sector can be transferred. When the interrupt is received, the CPU executes a String Move instruction to move the data between the system RAM and the controller's sector buffer. The String Move instruction executes a tight loop of microcode within the CPU chip, moving one 512-byte sector in 256 16-bit operations. If the disk read or write command is for multiple sectors, the CPU then waits for another interrupt before transferring the next sector. One interrupt will occur for each 512-byte sector transferred.
IRQ levels let a device in your system interrupt your processor from what it is currently doing and direct its attention to something else (the device that asked for the interrupt). After the job is finished the CPU returns to whatever tasks it was doing before.
|
|
|