A different mental model of what an OS can be. POSIX has been the water we swim in for so long that its choices feel like natural laws. The Amiga makes different ones. It has shared libraries loaded on demand into a single address space; message-passing IPC that predates Erlang by a decade and is functionally similar; a graphical shell (Workbench) and a command shell that are peer siblings, not parent-and-child; a filesystem with named volumes and no root directory; preemptive multitasking implemented on hardware without a memory management unit; a display coprocessor that reprograms video registers in step with the scan-line beam; a system-wide scripting language (ARexx) that any application registers a message port with by default.

Some of those choices are outright dangerous by modern standards. A wild pointer takes down the whole system rather than one process; the security model has one user and trusts every running program with complete access to every other program’s data; a networked service crashes and the machine reboots. Others quietly beat their Unix counterparts: message-passing IPC with kernel-mediated wake-up is cheaper than a POSIX pipe; the assign system (chapter 6) gives you per-user, first-class-in-the-filesystem symbolic paths that appear in every filesystem tool without special support; the boot process takes seven seconds. Both categories are educational.

The single biggest thing you learn is what an OS looks like when it is designed as a tightly-coordinated whole rather than an accretion of decades of layers. Every part of the Amiga knows about the other parts — the message-port abstraction Exec provides is what Intuition uses for window events, what dos.library uses for its packet-based file operations, and what ARexx uses to deliver scripting commands to applications. That single primitive composes cleanly across half a dozen layers.

A machine you can hold in your head. A stock Amiga 500 shipped with 512 KB of chip RAM, a 7 MHz 68000, and a ROM containing an operating system that fit in 256 KB. The AmigaOS 3.2 ROM is 512 KB. You can, if you want, read most of the Amiga ROM Kernel Reference Manuals in a long weekend and come out understanding the whole stack, from Exec/AllocMem through Intuition/OpenWindow. Very few modern systems offer that. The Linux kernel alone is now roughly 40 million lines of C. macOS is not much smaller. Both are opaque to almost every engineer that uses them.

The Amiga is readable. Every OS structure has a documented layout. Every library function has a one-page reference in the RKM autodocs. The whole boot process is transparent from the moment the CPU comes out of reset to the moment LoadWB finishes starting Workbench. You can trace exactly how a keystroke moves through the OS, from the keyboard IRQ, into input.device, through Intuition’s event router, onto a window’s UserPort, into your program’s Wait(). On Linux this path exists but is spread across hundreds of files and thousands of engineer-years of accreted history. On the Amiga you can print it on a single sheet of A4.

A working retrocomputing target. If you write demos, games or tracker music, the Amiga is one of the most vibrant retro platforms alive. There are annual competitions (Revision, Assembly, Datastorm) with active Amiga categories; new commercial games ship on floppy and cartridge every year; the tooling (vasm, vbcc, hollywood, Amiga Bloodwych) is being actively maintained. The scene has never really gone away.

Because you missed it the first time. This is a perfectly good reason. The Amiga’s peak commercial period was 1985 to 1994; many readers of this book were nine years old at the end of that. There is no age at which it stops being interesting to learn what your predecessors were doing. If you learned about protected memory, shared address spaces, message-passing kernels, or coroutine schedulers in an undergraduate OS course — the Amiga is a working existence proof of most of those ideas, ten years before Linux 0.01.

Set aside nostalgia. Ask instead: what is architecturally interesting about this system that is worth studying?

Preemptive multitasking without an MMU. How do you build a multitasking OS on hardware that gives you no memory protection? Exec’s answer is: you don’t try. You provide fast context switching, a strict priority scheduler, and enough primitives (semaphores, message ports, signal bits) that well-behaved programs can share correctly. Every program is trusted. This is a design point most modern OSes did not seriously explore and one that mobile-microkernel research groups occasionally re-invent.

The library dispatch model. Every OS service is a struct Library whose entry points live at fixed negative offsets from a base pointer you obtain by name. OpenLibrary("dos.library", 39) returns a base pointer; -30(a6) is Read, -36(a6) is Write. This is dead simple, extends to new libraries without any kernel changes, and gives you per-caller refcounting for free. It also enables patching: SetFunction() swaps out an entry point at runtime, and every subsequent call goes through your replacement. This is how utilities like SnoopDos work — patch the library, log every call, forward to the original.

Cheap message-passing IPC. An Exec message is a struct Message embedded in whatever caller-owned structure you want; sending is PutMsg(port, msg) and takes on the order of fifty cycles; receiving is a Wait() on a signal bit followed by GetMsg(). There is no kernel copy — the receiver reads the sender’s memory directly. Compare to a POSIX pipe, which requires a system call, a data copy, and typically a buffered kernel object. The Amiga’s cheapness of IPC is what makes it viable to structure almost every subsystem around messages. Filesystem operations are packets sent to a handler’s port. Keyboard events are messages. Timer expirations are messages. All of it composes cleanly, on 1985 hardware, at speed.

Datatypes as pluggable format handlers. The system-wide datatypes.library (chapter 8) is a registry: applications register "I can handle image/gif" or "I can handle text/plain" and any consumer says "please display file X" without knowing what X is. This is a decade before macOS’s UTI system and two decades before Linux’s mimetype handling caught up in polish. When you install a new datatype, every application that opens files gets the new format for free.

ARexx as system-wide automation. Every well-written Amiga application opens a named message port and accepts commands as strings. Any ARexx script can ADDRESS "PPAINT" "LoadBrush foo" and Personal Paint receives the message, executes the command, and replies with a status. This is DBus service dispatch in 1987. Cross-application scripts — save a picture from a paint program, insert it into a word processor, email the result — are dozens of lines and rely on no glue code beyond what the OS provides.

The custom chipset as a coprocessor family. Rather than making the CPU do everything, the Amiga hardware team split the work between three custom chips (Agnus, Denise, Paula) that share the chip-memory bus with the CPU via time-slicing. The Copper (inside Agnus) is effectively a small display-list processor that runs a program of its own, synchronised with the beam. This lets a 7 MHz 68000 do things that a 25 MHz 386 could not do at all, because most of the work is offloaded to hardware. The lesson generalises: partition the work between fast-and-general (CPU) and slow-but- plentiful (fixed-function coprocessors) at the design level, not after the fact.

None of the ideas above are unique to the Amiga; some appear in QNX, in classic Mac OS, in the Atari ST, in a couple of academic kernels. But the Amiga is where they compose into a system that a user actually turned on every day for a decade.

It is not a nostalgia trip. There will be no exhaustive lists of demoscene groups, no reverence for the Video Toaster, no pages of Guru Meditation codes decoded from memory. Those are excellent subjects for other books.

It is not a hardware reference. The Amiga’s custom-chip architecture is one of the most beautifully documented systems of its era, and the Amiga Hardware Reference Manual is a couple of clicks away on archive.org (see the bibliography). We touch on Agnus, Denise and Paula only where they matter to understanding the OS, and we spend one section in chapter 10 on the Copper because it is a fascinating primitive that changed my thinking about what a display subsystem can be.

