Introduction to IDE ------------------- IDE = "Integrated Drive Electronics". This name is a reference back to the days when drive controller (on board the mainboard or an interface card) communicated at a very low level to drives, signalling to step heads inwards/ outwards and the like. IDE does away with that and introduces a higher level communication between the controller and the drive. The drive is more intelligent and can accept orders such as "read data from a sector". Primary "competition" to IDE is SCSI (small computer systems interface?). The main differences are that SCSI supports chaining several devices of one controller and running commands in parallel. IDE supports only two devices on a controller, one "Master" and the other "Slave". It's worth noting that the drive electronics in a SCSI drive are integrated as well. (Note, I don't know much about SCSI). The term ATA is also used when talking about IDE. There is also the ATAPI, "ATA Packet Interface" which is essentially a way of encapsulating SCSI commands over the ATA (IDE) interface, normally used for CD-ROM drives rather than disk drives (which support standard IDE commands). When two devices are attached to one IDE controller, only one can be actively executing a command at any given moment. Thus it is generally better to stick to only one device per controller if possible. Technically, a single device should be configured as a "Master" device (normally done by moving a jumper pin on the hardware itself) but in practice it is common to see some drive stuck on a cable by itself but configured as "Slave", especially in the case of CD-ROM drives. Many drives also have a "Cable Select" setting which determines Master/Slave status according to the position on the cable. A certain cable type is required for this. I'm not sure if the cables are common; I always configure directly as Master or Slave and steer clear of Cable Select. It's unusual for controllers to exist as a single entity (supporting two drives). Most IDE chipsets offer two interfaces, thereby supporting up to four devices; from a programming point of view they look like two seperate controllers. Transfer modes -------------- There are various transfer modes between the controller and the drive. Presumably the data is transferred using different timing,signalling on the wires. To be able to use any particular mode both the drive and the controller must support that mode. There are PIO modes (numbered). Higher is better? DMA modes. UDMA modes ("Ultra-DMA"). - UDMA-33, -66, -100. UDMA-66 requires an 80 pin IDE cable? Presumably -100 does also. PIO = Programmed Input/Output. In these modes the data is sent to the host a byte at a time and read in software via an IO port, a byte or word at a time. DMA = Direct Memory Access, as used in various other types of device, this allows a large chunk of data to be transferred with only a single interrupt generated at the end. Using the right mode results in a significant speedup (I've seen > 4X improvement). I'd like to know more about this stuff. Serializing of commands ----------------------- As mentioned before only one drive (of two on an interface) can be executing a command at any one time. Therefore commands to the two seperate drives must be "serialized" (ie. two request queues effectively merged into one). Serialization is sometimes necessary across multiple interfaces, for instance with system buses that don't properly support IRQ sharing (eg. ISA, due to the use of level triggered interrupt requests), then only one interface using a particular IRQ can be active at any time. Note the PCI bus does support IRQ sharing properly (edge triggered interrupts). Finally, some chipsets which present two interfaces are buggy and commands issued simultaneously to the two different interfaces may cause the controller to become confused, which can lead to misbehaviour including data corruption. So serialization is useful here as well. PCI controllers --------------- The nature of a regular PCI device is to have configurable resource mappings (I/O port ranges, memory ranges etc). However legacy IDE chipsets presented a standard mapping of ports & interrupts. Many "on-board" (embedded in mainboard) PCI chipsets support these legacy mappings and operate in a sort of compatibility mode. On the other hand "100% native mode" chipsets function as a PCI device should. Legacy software would not be able to detect ide interfaces on such chipsets. Tagged Command Queueing (tcq) ----------------------------- Tagged command queueing or TCQ is when multiple commands can be sent to a drive without waiting for previous commands to finish. Each command is sent with a "tag" value and when a command is completed the "tag" value is sent back to the host so that it knows which command. Naturally there is a limit to the number of commands which can be executing simultaneously on a drive. The advantage of using TCQ is (presumably) that the drive can make decisions about which command to execute next based on for instance the current position of the read head. So instead of executing command #1, seeking to some other track to execute command #2 and then seeking back to the original track before executing command #3, the drive could just perform command #1 then #3 and then seek to the other track to do command #2 (ie. we cut out a seek operation). The same sort of benefit could probably be realised in software, but then software doesn't always have an accurate picture of the geometry of the drive. The drive may be internally translating co-ordinates so that what software thinks is on the same track may not actually be so.