Input and Output Explained
September 7, 2026 • 6 min read
Table of contents
Part of the series:Computers Explained
The last posts built a machine that can compute, remember, and persist, yet one that is deaf, mute, and blind. With no way in and no way out it would be useless. This post covers input/output (I/O)1: devices that cross the machine boundary, plus the two tricks (interrupts and DMA) that let a fast CPU work with slow devices. Drivers and filesystems belong to a future OS series. Here we stay in hardware.
Input devices: bringing the world in
Input devices2 turn the outside world into bits. A keyboard3 is a grid of switches. A controller scans rows and columns many times per second, finds which crossing closed, and reports a position code. Which letter that means (q, upper or lower case) is decided later by software.
An optical mouse4 reports movement, not position. Its sensor photographs the desk thousands of times per second and sends how far the image moved. The machine adds those steps into cursor position. Touch, microphones, and cameras do the same at higher rates: sample the world on a schedule, send numbers.
Real example: press A. The keyboard sends position code 30. Your OS layout turns it into a or A depending on Shift. The hardware never knew letters.
Output devices: carrying bits back out
Output devices5 run the reverse way. A display6 is a grid of pixels. The machine writes color values into a memory region called the framebuffer. The display controller reads it 60 or more times per second and turns each value into light. What you see is memory made visible, refreshed faster than eyes follow.
Audio7 does the same in time. Values for air pressure sit in a buffer, and the audio controller feeds them to a converter tens of thousands of times per second. Miss the schedule and you hear a click. Video forgives a late frame, audio never forgives a late sample.
Real example: move a window and you write new pixels into the framebuffer. The next 60 Hz refresh shows them. Play a song and 44100 samples per second must leave on time or you hear gaps.
Storage and network devices: I/O in disguise
Storage disks from the last post are I/O devices to the CPU. The processor never touches platters or flash directly. It sends commands like “read blocks 100 to 107” and waits for done.
Network devices8 are both directions at once. The same card sends and receives packets. That is why a machine with only Wi-Fi stays fully useful. The network is a universal I/O channel to other machines.
Real example: open a file and the OS sends a read command to the SSD. Load a page and the Wi-Fi card brings packets in while it sends requests out.
Controllers: translators at the border
No CPU speaks keyboard or display natively. A controller9 sits between: it speaks device language on one side and machine language on the other. Keyboard controller scans the matrix. Display controller keeps the refresh rhythm. Storage controller turns commands into seeks or flash writes. Network controller frames bits for wires or radio.
Controllers also offload boring timing work. The CPU says “fetch these sectors” and goes away. The controller does the millisecond by millisecond dance alone.
Real example: your CPU does not blink each pixel 60 times per second. It draws once into the framebuffer. The display controller repaints the screen alone from there.
Buses and ports: the roads and doors
Devices plug in through shared links. A classic bus10 carries address, data, and control between parts. Modern machines use fast point-to-point links like PCIe for speed, but the job is the same: roads with traffic rules.
A port11 is where the road meets the outside: USB-C, HDMI, Ethernet, audio jack. Standards like USB or HDMI define the electric talk so makers interoperate. Plug in a mouse and you join a small network with its own schedule.
Real example: plug a USB drive in. It identifies itself, the host schedules its packets, and files appear. Unplug HDMI and the display controller simply has nowhere to send pixels.
Interrupts: devices that raise their hand
The CPU runs billions of cycles per second. A keystroke arrives a few times per second. Asking every device in a loop (“anything new?”) wastes all attention on silence. That loop is called polling.
An interrupt12 flips it. The device taps the CPU shoulder instead of waiting to be asked.
program running
↓ (interrupt: key pressed)
save registers + rip
↓
jump to handler, read key code
↓
restore registers + rip
↓
program continues, never noticedReal example: press a key while a game runs. The keyboard raises an interrupt, the CPU grabs code 30 in microseconds, queues it, and the game keeps rendering. No polling, no missed press.
DMA: moving data without the CPU
Interrupts fix notification, but bulk is still heavy. Dragging every disk byte through CPU registers wastes the processor. Direct memory access13 fixes it: hardware moves data between device and RAM alone.
The CPU sets source, destination, and size, then does other work. The DMA engine copies in bursts. When done it raises one interrupt: data is there.
Real example: play a 4K video. The SSD streams frames into RAM by DMA while the CPU decodes the last frame. Without DMA the CPU would copy every byte itself and stall.
The big picture
in (keyboard, mouse, mic, camera)
↓
controllers (translate device talk to machine talk)
↓
CPU <-> memory (asks, computes)
↓
out (display framebuffer, audio buffer)
+
bulk (storage and network by commands + DMA)
+
signals (interrupts tap the CPU shoulder)Input samples the world into bits. Output renders bits into light and sound. Controllers translate at the border. Interrupts save polling. DMA saves copying. One boundary remains: the wires between machines.
Footnotes
/sponsor
Enjoyed this post? You can sponsor me and this site.