It is not a beginner’s programming book. You already know how to program. We will spend our budget on the parts of Amiga programming that are different — the library model, the memory model, the message-passing IPC, the tag-list convention, the paranoid-cleanup pattern — and skip past the parts that are the same as everywhere else.

It is not an assembly-language tutorial. 68k assembly is a beautiful CPU to write in and there are excellent books on it (see the bibliography), but this book stays in C, ARexx, and the Shell.

It is not a complete Aminet catalogue. We name the applications you would actually install in 2026 (chapter 8), but the archive has 90,000+ files and any attempt to be exhaustive would be out of date before the ink dried. Aminet’s own category tree (https://aminet.net/) is the right index.

You already know how to program. Concretely, this book expects:

You do not need to know 68000 assembly, and this book does not teach it. If you want to go there afterwards, Motorola’s original M68000 8-/16-/32-Bit Microprocessor User’s Manual is the primary source, and Ranck & Wilkinson’s Programming the 68000 (Sybex, 1983) is the readable secondary source. Both are cited in the bibliography.

You do not need any prior Amiga experience. If you had an A500 in the loft, you will find chapter 3 fast to read; if you never did, you will find it slower, and everything after that is the same. The book is calibrated for either starting point.

The word "Amiga" covers thirty years of hardware and at least four mutually incompatible operating-system lineages:

When a chapter says "the OS" without qualification, it means classic 68k AmigaOS 3.1 or newer, running on either real hardware or emulation. Where a topic differs between OS 3.x and OS 4.x, or where AROS and MorphOS diverge in an interesting way, the text calls it out.

The C examples in this book are tested against three toolchains where practical:

Where an example is toolchain-specific it says so. The default assumption throughout is "modern build, either native SAS/C on the Amiga or cross-compiled GCC on your Mac or Linux host." Runnable sources are in the book’s code/ directory.

Chapters 1 through 4 give you enough historical and mental-model context to sit down at the machine without wincing. Chapters 5 through 8 cover day-to-day OS use: Workbench, filesystem, Shell, and the applications you would install for common tasks. Chapters 9 through 12 are the programmer’s core: C, Intuition and the graphics chips, ARexx, and networking. Chapter 13 brings the story up to the present with AmigaOS 3.2, 4.1, MorphOS and AROS.

The appendices are for the desk: a Linux-to-Amiga command cheatsheet, and a bibliography with the primary and secondary sources cited in each chapter, plus community resources for further reading.

If you only have an afternoon, read chapters 4, 6 and 7 — terminology, filesystem, Shell. Those three unlock almost everything else. If you have a weekend, add chapter 9 for the programming model.

Amiga command names, device names and filesystem paths are set in monospace. Because the Amiga is case-insensitive we render commands the way Commodore’s documentation did: initial caps for command names (Dir, List), all caps for device and assign names (DF0:, SYS:, RAM:). You may type them however you like.

Side-by-side comparisons use two-column tables with the reader’s current platform on the left and the Amiga equivalent on the right:

Where a screenshot or diagram is referenced, the caption cites the source. Images from Wikimedia Commons are used under their Creative Commons or public-domain licences; fair-use screenshots of copyrighted OS UIs (Commodore, Hyperion) are used for identification and educational commentary. Full source and licence per file are in images/README.md.

[graphviz] and [ditaa] blocks in the source render to SVG at build time via the asciidoctor-diagram extension; you can edit the diagram source in place and rebuild. Rendered SVGs are not tracked in git; run asciidoctor -r asciidoctor-diagram book.adoc to regenerate.

See Chapter 6 for how to pick a version and start it up.

Hi-Toro was founded in 1982 by Jay Miner, Larry Kaplan, Dave Morse and several others. Miner had designed the Atari 2600 and 800 custom-chip sets and knew exactly what he wanted next: a next-generation home-computer chipset that would leave the current crop of Apple II clones and IBM PCjrs in the dust. The plan was a games console codenamed Lorraine (after the wife of one of the founders), built around a custom chipset paired with the then-new Motorola 68000 CPU.^[3]

The choice of 68000 mattered. In 1982 the alternative was Intel’s 8088 (which powered the IBM PC and its clones) — a 16-bit CPU with a 20-bit segmented address space and a slow memory bus. The 68000 was a 16/32-bit CPU with a flat 24-bit address space, more registers, faster clocks, and a cleaner instruction set. Motorola sold it for less. Apple picked the 68000 for the Macintosh in 1984; Atari picked it for the ST; Amiga picked it for Lorraine. For half a decade the Motorola-camp home computers all had architectural advantages over the Intel-camp ones and lost on market share anyway. But that is a different book.

Hi-Toro renamed itself Amiga Corporation early on for legal reasons (the name "Hi-Toro" collided with a Japanese lawn-mower manufacturer, which was not the association the founders wanted). The company ran short of money as the 1983 videogame crash hit — Atari’s implosion sucked the oxygen out of the whole console market. Amiga survived by taking bridging loans from Atari itself, which came with strings attached: Atari acquired the rights to the Lorraine chipset for use in an Atari-badged product, and Amiga would be paid a licence fee. If Amiga couldn’t pay back the loan by June 1984, Atari would own the chipset outright.

The loan came due. Commodore paid Amiga’s debt to Atari on the day, bought Amiga Corporation the following week, and kept the chipset. The Atari-owned "Amiga" console never shipped. What did ship, seven months later, was the Amiga 1000 from Commodore.

The operating system was written under contract by a small team at MetaComCo in Bristol, England, led by Dr Tim King. King’s team were BCPL people from way back — BCPL is a pre-C systems language Martin Richards designed at Cambridge in the late 1960s — and they wrote AmigaDOS (the filesystem and command layer) in BCPL. This was a pragmatic choice: MetaComCo had a mature BCPL compiler, the language produced compact code that fit in the Amiga’s tight ROM budget, and the team could ship on schedule. It was also a long-lived source of Amiga-user bewilderment. BCPL’s heritage leaked into user-visible details for a decade: filename length limits, the shape of return codes, the persistence of "BPTR" (BCPL pointer) types in the DOS library API well past the point where the underlying implementation had been rewritten in C. If you have ever wondered why the Amiga has separate dos.library and exec.library sitting on top of each other, that seam is where the two teams' code met.

Meanwhile, in Los Gatos, RJ Mical was building Intuition — the windowing system — in 68000 assembly, and Dale Luck was building the Boing Ball demo that would be the launch showcase. The demo was written overnight for the Consumer Electronics Show in January 1984, running on prototype hardware still soldered to breadboards. It became one of the most famous marketing pieces of the decade — a 3-D bouncing beach ball with realistic shading, at a time when the state of the art on IBM PCs was Lotus 1-2-3 in monochrome text mode.^[4]

Commodore launched the Amiga 1000 in July 1985 at the Lincoln Center in New York, priced at US$1,295 for the computer alone (monitor extra). The machine had:

The 1000 shipped without an OS in ROM. It had a small "Kickstart" bootstrap that loaded the OS from a Kickstart 1.0 floppy into 256 KB of "writable-then-locked" RAM. You inserted the Kickstart disk, watched it load, ejected it, inserted the Workbench disk, and were on your way. This "soft-Kickstart" scheme made early OS updates trivial — just ship a new floppy — but it wasted 256 KB of the machine’s total 512 KB on the OS. Later Amigas moved Kickstart into ROM and reclaimed that RAM.

The 1000 was expensive and did not sell in large numbers — a few hundred thousand units over its lifetime. But it established everything the later Amigas would build on: the chipset, the OS, the developer story, and the reputation for graphics and sound that would carry the platform for a decade.

The A500 is the machine most Europeans think of when they hear the word "Amiga." Commodore launched it in 1987 at approximately US$700 with the goal of putting Amiga hardware in the price range of the Commodore 64 crowd — mass-market home computers, not workstations.

The 500 traded the 1000’s rack-mount styling for a wedge-shaped "all-in-one" case with the keyboard built in and everything on a single motherboard:

The 500 sold in the vicinity of six million units over its lifetime, and it did most of them in Europe. In the UK, Germany, France, the Netherlands and Scandinavia it was for several years the single best-selling home computer, particularly for games — Speedball 2, Lemmings, Kick Off 2, Shadow of the Beast, Sensible Soccer, thousands of others.

The Amiga 500 was so successful commercially that Commodore’s American management repeatedly assumed the platform was purely a games machine, which shaped the marketing (targeted at kids) and which cost the platform a whole class of business software that went to Macs and PCs instead. This is a recurring theme in Amiga history.

The A500+ followed in 1991: internally an A500 with the newer ECS (Enhanced Chip Set), 1 MB of chip RAM standard, and Kickstart 2.04 in ROM. Otherwise identical.

The A2000 was Commodore’s answer to the "what do we sell for business use" question, and it was built by a different team in Braunschweig, Germany — the ex-employees of the German Amiga subsidiary bit-cross Systeme. The 2000 was a proper professional tower:

The Video Toaster is worth a paragraph. NewTek’s product was a Zorro card that turned an A2000 into a broadcast-quality video mixer with hardware chroma keying, effects, and character generation. It was used on national television — Babylon 5, seaQuest DSV, Home Improvement, Late Night with Conan O’Brien — and for a while the Amiga owned a real slice of the video production industry. Commodore never quite grasped what this meant for their marketing strategy.^[5]

The A3000 was Commodore’s late attempt to build a proper workstation. It shipped with:

The 3000 was a genuinely good workstation and had a fair run in video production and in graphics-arts circles. There was even an official Unix port — Amiga Unix (AMIX), based on System V Release 4 — that made it a legitimate small-office Unix server for anyone who wanted one. AMIX did not sell in significant numbers; the market for a $5,000 68030 Unix machine was small against Sun workstations at that price. But it existed, and it runs today on 3000 hardware under an emulator, and it is a fascinating artefact of what Commodore could have done if they had had a coherent strategy.

By 1991–1992 the original A500 was showing its age. Commodore’s response was a family of replacements:

The AGA ("Advanced Graphics Architecture") chipset was Commodore’s attempt to catch up with the SVGA cards that were becoming standard on PCs by 1992. AGA gave 256 colours from a palette of 16 million (up from ECS’s 64 from 4096), sped up the Blitter, added higher-resolution modes, and made HAM8 possible — a hold-and-modify display mode that could show all 262 144 colours simultaneously.

AGA was not enough to compete with contemporary SVGA cards, which were pushing 1024×768 in 24-bit colour by 1993. Commodore had a successor chipset in development — the AAA ("Advanced Amiga Architecture") — that would have added true 24-bit graphics and multiple simultaneous displays, but AAA was still in development when Commodore ran out of money.

The CD32 launched in 1993 as Commodore’s answer to the Sega Mega-CD and the still-rumoured PlayStation. It was an A1200 with a CD-ROM drive in place of the floppy, in a low-slung games- console case, with a gamepad instead of a keyboard. It sold well in the six months of its life (roughly 100,000 units in the UK alone), demonstrating that Commodore could still produce hardware that people wanted to buy.

The problem was the balance sheet. Commodore had over-invested in factories, under-invested in R&D, over-committed to the failing Commodore 64 line for far too long, misfired badly on the US market, and burned cash trying to develop AAA. In April 1994 Commodore International filed for bankruptcy. All development stopped. The Braunschweig German engineering team was let go. The AAA silicon was never manufactured. The Amiga trademark and intellectual property went to the highest bidder in the liquidation.^[6]

The Amiga’s intellectual property passed through a sequence of owners — Escom (1995), Gateway 2000 (1997), Amino/Amiga Inc. (2000) — none of whom shipped substantial new products. Escom briefly re-manufactured the A1200 and A4000 in 1995 before its own bankruptcy in 1996; Gateway held the rights for two years without doing anything meaningful with them; Amiga Inc. was a succession of small shells that promised much and delivered little through the late 1990s and early 2000s.

In this period the software community kept the platform alive on its own. Aminet, founded 1992 by Urban Müller in Switzerland, had by 1998 grown to the largest single archive of software for any platform in the world at the time (measured by file count). Third-party companies — Village Tronic, phase 5, ELBOX, DCE — built RTG graphics cards, accelerator boards, SCSI controllers, network cards, and CPU expansions that kept the hardware running. Haage & Partner released AmigaOS 3.5 in 1999 and 3.9 in 2000 with a Commodore licence, adding modern icons, docked launch bars, RGB icon support, and updated commands. Software companies continued to ship: Personal Paint, PageStream, Lightwave, ImageFX, Directory Opus, Wordworth all had major releases in the late 1990s.

Two developments in this decade shape everything after:

Both projects were driven by community volunteers with no commercial support; both are alive and healthy thirty years later.

In 2001 a small Belgian company, Hyperion Entertainment, was contracted by Amiga Inc. to port AmigaOS to PowerPC. Hyperion had done a series of well-regarded game ports to AmigaOS (Shogo, Descent Freespace) and had the systems-programming credibility. The result — AmigaOS 4 — shipped in 2006 after a long and troubled development, targeting the AmigaOne series of PowerPC boards (Eyetech, later A-Eon Technology). AmigaOS 4.1 arrived in 2008 and 4.1 Final Edition in 2014, with continuous update packs since. Hyperion is still, in 2026, the active developer of AmigaOS 4.x.

In parallel, a separate PowerPC OS with different lineage — MorphOS — reached its first stable release in 2002. MorphOS runs Amiga applications through an emulation layer (a JIT compiler called Trance) and native PowerPC applications directly. It is source-code independent of AmigaOS but broadly source- compatible with the API. It runs on several Apple PowerPC machines — notably PowerBook G4 and Power Mac G5 — and on the Pegasos motherboards from Genesi.

Meanwhile, Hyperion also acquired the rights to the classic 68k OS and shipped AmigaOS 3.1.4 in 2018, 3.2 in 2021, and point releases since. These target the original 68k hardware (and its FPGA recreations — Vampire, MiSTer, Minimig).

The upshot for a returning engineer is: there are four living Amiga platforms today.

Two design decisions from the mid-1980s explain most of what feels alien to a modern eye.

The next chapter puts you in front of a running Amiga so you can follow along, either on a modern host under emulation or on real hardware you have restored.

Emulation is not a compromise. UAE and its descendants have been developed continuously since 1995; on any modern CPU they emulate a 68060 A4000 faster than the hardware itself ran, with cycle-exact timing that is accurate enough for demos and games that depend on Copper trickery. It is also the only way to get instant snapshots, directory-based virtual disks, and painless file sharing with the host.

Three UAE forks matter today:

WinUAE is the reference implementation. Windows-native, updated constantly (monthly betas, quarterly stable releases), and used by every serious Amiga developer for testing. Runs perfectly under Wine on macOS and Linux, but the launcher UI is Win32 through-and-through.^[7]

FS-UAE is a cross-platform wrapper (macOS, Linux, Windows) around the WinUAE core, with a friendlier configuration UI and a companion program called FS-UAE Launcher that manages a local library of disks, hard-drive images and configurations.^[8] This is what the book assumes unless it says otherwise.

Amiga Forever, from Cloanto, bundles WinUAE with a legally licensed Kickstart ROM set and a curated selection of Workbench disks. It is the easiest legal on-ramp because the Kickstart ROMs are otherwise a legal problem: they are copyrighted, and you are only entitled to a copy if you own the corresponding hardware. Amiga Forever costs money (roughly €30 as of writing) but it is the smoothest path.^[9]

An FPGA implements the custom chipset and CPU in reconfigurable silicon and pairs it with modern I/O (HDMI, USB, SD card). The result is not emulation; it is a hardware clone. As of 2026 the practical options are:

If you have an A500 or A1200 in the loft, or you buy one on eBay, budget a weekend for restoration.

You will hear people evangelise Kickstart 1.3 for the retro authenticity, and Workbench 3.1.4 or 3.2 for actually getting work done. The trade-offs:

This book targets Workbench 3.1 or 3.2 — old enough to be faithful to the classic API, new enough to include modern conveniences (better Shell, TCP/IP support out of the box, hard- disk-first workflow).

If you have neither and want to try, install AROS m68k on your emulator — it is free and boots most 3.1-era software.

If you can boot to Workbench and open a Shell — the icon lives in SYS:System/Shell — you are ready. As a smoke test, open a Shell window and type:

That is Workbench 3.2.2. Any 47.x or 45.x tells you you are on OS 3.1.4 or later. Version on OS 3.1 reports 40.68 or 40.63. Version on OS 1.3 reports 34.5. Keep this number handy — later chapters occasionally note version-specific behaviour.

Two more smoke tests worth running:

If both of those look sane, you have a working setup. If Info reports Read/Write on your Workbench volume you should also verify write access:

T: is the temporary-file assign; if writing to it works you are in business. T: is normally assigned to RAM:T so this exercises RAM-disk creation as well.

Now the terminology chapter.

The rest of this chapter unpacks the terms that are load-bearing for everything that follows.

The whole OS stack, one picture, Linux on the left:

The single most common Amiga terminology confusion:

Kickstart 3.2 + Workbench 3.2 = "AmigaOS 3.2". You need both, and they are versioned together. When someone says "I’m on Kickstart 3.1 and Workbench 3.1.4" they are running a mix, which is legal but occasionally weird.

Analogy: Kickstart is your kernel, Workbench is your userland
/etc. The line between them is where "OS in ROM" ends and "OS on disk" begins, and that line is drawn at a lower level than macOS’s or Linux’s — a stock Amiga can boot Kickstart, get to the "insert Workbench disk" hand-holding-a-disk animation, and not boot any userland at all until you give it one.

These three terms name three different things and are the most common source of bewilderment. Chapter 6 covers them in depth; the summary is:

You will use assigns constantly. Every third-party package sets one up (INSTALL:, NETWORK:, SDK:) so that its files can live anywhere on any volume while its scripts refer to them by a stable name.

That last one is a tripwire. On Unix / means root. On the Amiga there is no root; each colon-terminated device or assign is its own root, and / in a relative path means "go up." /../foo is "grandparent’s foo."

Exec provides tasks. A task has a stack, a priority (-128 to +127), a signal-bit mask, and a list of allocated resources. Tasks are what the scheduler schedules.

dos.library builds a process on top of a task by attaching a DOS environment: current directory, command search path, standard input/output/error, arguments, environment variables. Every Shell window is one process; every program you run from Workbench is one process; the Workbench desktop itself is one process.

You almost always want to write your programs as processes rather than raw tasks: processes give you printf-style output, file I/O, and the ability to open the OS by name. Raw tasks are for Exec-internal work — device handlers, interrupt servers, the scheduler-adjacent code.

Everything the ROM exports is packaged as one of three shapes:

A device driver is usually a device with a handler as its front end. Example: the console handler CON: puts a user-facing filesystem face on top of console.device, which puts a queued-I/O face on top of the raw keyboard input.

You will meet at least three, so:

If you are writing a new application, MUI is the safest bet for compatibility across 68k Amiga installations from 1996 onwards; if you are on OS 4 or targeting only OS 3.2+, ReAction is the first-party option.

Late-Commodore AmigaOS (from 2.0 onwards) added an object-oriented class system called BOOPSI — "Basic Object-Oriented Programming System for Intuition". This is not a full Smalltalk; it is a minimal class/instance/method system that runs in C, using tag lists for message dispatch and a simple root class from which everything inherits.

The primitives:

You create an object by asking a class for one, passing tags:

You send arbitrary methods through DoMethod:

Toolkits (MUI, ReAction, ClassAct) all build on BOOPSI. Each adds its own class hierarchy but they use the same primitives. The API’s shape lets you subclass system classes to add behaviour: implement a new class that extends gadgetclass, override GM_RENDER and GM_HITTEST, and every Intuition gadget-consumer accepts your class as a normal gadget. This is how the Aminet class/ directory grew to hundreds of third-party BOOPSI classes.

If you write GUI code, you will meet BOOPSI. Chapter 10 has examples.

datatypes.library is another late-Commodore idea. Applications register themselves as handlers for specific data classes ("image", "picture", "sound", "text", "animation"), each supporting one or more MIME-like types. Any consumer that wants to display or play arbitrary data asks the datatypes library:

Behind the scenes, datatypes.library scans SYS:Classes/DataTypes/ for a class that claims to handle PNG files, loads it, and passes the file to it. Your program does not need to know PNG exists.

Install a new datatype (gfx/dtc/PNG.datatype from Aminet is the canonical one) and every DT-aware application on the machine suddenly gains PNG support. This is a decade before macOS’s Uniform Type Identifiers reached the same level of plug-and-play.

The pre-installed datatypes on OS 3.2 handle: IFF-ILBM (native picture), PNG, JPEG, GIF, WebP, IFF-8SVX (native sound), MP3, Ogg Vorbis, plain text, RTF, plus IFF-ANIM animation and MPEG video.

These are the three main software archives:

The default archive format on the Amiga is LhA (.lha), not zip or tar. The LhA command is on every Workbench install (or one Aminet download away).

Three filename extensions you will see constantly:

Now that you can pronounce everything, we can look at the desktop.

A "screen stack" is real — public and custom screens layered on top of each other, each dragged down by its title bar to reveal the one behind:

On macOS the "screen" is your monitor. On the Amiga, a screen is a display mode plus a colour palette plus a stack of windows. You can have many screens open at once, each in a different resolution, each with its own palette, and you switch between them by pressing Left Amiga+M (or by dragging the screen’s top bar down like a window shade to reveal the screen behind it).

This exists because the custom chipset natively supports multiple display modes and per-line palette reprogramming via the Copper. Applications can, and often do, open their own screens: a paint program in HAM-8 (24-bit rendered on-the-fly), a modeler in high-resolution interlaced, a game in 320×200 lowres — all simultaneously, all live, none of them dropped to bitmaps.

Most applications are polite and open on the Workbench screen, which is the default public screen. A public screen is one that other applications can open windows on; if you write your own screen you can declare it public with OpenScreenTags(…​, SA_PubName, "MyScreen", TAG_END) and other well-behaved apps will be able to target it.

Practical consequences:

The gadgets on a standard window, moving clockwise from the top left:

Every gadget the OS provides is a struct Gadget on Intuition’s gadget list; you can enumerate them from your own program with FindGadget() on a window. Third-party toolkits (MUI, ReAction, gadtools) build their own richer widgets by extending the same struct with BOOPSI classes.

Every visible object on the desktop has an icon file — a .info file that lives next to the object it describes. Workbench.info is the icon for the Workbench volume; Prefs.info is the icon for the Prefs drawer; Notepad.info is the icon for the Notepad executable. The .info file contains:

Tooltypes are the Amiga’s answer to command-line arguments for programs launched from the desktop. Click an icon once to select it, then choose Icons  Information (or Right Amiga+I) and you get a requester where you can edit them. Example — the tooltypes on SYS:Tools/Calculator:

The launching program parses them with ArgArrayInit() / ArgArrayDone() from icon.library. Chapter 9 has an example.

Icons come in three flavours by tradition:

There is also a trashcan drawer per volume — really just a convention (a normal drawer with a special icon) that Workbench knows to route deletions through.

Commodities Exchange (added in OS 2.0) is the Amiga’s answer to system-tray applets and input-method daemons. A commodity is a program that:

Standard commodities that ship with Workbench:

You can write your own. The commodities.library API is small — CxObject *broker = CxBroker(&nb, NULL) creates a service, then AttachCxObj() adds hot-key filters, CxSender objects, translators. Under a hundred lines gives you a hot-key that runs a Shell command.

The "commodities" name comes from Amiga’s marketing of the concept as "small useful things you drop into your desktop." Think of them as the Amiga’s equivalent of macOS launch daemons or of Windows tray-icon utilities.

The preferences editors live in SYS:Prefs. On OS 3.2 you get roughly this set:

Each editor saves two files: an active copy in ENV:Sys/ for the current session, and a persistent copy in ENVARC:Sys/ that survives reboot. Choosing Prefs  Save writes both; Prefs  Use writes only the session copy. Chapter 6 explains ENV: and ENVARC: in detail.

Workbench is genuinely preemptive. If you launch a slow rendering task, you can drag its window aside and start a Shell without waiting. The way you monitor the multitasking depends on how much you paid for your setup:

Because there is no memory protection, one buggy task can and will take down another. When it takes down the whole system you get a red Guru Meditation alert (rebranded to "Software Failure" in OS 2.0+ but still popularly called a Guru). The hex numbers on the alert are decoded in the ROM Kernel Reference Manual: Libraries appendix on alert codes; the first byte tells you which subsystem crashed and the second gives detail.^[13]

The boot process, from power-on:

You can hold both mouse buttons during boot to get an early boot menu (Kickstart 2.0 and later) where you can pick a different boot volume, disable startup-sequence, or run a Shell without Workbench. This is the closest thing the Amiga has to a "safe mode."

The boot sequence in full:

If your boot hangs, the failure point is almost always inside S:Startup-Sequence — a Mount for a missing device, an Assign to a non-existent path, or a startup program with a wild pointer. Hold both mouse buttons at boot, pick Boot With No Startup-Sequence from the early menu, and you drop into a bare Shell where you can Type S:Startup-Sequence and fix it.

There is no root directory.

Repeat that until it stops feeling wrong. In Unix, every path traces back to /. On the Amiga, the top of the tree has many entries — one per device, one per volume, one per assign — and none of them are above any others. When you write a full path you always name which top-level entry you are starting from, and you separate it from the rest of the path with a colon.

Workbench:Utilities/Clock means: on the volume named Workbench, in the drawer Utilities, the file Clock.

DH0:Utilities/Clock might mean the same file, if the volume Workbench is currently on device DH0.

SYS:Utilities/Clock also might mean the same file, because SYS: is an assign to the current boot volume.

All three paths are equally valid ways to name the file. Which you use depends on what you are trying to convey — "on this specific hardware," "on this specific disk," or "in the OS’s canonical place."

An absolute path names its device, volume or assign explicitly and ends the name with a colon:

A relative path has no leading colon-terminated name:

A path element of / at the start of a relative path (or in the middle of any path) means parent directory. This is the tripwire:

There is no ... Where Unix uses .. to go up, the Amiga uses a leading or extra /.

Foo: on its own means "the root of the volume Foo". Foo:/bar is illegal — you cannot go up from a volume root.

Paths on the Amiga are case-insensitive but case-preserving, like HFS+ on macOS. Filenames are limited to 30 characters on the original Old File System (OFS) and to 107 characters on Fast File System (FFS) revisions from Kickstart 2.0 onwards. Modern PFS3 and SFS allow filenames up to 255 characters.

Every device on the system is mounted by giving the OS a description of it. On classic AmigaOS the descriptions live in two places:

A typical DOSDriver — this is what a DEVS:DOSDrivers/PIPE config file looks like:

And a full mountlist entry for a hypothetical EXTRA: hard-drive partition on the second SCSI unit:

The # on its own line ends the entry. This is the same syntax HDToolBox writes when you partition a drive with it. Once mounted, EXTRA: behaves like any other volume — you can Format it, Info it, and use it in paths.

Most users never edit a mountlist by hand; HDToolBox, MediaToolBox and the modern OS 3.2 DevInfo preferences editor handle it graphically. But knowing where the config lives helps enormously when things go wrong — a stubbornly unmountable partition often boils down to a wrong DosType (0x444f5301 for FFS, 0x444f5303 for FFS-DirCache, 0x50465303 for PFS3, 0x53465303 for SFS, and so on).

The Amiga has more filesystems than you would expect. The important ones:

You choose the filesystem when you format a partition; you can mix freely across your drives. There is no "must reformat root" story.

RAM: is not a file cache. It is a filesystem in main memory. It grows and shrinks as files are written to and deleted from it, without any per-user configuration.

T: (temporary files) is an assign to RAM:T. If you install a package that writes temp files, they land in T:, which is RAM:T, which is memory. This is fast. It is also volatile — a crash loses RAM:, so do not put your only copy of your source code there.

The "Recoverable RAM Disk" (RAD:) is a related concept: a separate handler that survives a warm reboot by preserving the memory region. Used historically to keep a bootable copy of Workbench on machines with slow floppy drives.

Under the boot volume, an OS 3.2 install lays out roughly:

This is stable enough that a script can rely on it. It also gives you the mental map of where things live: commands go in C:, libraries in LIBS:, drivers in DEVS:, scripts in S:.

Two flavours, both file-backed:

Global environment variables are files in ENV: (which is RAM:ENV after boot, populated at boot from ENVARC:, which is SYS:Prefs/Env-Archive). Every process sees them. The Shell commands SetEnv and GetEnv read and write them, and GetVar/SetVar do the same from within scripts and programs. Prefs editors use them: ENV:Sys/pointer.prefs is your current pointer preferences.

Local variables are per-Shell. Set FOO=bar in one Shell does not affect another. Local variables shadow global ones.

To make a global env var survive reboot, save it to both ENV: and ENVARC::

or in one step:

The SAVE flag was added in OS 2.0.

Command resolution, top to bottom, first match wins:

Compact reference. Every command has a ? help mode (List ? prints its template).

Boot-time shells run S:Shell-Startup before their first prompt. This is where you set aliases, add to your path, and configure your environment for interactive use. It is the equivalent of .bashrc.

S:User-Startup is sourced by S:Startup-Sequence at boot time, and is the equivalent of Linux /etc/rc.local. Every package installer that needs to add an assign or mount a device appends to User-Startup. Do not edit Startup-Sequence itself unless you know what you are doing; put your changes in User-Startup.

A reasonable S:Shell-Startup:

%N is the shell number, %S is the CWD, %R is the previous command’s return code. See Prompt ? for the full list.

Run a program in the background by prefixing with Run:

Run starts the program as a new detached process and returns immediately. The [CLI 2] line tells you it got shell number 2.

To close a background CLI when its program is finished, add >NIL: <NIL: to detach its I/O too:

The EndCLI command terminates the current Shell. Break n sends signal n to Shell number n (like kill, with Break n C for Ctrl-C). List running shells with Status.

Modern OS 3.2 adds TaskPri and Break improvements; check the manual page.

Because CON: is a handler, you can open a fresh window from a script by writing to a CON: "file" whose name encodes the window’s shape:

The path components are left/top/width/height/title/flags. The flags are:

This is how programs launched from Workbench get a shell window when they need one — they open CON:0/0/640/200/Title/AUTO/WAIT as their stdout.

A Shell script is text; a Workbench user wants a double-clickable icon. The bridge is a small utility called IconX, which lives in C:.

Give your script a .info icon with these tooltypes:

And set the icon’s Default Tool to C:IconX. Now double- clicking the icon runs your script inside a Shell, complete with a temporary console window. The script sees its Workbench arguments in the standard .KEY fashion.

For a script that acts on a file dropped onto its icon — a common pattern for "converter" scripts — set the Default Tool to C:IconX and the script’s .KEY argument to expect a filename; dragging a file onto the icon runs the script with the dropped filename passed as the argument.

Which, Assign, Path, Alias, Set, SetEnv, Cd, Prompt and Version are the ones you already know. The Amiga-specific ones worth having in your fingers:

The section previously kept as an appendix. Print it and pin it above your emulator; you will be reaching for it constantly for the first week.

The stock Shell is fine. If you use the Shell heavily, install one of:

For OS 3.2 the stock Shell is meaningfully improved (persistent history, better line editing) and you may not need a replacement.

Next: what programs to actually run.

MicroEmacs (uEmacs/PK) ships with the SAS/C developer install and is on Aminet. It is real Emacs, in miniature: buffers, kill ring, regexps, keyboard macros. If you want Emacs fingers, this is it.

GoldED / CygnusEd Professional — the two long-standing commercial-quality editors. CygnusEd is now free; GoldED (also known as "Ed" in its later releases) has a mature Amiga-native UI. Either is closer to a modern GUI editor than a terminal one.

TextEdit ships in SYS:Utilities. Fine for editing scripts and preferences files; not intended for programming.

MEmacs — the OS’s own EMACS-in-miniature in SYS:Tools/MEmacs. Small, fast, no extensions. Good enough for Startup-Sequence edits.

If you must have modern vi or emacs: Vim has a stable 68k Amiga port on Aminet (text/edit/vim…​). Emacs 25 has been ported by third parties for AmigaOS 4.

Final Writer is the classic Amiga word processor — WYSIWYG, prints beautifully via PRT:, imports and exports RTF. Freely available since the mid-2000s when the developer released it. Ships in most modern OS 3.2 install bundles.

Wordworth — the other contender. Softwood released the last version (Wordworth 7) as freeware.

AbiWord was ported to AmigaOS 4 and MorphOS; it opens .docx well enough for most purposes.

AmiSpread and PageStream cover spreadsheets and DTP respectively. PageStream 5 is still commercially maintained by its original developer.

There is no LibreOffice on classic Amiga. If you need to read .docx or .xlsx on a stock 68k machine, convert on another machine first, or use a network share.

The state of the web-on-Amiga is a real problem, because a modern browser is a hundred million lines of C++ and the Amiga does not have a working port of one.

If you want to actually use the web on a classic Amiga in 2026, the honest workflow is:

YAM (Yet Another Mailer) — the standard 68k mail client. IMAP, POP3, SMTP with STARTTLS. MUI-based, extensively documented, actively maintained through 2026.^[21]

SimpleMail — a smaller alternative. Also cross-platform (68k, OS 4, MorphOS, AROS).

For a command-line mail workflow, Grn and muMail exist but are niche. In practice, YAM covers everything most users want.

AmIRC — the classic IRC client, commercial in the 1990s, freeware since. Still the reference.

WookieChat — active-development IRC client, MUI-based, still receiving updates.

Kwakk — Matrix client for AmigaOS 4.

XMPP support exists via AmiJabber. Discord and Slack do not have first-party Amiga clients; Matrix bridges via Kwakk are the usual answer.

Directory Opus 5 Magellan II is one of the most beloved pieces of Amiga software ever written. Twin-pane file manager, scriptable in ARexx, extensible with modules, comes with a fully replaceable Workbench. Open-sourced by Jonathan Potter in the late 2010s and now actively maintained by the community as DOpus5.^[22]

Filer and DiskMaster are the older / lighter alternatives.

If you spend serious time in files, install DOpus.

Personal Paint — Commodore’s own bitmap paint program, released as freeware. Supports palette animation, custom brushes, IFF and GIF. Nice for pixel art.

ImageFX — professional bitmap editor with rich colour handling, scripting via ARexx, and a plugin ecosystem. Now freeware.

Photogenics — layered non-destructive editor from the mid-1990s. Nova Design has released the final version as freeware. Good for photo work; still one of the nicer UIs on the platform.

MultiView ships in SYS:Utilities. It uses the Datatypes system to display any registered format — IFF, GIF, JPEG (with a datatype installed), PNG, animations, PostScript. Every graphics app worth having installs its formats' datatypes so MultiView can preview them.

For vector work, DrawStudio is the traditional Amiga vector package; HighlightPro and PageStream (which is DTP but includes vector drawing) are the alternatives.

For 3D, the classic is Lightwave 3D — the same package used to make Babylon 5 — but by 1998 it had migrated off the Amiga. Modern 3D work on AmigaOS is possible but niche; Cinema 4D was Amiga-native through 1997.

ProTracker — the four-channel MOD tracker that defined a generation of demoscene music. Now open-source and actively maintained; the current 68k version tracks the original ProTracker 2.3D.^[23]

OctaMED SoundStudio — the big brother: eight+ channels, MIDI support, richer editing.

HippoPlayer and DeliTracker are the music players — both handle almost every known Amiga music format.

AHI (Audio Hardware Interface) is the standardised audio API, present on any modern install; higher-quality sound cards route through it.^[24]

For MIDI, Bars & Pipes Professional was the flagship sequencer; it is still workable on modern configurations and there is an active user community.

For DAW-style work with samples, look at Symphonie Pro or — for anything serious in 2026 — accept that the workflow is "tracker on the Amiga, mix on the host."

MainActor and Fiasco/Wildfire were the video editors of the 1990s Amiga. The state of the art has moved on. Modern practical approaches:

The Video Toaster is a chapter of history rather than a current tool.

The full C toolchain lives in Chapter 14. In brief:

For encoded audio and video, install the CyberSound and akMPEG datatypes on OS 3.x, or use MPlayer on OS 4.

For hard drive management, HDToolBox (in SYS:Tools) is Commodore’s original; MediaToolBox is a more capable modern replacement.

Amiback and Quarterback were the commercial backup tools. Freely available now. For modern workflows, the common answer is:

Getting from the shopping list above to actual working workflows.

Aminet, in this order of frequency:

For OS 4-specific packages use https://os4depot.net/; for AROS use https://archives.aros-exec.org/.

Next: writing your own.

An OCS or ECS Amiga is a Motorola 68000 CPU wired to two shared memory regions (chip and — if fitted — fast) and three custom DMA-capable chips (Agnus, Denise, Paula), plus two general-purpose I/O chips (Complex Interface Adapters, CIA-A and CIA-B). AGA machines replace Denise with Lisa and Agnus with Alice, boosting the custom-chipset capabilities, but preserve the same overall topology.

The trick is that the CPU and the custom chips share the chip- memory bus by time-slicing. Every "cycle" (280 ns on a 7 MHz NTSC Amiga) is divided into two halves. Odd cycles are handed to Agnus’s DMA engines by default; even cycles are handed to the CPU. When DMA doesn’t need the bus, the CPU gets those cycles too. This is why a stock 68000 in an Amiga executes at approximately the same speed as a stock 68000 not in an Amiga: DMA and CPU access are interleaved.

The custom-chip DMA slots per horizontal scan line are budgeted strictly. In a 320×256 low-res 4-plane display the Copper takes some slots, the bitplane-DMA takes 4 out of 8, the sprites take 16 slots at the start of each line, and so on. Detailed slot diagrams are in the HRM, chapter 7.^[28]

The Motorola 68000 in a stock Amiga runs at:

Nothing about the CPU is Amiga-specific — it is the same CPU Apple put in the Mac 128K, Atari put in the ST, and Sun put in early workstations. The 68000 has:

The 68000 has no MMU, no cache, no floating-point unit, no memory-protection. Chapter 2 covered what those absences imply for the OS design; the physical consequence is that any address in the 24-bit space is legal to read or write from anywhere in the machine.

Successors — the 68010, 68020, 68030, 68040, 68060 — all fit into the same socket electrically (with some caveats) and are mostly upward binary-compatible. The 68020 introduced a 32-bit external data bus and a full 32-bit address bus (4 GB addressable), the 68030 added a paged MMU and instruction / data caches, the 68040 and 68060 added floating-point on-die and much higher clock rates. All of them are supported by the Amiga OS through the same exec.library.

The 68000’s 24-bit address space (16 MB) is divided into fixed regions:

The custom-chip registers at $DFF000 are the heart of Amiga programming when you go below the OS. Every register is 16 bits. Most are write-only from the CPU; reading them gives back different data (the Copper or hardware state, not what you last wrote). A few are read-only.

On AGA the map extends into the 32-bit address space and Zorro III cards autoconfig into the range from $40000000 upwards. The 24-bit chip-register aperture at $DFF000 is preserved for backward compatibility.

The Amiga has approximately 250 chip registers, each with a symbolic name and a fixed offset from $DFF000. A small sampling:

You write to a register with a MOVE.W #value, $dff100 in 68k assembly, or a *(volatile UWORD *)0xdff100 = value; in C. Except you almost never do — the OS wraps everything you would want in graphics.library, intuition.library and hardware/custom.h.

The exceptions are the demo/game side of Amiga programming, and they are worth understanding at least in outline. If you ever see code like:

what is happening is a direct write to $DFF180 and $DFF182 via the struct Custom overlay declared in hardware/custom.h. The declaration:

Full list is in hardware/custom.h.

Agnus (Address GeNerator UnitS) is the bus master. Its responsibilities:

Revisions of Agnus:

The Copper’s instruction set has just two opcodes (WAIT and MOVE) plus a SKIP. Programs are stored in chip memory, called a "Copper list." A Copper list is executed once per frame, starting at the beginning of vertical retrace. When it hits WAIT $FFFF, $FFFE (wait for beam position that never happens) it stops until the next frame.

A minimal Copper list to force a red background:

Encoded as three 16-bit words. graphics.library’s Copper allocation functions (`AllocCopperListTags, AddInterrupt with INTB_COPER) let you install this without touching the hardware directly.

The Copper is what makes Amiga demos look like Amiga demos. Sixteen-colour palette but 4096 apparent colours in the scene? Copper list re-writes COLOR00–COLOR15 between every scan line. Impossible-looking sprites bigger than the sprite hardware allows? Copper re-uses each hardware sprite three or four times per frame at different vertical positions.

Also in Agnus. The Blitter is a hardware DMA engine that performs rectangular memory operations on chip RAM. Its capabilities:

The Blitter is what draws Amiga sprites, scrolls playfields, fills polygons, and draws the entire Workbench window system. Every RectFill(), Move/Draw, or BltBitMap() call in graphics.library maps to a Blitter operation under the hood.

You control the Blitter through registers BLTCON0 and BLTCON1 (source configuration and modes), BLTAxxx, BLTBxxx, BLTCxxx (source addresses, per-source modulos), BLTDxxx (destination), BLTSIZE (kicks off the operation).

Full API in the HRM, chapter 6, and — for the OS-level wrapper — the RKM Libraries volume on graphics.library.

Denise (OCS/ECS) and Lisa (AGA) are the video output chips. Responsibilities:

Revisions:

Paula is the "everything else" chip — Peripherals / Audio / UART / Logic Array. Not a great acronym; it is named after the wife of one of the designers.

Responsibilities:

Paula’s audio is one of the reasons the Amiga was significant. Four independent 8-bit DMA channels sound very modest by modern standards, but in 1985 no other home computer had DMA audio at all — samples had to be polled from the CPU. The Amiga could play back a four-part sample-based track (a MOD file) in the background at CD-quality bit depth while the CPU did other work. The entire tracker scene of the late 1980s grew out of exactly this capability.

Paula has not changed across chipset revisions — the same chip is in an A1000 and a stock A4000. The Amiga’s four-channel audio is a floor that never rose.

Two general-purpose peripheral chips, MOS 8520. Each has:

They are Amiga versions of the classic 6526 CIA from the Commodore 64, with Motorola bus interface changes.

CIA-A is at $BFE001; CIA-B is at $BFD000. On the Amiga:

If you have ever wondered how the Amiga can be a floppy drive one moment and a serial modem the next moment with no special hardware, the answer is "the CIAs are general-purpose enough that Commodore’s engineers wired every peripheral through them."

The three chipset generations of classic AmigaOS-era hardware:

EHB is "extra half brite" — a hardware mode on OCS/ECS that doubles the palette to 64 by adding the same colours at 50% intensity. Very common on early games.

HAM (Hold-And-Modify) — see chapter 10.

The reason the OCS-to-AGA jump is not larger is that Commodore was competing with successor products they never shipped. The AAA chipset (Advanced Amiga Architecture) was in development from 1990 and would have offered true 24-bit graphics, hardware-accelerated 3D, and much higher DMA bandwidth; the Hombre chipset (a PA-RISC-based Amiga-successor) was in earlier development. Neither was finished before Commodore ran out of money in 1994.

Kickstart is the operating system’s kernel plus a set of essential libraries, in ROM. A 512 KB Kickstart 3.2 ROM contains:

Everything else — Workbench itself, most C: commands, most libraries in LIBS:, prefs, fonts — lives on disk.

The physical ROM chip:

At power-on, the CPU begins fetching from $000000. Kickstart maps itself into the low 4 KB at reset time — the reset code lives there — then remaps chip RAM into $000000 and executes from ROM at $F80000 for the rest of the boot process.

For a bare-metal programmer this matters because it means the exception vector table — the 68000’s list of where to jump on interrupts, traps and exceptions — lives at the bottom of chip RAM after boot and is patched by Kickstart. Exec provides SetIntVector() and SetExcept() for user-code access.

Next: the expansion side — Zorro, PCMCIA, IDE, SCSI, accelerator cards, and the AutoConfig protocol that makes the whole thing plug-and-play a full decade before PCI managed the same.

The Amiga had three generations of expansion bus, all called "Zorro" but differing in physical form and electrical capability.

Physically, Zorro II slots and Zorro III slots are the same 100-pin edge-card connector, so a Zorro II card fits fine in a Zorro III slot (the machine autoconfigures it as Zorro II). This is one of Commodore’s better engineering decisions — software written for Zorro II runs unmodified on Zorro III hardware; only when the card wants Zorro III’s extended capabilities (32-bit addressing, bus mastering, faster clock) does it need to be Zorro-III-aware.

Every well-designed Zorro card has a small AutoConfig ROM mapped into a fixed window at $E80000. At boot, the Kickstart ROM runs an autoconfig walker that:

The process takes a fraction of a second. After it completes, every card in the machine has a unique address range and is addressable from software.

The manufacturer IDs are unique small integers. Commodore maintained a registry through 1994; the assignments are preserved on https://amiga.resource.cx/manuf.pl. Notable IDs:

A card’s manufacturer_id + product_id pair uniquely identifies its type; a driver looks for its own pair via expansion.library’s `FindConfigDev().

Where PCI achieved plug-and-play via the PCI Configuration Space read via config-cycles, Zorro achieved it via a memory-mapped ROM at a known aperture. The elegance is that software above the driver level sees exactly the same "structure of ConfigDev nodes" regardless of Zorro version, so a 1990-vintage driver still works in a 2026-vintage system.

From your programs (usually a driver’s boot code):

FindConfigDev walks the OS’s internal list of AutoConfig’d boards. Any driver that wants to enumerate its own hardware starts here.

The struct ConfigDev gives you everything you need to talk to the card: its base address, its size, a pointer to its optional driver-init ROM (if any), and the struct ExpansionRom that was read at boot time. If the card exposed a driver ROM, Kickstart may have already loaded and initialised it — otherwise your driver has to LoadSeg() its own binary from LIBS: or wherever.

Not every expansion needs a full Zorro slot. Every A500, A500+, A600 and A1200 has a trapdoor slot on the underside of the case, providing:

Trapdoor expansion is a real advantage of the Amiga’s home- computer heritage. You do not need to open the case with a screwdriver; you flip the machine over, pop a panel, slide the card in. Twenty-year-old A500s in retro shops still have functioning trapdoor slots.

The A1200, A3000, A4000 and larger machines have a dedicated CPU expansion slot (a 200-pin connector on the A3000 side, a 150-pin trapdoor slot on the A1200). This slot exposes the raw 68000/020/030 bus and is used for:

CPU-slot cards can be very high-bandwidth — they have direct access to the CPU bus with no arbitration. This is why the Vampire V4 accelerator can achieve genuinely modern performance out of a stock A600 chassis.

The A600 and A1200 have a PCMCIA Type II slot on the left side. This is the standard IBM/JEIDA PC Card slot, so any PCMCIA device with an Amiga-compatible driver works: Ethernet cards, modems, compact-flash-to-PCMCIA adapters (a common way to give these small Amigas storage), SCSI hosts, sound cards.

Popular PCMCIA cards on Amiga:

Storage expansion on the Amiga:

The catalogue you would encounter in a well-equipped 1994 Amiga tower:

If you want to write a driver:

For most modern users this is not relevant — you use pre-built cards with pre-built drivers. But knowing the shape of the system explains why an Amiga you bought in 1994 with a card someone made in 1990 still boots and works in 2026 without a driver update.

Next: the early-software-development story, including the tools Commodore used to build Kickstart itself and the cross-develop- ment workflow that ran on Sun workstations in 1985.

Amiga executables are in Hunk format. A hunk is a chunk with a type: code hunk, data hunk, BSS hunk, reloc32 hunk, symbol hunk, and a couple of others. LoadSeg() — the DOS function that loads an executable — walks the hunk list, allocates memory for each code and data hunk, applies relocations, and returns a segment list you can jump into with CreateNewProc() (or that dos.library will jump into for you).

Practical consequence: there is no fixed base address. Every code and data address in your program is relocated at load time. Position independence would be a fine feature to have, but the classic compiler toolchains do not produce it; they produce relocations, and LoadSeg() applies them.

You do not have to know this to write programs. You do have to know it when you look at List output and see a 4 KB executable that does far more than 4 KB should — one of its hunks is a 64 KB BSS that costs nothing on disk.

The easiest modern developer experience is cross-compiling. Bebbo’s GCC packages install cleanly on macOS via Homebrew and on Linux via the project’s own installer script.

Once installed, you can compile a native Amiga executable on your Mac and run it under FS-UAE: