If you learned graphics after about 2000, your mental model of a display is a framebuffer: a rectangular array of pixels, each holding a colour, which you write into and the hardware shows. Everything from a canvas element to a GPU render target works that way.
The Amiga did not, and a primer on Amiga screens picked up by Adafruit is a good excuse to explain why that still matters.
Bitplanes instead of pixels
The Amiga stored images as bitplanes. Rather than one array where each entry is a colour, you have n separate 1-bit-deep images, and a pixel’s colour index is assembled by reading the corresponding bit from each plane.
Five bitplanes gives 32 colours; three gives 8. The consequences are immediate and strange to modern eyes:
- Fewer colours cost less memory and less bandwidth. Dropping from 32 to 16 colours removes an entire plane from every fetch, which frees up memory bandwidth for something else. Colour depth was a performance dial in a way it hasn’t been since.
- Some operations are almost free. Want to swap a colour range, or make a plane a mask? That’s a per-plane operation, not a per-pixel one.
- Others are painful. Reading or writing a single pixel means touching n separate locations. Anything that would be a trivial array index becomes a loop.
The Copper is the part that matters
The genuinely radical piece is the Copper — a coprocessor whose only job was to wait for a screen position and then write to hardware registers.
That means the display configuration wasn’t fixed for a frame. It could change per scanline. Consequences that look impossible if you assume a framebuffer:
- Colour gradients across the screen with no cost in memory, because the palette register is rewritten every line
- Different resolutions and colour depths in different parts of one screen
- More colours on screen than the palette holds, by changing the palette as the beam travels down
- Split screens where the top half scrolls independently of the bottom
Anyone who has wondered how Amiga demos showed a 4,096-colour gradient on hardware with a 32-colour palette: that’s the Copper, reprogramming the machine 200-odd times a frame in step with the electron beam.
Why this is useful to a creative coder now
Three reasons, and none of them are nostalgia.
It explains a visual language. Amiga aesthetics — the specific dithering, the limited palettes, the horizontal gradient skies, the copper bars — are not stylistic choices someone made freely. They are what that architecture made cheap. If you’re trying to produce that look with a shader, knowing why those images are shaped that way gets you much closer than filtering a modern render.
Constraint-driven technique transfers. The Amiga habit of asking “what does the hardware make free?” rather than “what do I want?” is exactly the discipline that makes GPU work fast. Bitplanes and the Copper are dead; the reasoning isn’t.
It’s the ancestor of things that came back. Per-scanline register changes are conceptually close to what a modern compute shader does when it varies behaviour per tile. Beam-synchronised rendering is how frame pacing works in VR. The demoscene’s obsession with doing more with the hardware than the hardware was specified for is alive in shader golfing and one-tweet renderers.
Reading a primer on a machine from 1985 is a surprisingly efficient way to understand that a display is a device you program, not a canvas you fill — and that assumption has been quietly re-emerging as GPUs get more programmable.