The following primarily relates to implementtion of disk access on personal computers (PC-clones) using the ATA-API protocol. Many of the issues noted would require similar adjustments on other architectures.

The original Host Bus Adaptor(HBA) was designed to interface ATA-ATAPI devices, primarily hard drives, to the system bus by extending the neccessary AT bus signals/traces using a pair of complementary interfaces, the HBA on the mother board, and the logic circuits on the device.

This split implementation allowed updating the drives, magnetic or optical, without having to replace the adaptor itself. Or moving drives to a new system, without also having to move the adaptor.

The original AT controller protocol provided for 4 memory mapped port ranges for controllers. Each controller was able to control 2 drives. This allowed for 8 drives total. Although in most implementations, PC manufacturers only implemented the 1st two controllers/ranges.

Drives connected to a particular controller/port range were jumpered to be the either master (drive 0) or slave (drive 1). These 2 drives shared a bus connection, usually a 40 or 80 trace ribbon cable. Although termed master and slave, both drives received all data placed on the bus. Based on the jumper configuration and 'cable select' signal, only one of the drives dealt directly with the host controller during a transaction.

The ATA-API protocol and parallel interface design initially offered a variety of improvements over previous drive interfaces. New versions of the ATA-API protocol were released as technology improved. However, the parallel ribbon design limited the maximum throughput.

With the introduction of ATA-API 7, the ability to use a seriel interface (SATA) and packetized signal transfers to interface with a device, hard drive or other storage device, provided a path to much higher data throughput.

However, as with any technological advance, legacy practices and investment created an impedement to the advance. In order to provide minimal disruption, SATA is implemented between the host bus adaptor and the device and is, for the most part, invisible to the OS and device drivers on the system side, and to the device logic on the drive device itself.

SATA implements a serial point to point dedicated connecton to each drive.

This is where AHCI comes in. Because the legacy HBA on PCs only recognized 4 pair of drives (0 and 1), the SATA implementation on a PC had to emulate this drive 0, drive 1 pairing even though each device had a dedicated connection. You may notice that SATA ports, on the mother board, are often paired and often color coded. And this limits the number of devices to 8.

The original HBA implemented a dedicated buffer/memory area, this is the memory mapped port area. There is a single buffer per drive/ribbon interface, because only one drive could be accessed at a time. This limited throughput and it also greatly restricted the ability of RAID implementation to RAID 0 and 1.

AHCI is designed to get around these limits.

AHCI treats each SATA interface as its own. This means each interface gets its own register buffer.

Register buffers are implemented in main memory, rather than on dedicated storage on the adaptor.

AHCI is capable of intefacing with 32 devices rather than only 8.

Because each interface has its own buffers and direct access to the controller, most primary RAID protocols, 0, 1, 3, 4, 5, 6, can be implemented.

AHCI is harware implemented and does require an OS that is aware of it. Most current (> 2000) OSes do support AHCI. Because it was not always supported, systems (CMOS) may allow the user to activate or deactivate it. It is strongly suggested that it is activated. A number of OSes will check on install and configure accordingly. If it is off and later activated, the system may fail to boot.

Many of the newest systems do not offer the chance to use a legacy HBA.