The custom chip architecture
Jay Miner's design philosophy for the Amiga's custom chips was that the main CPU should be freed from routine operations that dedicated hardware could perform faster and more efficiently. A general-purpose processor spending cycles moving memory blocks, updating display hardware, or playing audio samples is a processor not available for application logic. Miner designed three custom chips — Agnus, Denise, and Paula — to handle the operations that the Motorola 68000 would otherwise need to perform.
Agnus (Address Generator Unit) was the most architecturally significant of the three. It contained the DMA (Direct Memory Access) controller that managed all data transfers between system RAM and the other custom chips, operating independently of the CPU. It also contained two additional coprocessors: the Blitter and the Copper. The Agnus managed a bus arbitration system that allocated memory access between the CPU and the custom chips on a cycle-by-cycle basis, ensuring that neither the CPU nor the display hardware starved for memory bandwidth. The original Agnus chip accessed 512 kilobytes of chip RAM — memory visible to both the CPU and the custom chips. Later revisions (Fat Agnus, then Alice in the AGA chipset) expanded this to one and then two megabytes.
Denise (Denotes Encoder) handled the video output side: generating the display from data in chip RAM, managing hardware sprites, and producing the composite and RGB signals the monitor received. Paula managed audio — four independent PCM (pulse-code modulation) audio channels, each with independent frequency, volume, and sample length — and also handled the floppy disk controller, the serial port, and interrupt management. The three chips together offloaded so much from the CPU that an Amiga could multitask — running multiple applications simultaneously — while also playing audio and updating the display, all on a 7.16 MHz processor.
The Copper coprocessor
The Copper was a simple coprocessor embedded in the Agnus chip, designed for one specific purpose: executing a list of hardware register operations synchronised to the display's raster beam position. The display beam scans from left to right and top to bottom, drawing each horizontal line of the picture in sequence. The Copper's instruction list — called a copper list — could contain instructions to wait until the beam reached a specific position, then write a value to a specific hardware register.
This mechanism, simple as it sounds, enabled visual effects that no other personal computer of the era could produce. The most visible was colour cycling: by changing the hardware colour palette registers as the beam moved down the screen, a programmer could display different colours in the upper portion of the screen than in the lower portion. With a copper list long enough to change palette registers on every scan line, the Amiga could display a different set of colours on each line — effectively displaying many more colours simultaneously than the hardware's sixteen-colour limit would suggest. The classic Amiga effect of a smooth gradient sky that transitioned from deep blue at the top to pale yellow at the horizon was produced by changing one or two palette registers per scan line through the sky portion of the screen.
More sophisticated copper list techniques allowed split-screen effects — different graphics modes or different numbers of colours in different portions of the screen — and smooth horizontal scrolling of individual background layers at speeds the CPU alone couldn't have produced. Games including Shadow of the Beast (1989) used copper list techniques to create parallax scrolling across multiple independently moving background layers at a smoothness that other platforms simply couldn't match. The visual quality came not from a faster processor but from the Copper executing display hardware changes at exactly the right moment without CPU involvement.
The Blitter and the audio
The Blitter (Block Image Transfer) was dedicated hardware for moving rectangular blocks of memory from one location to another — an operation required constantly in 2D graphics programming for drawing sprites, scrolling backgrounds, and clearing or updating regions of the display. A CPU performing these operations had to execute a load-and-store loop: load a value from source address, store it to destination address, increment both addresses, repeat until the block is transferred. At 7.16 MHz with two clock cycles per memory access, a 32×32-pixel sprite required approximately 512 memory operations — roughly 72 microseconds of CPU time, during which the CPU was doing nothing but copying memory.
The Blitter performed the same operations in parallel with the CPU. While the CPU executed game logic, the Blitter moved sprite data to the display buffer, copied background tiles, or cleared screen regions. Both operations happened simultaneously on separate memory bus cycles. The practical effect was that Amiga games could display more sprites, scroll more background layers, and update more screen area per frame than a system relying solely on the CPU would allow — not because the hardware was faster in an absolute sense, but because the Blitter was busy in the same moments that the CPU was busy.
Paula's four audio channels used DMA to read sample data from chip RAM and convert it to audio output without CPU involvement. Each channel independently read from its sample buffer, advanced a pointer through the sample at a rate determined by the channel's period register, applied a volume setting, and output the result. A programmer could set up all four channels and then let Paula handle the playback while the CPU worked on other things. The four independent channels allowed a Sonic the Hedgehog-style sample for percussion, a bass-range sample for harmonic support, and two melodic voices to play simultaneously, producing audio quality that the NES's synthesis channels and the Atari ST's YM2149 could not match. Amiga tracker music — composed in sequencer programs that programmed Paula's DMA playback directly — became an art form in its own right, producing the MOD file format that influenced electronic music production through the following decade.
AmigaOS and why it mattered
The Amiga's operating system was as unusual as its hardware. AmigaOS provided preemptive multitasking — the ability to run multiple programs simultaneously with the operating system switching between them on a time-slice basis — in 1985, years before Microsoft Windows achieved comparable capability. The kernel, called Exec, managed task scheduling, memory allocation, and inter-process communication. Intuition handled the graphical user interface: windows, menus, gadgets, and the Workbench environment that managed files and launched applications.
Preemptive multitasking meant that an Amiga could be rendering a Deluxe Paint animation in the background while a tracker played music while a spreadsheet calculated in the foreground — all on the same machine, simultaneously. This was not a theoretical capability; it was a daily working mode for Amiga users who used the system for creative production. The demo scene's practice of playing music while displaying graphics while executing demo effects was possible because the OS supported simultaneous operation of multiple subsystems through its task scheduler and priority system.
The hardware was eventually overtaken by the PC market's commodity economics. A PC in 1993 with a VGA card, Sound Blaster, and DOS could approximate most of what the Amiga did, and by 1995 a PC with a Pentium processor, Windows 95, and a dedicated sound card exceeded it. The Amiga had been designed to do with custom silicon what the PC eventually did with commodity components — a hardware architecture that was correct about the destination but couldn't survive the journey. What Jay Miner built in 1983–84 reached the commercial market in 1985 and was genuinely remarkable for a decade. The companies that made it couldn't sustain it. The hardware outlived them.