programmed I/O

Picture making tea by standing at the kettle and staring at it, refusing to do anything else until it boils, then pouring it cup by cup yourself. You are personally present for every step and every drop. Programmed I/O is the computer doing exactly that: the CPU itself drives the whole transfer, byte by byte, watching the device the entire time and never wandering off to do other work until it is finished.

Concretely, the CPU loops. To send data, it reads the controller's status register over and over until the busy bit clears, writes the next byte into the data register, sets the command register's go bit, and repeats for every single byte. To receive, it polls the status register until a byte is ready, then reads the data register, and loops again. There is no helper: the CPU is both the brain and the courier, and it spins in this tight busy-wait loop the whole time, doing nothing useful while it waits for a slow device.

Why it matters: programmed I/O is the simplest scheme to build and is fine for tiny, fast, or one-off transfers, or in very small embedded systems with nothing else to do. But it is terribly wasteful when the device is slow: a CPU that can execute billions of instructions per second is reduced to babysitting a keyboard or a slow serial line, burning cycles in a loop. That waste is exactly why the two other schemes exist — interrupt-driven I/O frees the CPU to work until the device signals, and direct memory access lets a controller move whole blocks without the CPU touching each byte.