Every Amiga boot begins with a silent conversation between hardware and software — one conducted entirely through screen colors. Before a single library is loaded, before Intuition draws its first pixel, Exec's `ColdStart` routine subjects the machine to a gauntlet of integrity checks. Each test gates the next; failure at any stage halts the boot and paints the entire display a specific diagnostic color while blinking the power LED.
This document provides a complete architectural walkthrough of that self-test sequence as implemented in the Kickstart 3.x ROM, traced directly from the Commodore source code. It is intended for engineers performing board-level repair, emulator authors requiring cycle-accurate boot fidelity, and historians preserving the engineering decisions of the original Amiga team.
The boot diagnostic system operates in the narrow window between hardware RESET and the first multitasking context.
At this point, no operating system exists — there is no memory allocator, no interrupt handler, no stack beyond a hardcoded temporary at `$000400`. The CPU is in supervisor mode, and the only output device available is the Amiga custom chipset's color register at `$DFF180` (COLOR00).
This constraint dictates the architecture: **the entire diagnostic vocabulary is a single 12-bit RGB value written to a memory-mapped hardware register**. No text, no graphics, no blitter — just raw color.
The 68000 family reads two longwords (2x4 bytes) from address `$00000000` on RESET: the initial Supervisor Stack Pointer and the initial Program Counter. Because the ROM overlay maps Kickstart ROM into this space, the CPU begins execution at the address stored in the ROM header — which is always `ColdStart` at offset `$D2` from the ROM base.
```
ExecOrigin: DC.W BIG_ROMS ; ROM identification ($1114)
DC.W JMPINSTR ; $4EF9 — JMP absolute
DC.L ColdStart ; Must be $FC00D2 or $F800D2
```
> **Why $D2?** A quirk of history. In environments with virtual-memory ROM remapping (SuperKickstart), a software RESET re-maps the physical ROM to low memory. Unless the ColdStart entry point is at a fixed offset that matches across both the physical and virtual address spaces, the machine crashes. The offset `$D2` is that hardcoded contract.
---
## 2. The Color Code Dictionary
All diagnostic color constants are defined in `exec/constants.i` (lines 13–23). They use the Amiga's native 12-bit RGB format (`$0RGB`), written directly to the COLOR00 register at `$DFF180`.
The Amiga stores color as a 16-bit word, but only the low 12 bits are used in OCS/ECS: four bits per channel (`$0RGB`). To convert each 4-bit nibble (0–F) to its 8-bit equivalent (0–255), multiply by 17:
| 4-bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F |
> **AGA note:** The AGA chipset (A1200/A4000) extends COLOR00 to 24-bit (8 bits per channel) when `BPLCON3` bit `LOCT` = 1. In that mode the 12-bit conversion table above does not apply — each channel uses its full 8-bit value directly. Kickstart diagnostics always run in 12-bit mode since they execute before any AGA-specific setup.
These colors appear momentarily during a healthy boot, each signaling successful completion of a test phase. The grey intensifies as boot progresses — a deliberate design choice that gives the power-on sequence a visible "warming up" feel.
> **Design note:** In the production V40 ROM, only `OK_HARDWARE` survives — the intermediate grey stages (`OK_SOFTWARE`, `OK_RESLIST`, `OK_RESSTART`) were present in earlier revisions (visible in the RCS history of `constants.i`) but consolidated. The screen transitions from dark grey directly through to whatever the boot menu or Workbench draws. On a healthy machine, the grey flash is barely perceptible — lasting only the time it takes to checksum 512KB of ROM and verify chip RAM.
### 2.2 Fatal Diagnostic Colors (Boot Halted)
When any test fails, the color is loaded into `D0` and execution branches to `coldCrash`, which paints the screen and blinks the power LED before resetting.
| Constant | Value | Color | Failure | Source Test |
| `CC_EXCEPTION` | `$0FE5` |  **Yellow** | CPU exception before software setup | Bus/Address error or illegal instruction |
| `CC_NOMODULES` | `$0F0F` |  **Purple** | `InitCode(RTF_COLDSTART)` returned | No bootable resident modules found |
| `CC_BADCHIPS` | `$000F` |  **Blue** | Custom chip register test failed | *(Commented out in V40 — was for early hardware)* |
R --> CRASH["coldCrash<br/>LED blink ×10<br/>→ RESET"]
G --> CRASH
P --> CRASH
Y --> CRASH
```
---
## 3. The ColdStart Sequence — Phase by Phase
The following sequence diagram traces the exact order of operations from `RESET` through to `InitCode`. Every arrow represents a real instruction boundary in `coldstart.asm`.
```mermaid
sequenceDiagram
participant CPU as MC680x0
participant ROM as Kickstart ROM
participant CUSTOM as Custom Chipset
participant CIA as CIA-A
participant CHIPRAM as Chip RAM
participant LED as Power LED
Note over CPU: RESET asserted — all peripherals reset
CPU->>ROM: Read SP from $000000, PC from $000004
CPU->>ROM: JMP ColdStart ($FC00D2)
rect rgb(234, 234, 242)
Note over CPU,LED: Phase 1 — Stack + ROM Checksum
CPU->>CPU: LEA TEMP_SUP_STACK($400),SP
CPU->>ROM: Begin additive checksum of 512KB ROM
Note right of ROM: D5 accumulates carry-wrapped sum<br/>~34 cycles/longword @ 7.14 MHz
end
rect rgb(255, 232, 232)
Note over CPU,LED: Phase 2 — Diagnostic Cartridge Check
CPU->>ROM: Check $F00000 for DIAG_CART ($1111)
Note right of ROM: If found, JMP to cartridge<br/>(A5 = return address)
CPU->>ROM: Check PCMCIA credit card ($A00000)
Note right of ROM: Gayle attribute memory check<br/>for diagnostic code $23
end
rect rgb(232, 245, 232)
Note over CPU,LED: Phase 3 — Hardware Reset
CPU->>CIA: CLR.B _ciaapra (LED ON, overlay OFF)
Note right of CIA: Chip RAM now visible at $000000!
CPU->>CUSTOM: Disable all interrupts ($7FFF → INTENA)
CPU->>CUSTOM: Clear all interrupts ($7FFF → INTREQ)
CPU->>CUSTOM: Disable all DMA ($7FFF → DMACON)
CPU->>CUSTOM: BPLCON0 ← COLORON ($0200)
CPU->>CUSTOM: COLOR00 ← OK_HARDWARE ($0111)
CUSTOM-->>LED: Screen turns DARK GREY
Note right of LED: ← Brightness change visible here
end
rect rgb(255, 232, 232)
Note over CPU,LED: Phase 4 — ROM Checksum Verification
CPU->>CPU: NOT.L D5 — should yield 0 if good
alt D5 ≠ 0
CPU->>CPU: D0 ← CC_BADROMSUM ($0F00)
CPU->>CUSTOM: coldCrash → RED SCREEN
end
end
rect rgb(232, 245, 232)
Note over CPU,LED: Phase 5 — Chip RAM Write-Verify
CPU->>CHIPRAM: Fill vectors $08–$B7 with coldExcept pointer
CPU->>CHIPRAM: Read back all vectors top-down
alt Any mismatch
CPU->>CPU: D0 ← CC_BADRAM ($00F0)
CPU->>CUSTOM: coldCrash → GREEN SCREEN
end
end
rect rgb(232, 234, 255)
Note over CPU,LED: Phase 6 — CPU Detection + Memory Sizing
CPU->>CPU: BSR TypeOfCPU → AttnFlags
CPU->>CHIPRAM: Size chip RAM in 16KB blocks
Note right of CHIPRAM: Write magic $0F2D4B689, check<br/>for shadows at $000000
CPU->>CHIPRAM: Build temporary MemList header
end
rect rgb(234, 234, 242)
Note over CPU,LED: Phase 7 — ExecBase + Module Init
CPU->>CHIPRAM: Allocate ExecBase from chip RAM
CPU->>CPU: Build function table (MakeFunctions)
CPU->>CPU: FindCodeBefore — scan for ROMTags
CPU->>CPU: InitCode(RTF_SINGLETASK)
Note right of CPU: Hands off to strap → DOS
alt InitCode returns (shouldn't)
CPU->>CUSTOM: COLOR00 ← CC_NOMODULES ($0F0F)
Note right of CUSTOM: PURPLE SCREEN — infinite loop
end
end
```
### Phase 1: Stack Initialization + ROM Checksum (lines 296–420)
The very first instruction sets the supervisor stack to `$000400` — a fixed address below the allocatable chip RAM region. The comment in the source reveals a concern:
```asm
LEA.L TEMP_SUP_STACK,SP ;:TODO: Do games use this area?
;(I attempt to stay clear...)
```
Simultaneously, the ROM checksum begins. For 512KB ROMs (`ROM_SIZE = $80000`), this is a double-nested `DBRA` loop performing an additive wraparound-carry checksum across 131,072 longwords:
```asm
lea.l ExecOrigin,a0
moveq.l #-1,d1 ; first DBRA — 64K longwords
moveq.l #((ROM_SIZE/4)-1)>>16,d2 ; second DBRA — handles >256K
moveq #0,d5 ; accumulator
cs_chksum:
add.l (a0)+,d5 ; 12 cycles (nominal)
bcc.s cs_nooverflow ; 12 cycles
addq.l #1,d5 ; carry wraparound
cs_nooverflow:
dbra d1,cs_chksum ; 10 cycles
dbra d2,cs_chksum
```
The ROM is checksummed such that the final value in `D5` should be `$FFFFFFFF`. A `NOT.L D5` converts this to zero; any non-zero result triggers `CC_BADROMSUM`.
> **Timing:** At ~34 cycles per longword on a 68000 at 7.14 MHz, checksumming 512KB takes approximately **620 ms** — the bulk of the visible grey-screen duration on a stock A500/A2000.
### Phase 3: The Grey Screen Moment (line 576)
This is the earliest visible output from the CPU, and it's the exact moment that tells a technician whether the processor is alive:
```asm
LEA.L _custom,A4 ; chipset base = $DFF000
MOVE.W #$7FFF,D0
MOVE.W D0,intena(A4) ; kill all interrupts
MOVE.W D0,intreq(A4) ; clear pending interrupts
MOVE.W D0,dmacon(A4) ; kill all DMA
MOVE.W #BAUD_9600,serper(A4) ; debug serial @ 9600 baud
MOVE.W #COLORON,bplcon0(A4) ; enable color burst
MOVE.W #0,bpldat(A4) ; clear bitplane data (can't use CLR.W!)
MOVE.W #OK_HARDWARE,color(A4) ; ← DARK GREY SCREEN
```
> **The `CLR.W` trap:** The 68000's `CLR` instruction performs a read-modify-write cycle. For write-only hardware registers like `BPLDAT`, this read triggers undefined behavior. The Commodore engineers use `MOVE.W #0` instead — a write-only operation. This detail is explicitly called out in the source comment.
### Phase 5: The Chip RAM Test (lines 730–750)
The chip RAM test is deliberately minimal. Rather than a comprehensive memory sweep (which would be slow and complicated by cache coherency issues), ColdStart uses the exception vector table as a proxy:
```asm
; Fill vectors $08 through $B7 with a known pointer
move.l #BusErrorVector,a0 ; A0 = $00000008
move.w #($B4>>2),d1 ; 45 vectors
lea.l coldExcept(pc),a1 ; known good ROM address
cs_fillExcept:
move.l a1,(a0)+
dbra d1,cs_fillExcept
; Now verify — read back top-down
move.w #CC_BADRAM,d0 ; pre-load GREEN in case of failure
move.w #($B4>>2),d1
cs_checkExcept:
cmp.l -(A0),A1 ; tops down!
bne coldCrash ; → GREEN SCREEN
dbf D1,cs_checkExcept
```
The comment in the source explains the philosophy:
> *"This is a cheap power-on-only test for bad chip memory. On soft reboot the caches might invalidate this test. Oh, well."*
The test writes 45 longwords (180 bytes) into the lowest 184 bytes of chip RAM and reads them back. If even one bit flips, the entire machine is declared dead. This is the test that produces the **green screen** — the most commonly observed diagnostic color on faulty Amigas.
---
## 4. The coldCrash Handler
When any diagnostic test fails, execution converges on a single handler: `coldCrash`. This routine is the Amiga's equivalent of a PC's POST beep code — a last-resort communication channel when the system cannot boot.
### 4.1 The Handler — Annotated Source
```asm
; coldstart.asm, ~line 1185
;
; Entry: D0.W = diagnostic color code (e.g., CC_BADRAM, CC_BADROMSUM)
; Environment: Supervisor mode, no stack safety, no OS
;
coldCrash:
LEA _custom,A4 ; A4 = $DFF000
MOVE.W #COLORON,bplcon0(A4) ; enable color output
MOVE.W #0,bpldat(A4) ; blank bitplanes (solid color fill)
MOVE.W D0,color(A4) ; PAINT THE SCREEN with diagnostic color
;------ blink the LED 10 times:
MOVEQ #10,D1 ; outer loop: 10 blinks
MOVEQ #-1,D0 ; inner loop: 65535 iterations
cc_on:
BSET.B #CIAB_LED,_ciaapra ; LED OFF (active low!)
DBF D0,cc_on ; ~590ms delay
LSR #2,D0 ; D0 = $3FFF — shorter OFF phase
cc_off:
BCLR.B #CIAB_LED,_ciaapra ; LED ON
DBF D0,cc_off ; ~150ms delay
DBF D1,cc_on ; repeat 10 times
; Fall through to CrashReset...
```
### 4.2 The LED Blink Pattern
The asymmetric duty cycle produces a distinctive blink pattern. The CIA-A LED is **active low** — `BSET` (set bit) turns it OFF (dark), `BCLR` (clear bit) turns it ON (bright). The code spends `$FFFF` iterations in the OFF (dark) phase (~590 ms) and only `$3FFF` iterations in the ON (bright) phase (~150 ms):
Total blink duration: approximately **7.4 seconds** on a 68000 (faster on 68020+). After the blink sequence, the screen fades to black and the machine resets via `GoAway` (which executes the `RESET` instruction followed by `JMP` to the ROM entry point).
### 4.3 State Machine
```mermaid
stateDiagram-v2
[*] --> ColdStart: RESET Vector
state "ColdStart Tests" as Tests {
[*] --> ROMChecksum
ROMChecksum --> VectorVerify: Checksum OK
VectorVerify --> CPUDetect: RAM OK
CPUDetect --> MemorySizing
MemorySizing --> ExecBaseAlloc
ExecBaseAlloc --> InitCode
}
state "coldCrash" as Crash {
[*] --> PaintScreen: D0 = color code
PaintScreen --> LEDBlink: 10× asymmetric blink
LEDBlink --> FadeToBlack: $15000 delay loop
FadeToBlack --> GoAway: RESET + JMP
}
state "coldExcept" as Except {
[*] --> SaveRegs: Debug build only
SaveRegs --> SetYellow: D0 ← CC_EXCEPTION
}
Tests --> Crash: Any test failure
Tests --> Except: CPU exception
Except --> Crash: Fall through
ROMChecksum --> Crash: CC_BADROMSUM (RED)
VectorVerify --> Crash: CC_BADRAM (GREEN)
InitCode --> Crash: CC_NOMODULES (PURPLE)
GoAway --> [*]: Machine reboots
InitCode --> BootMenu: Success — OS takes over
```
### 4.4 The coldExcept Path
If the CPU takes a bus error, address error, or illegal instruction *before* the real exception handlers are installed, execution lands in `coldExcept` (~line 1150). This handler:
1. Saves all registers to fixed memory locations (`REG_STORE` at `$180`, `USP_STORE` at `$1C0`) — but only in debug builds
2. Loads `CC_EXCEPTION` (`$0FE5`, yellow) into `D0`
3. Falls through to `coldCrash`
In production ROMs, the register dump is compiled out, and the yellow screen is the only output.
---
## 5. Machine-Specific Variants
The boot test sequence is configured at assembly time via `romconstants.i`, which selects parameters based on the target machine. The color diagnostic system itself is identical across all platforms — but the *context* surrounding it differs.
### 5.1 Configuration Matrix
| Machine | Symbol | ROM Base | Checksum | A3000 Logic | Cold-PUD | Overlay |
|---|---|---|---|---|---|---|
| A500/A600/A2000 | `MACHINE_A2000` | `$F80000` | ✅ | No | No | CIA-A bit 0 |
D -->|"No (warm reboot)"| G["Preserve ExecBase<br/>Check ColdCapture"]
E --> H["Clear PUD bit 7"]
G --> H
H --> F
```
> **Why this matters for diagnostics:** On an A4000 showing a **black screen** (no grey flash at all), the PUD path is suspect. If Gary's bus timeout registers are corrupted (common with battery leakage near U177), the CPU may never reach the `OK_HARDWARE` color write — producing the "black screen, no brightness change" symptom described in Hertell's troubleshooting guide.
---
## 6. The Diagnostic Cartridge Intercept
Between the ROM checksum and the hardware reset, ColdStart checks for diagnostic cartridges — external ROM modules that can intercept the boot process before the operating system initializes.
B -->|Found| C["JMP $F00002<br/>(Cartridge Entry)"]
B -->|Not found| D{"Gayle present?<br/>(A1200/A4000)"}
D -->|Yes| E{"PCMCIA card at<br/>$A00000 has<br/>diag code $23?"}
D -->|No| F["Continue Boot"]
E -->|Yes| G["JMP to card<br/>COM memory"]
E -->|No| H["Disable PCMCIA<br/>(GAYLE_STATUS)"]
H --> F
C -.->|"A5 = return addr"| F
G -.->|"A5 = return addr"| F
```
Two cartridge types are supported:
1.**Expansion ROM cartridge** ($F00000): The classic diagnostic cartridge slot. ColdStart checks for the magic word `DIAG_CART` (`$1111`) at `$F00000`. If found, it jumps to `$F00002` with the return address in `A5`.
2.**PCMCIA card** ($A00000): On Gayle-equipped machines (A1200, A600, A4000), ColdStart reads the PCMCIA attribute memory at `$A00000` looking for a specific tuple sequence: `$91, $05, $23` (diagnostic function code). If matched, it extracts a 4-byte offset from the following bytes and jumps to `CREDIT_COM + offset` (`$600000 + offset`).
> **Engineering note:** The diagnostic cartridge runs *before* chip RAM is verified. It has access to the ROM checksum result in `D5` and the return address in `A5`, but no stack, no RAM guarantees, and no operating system. Third-party diagnostic ROMs (like the "Logica Diagnostic ROM" or "DiagROM" mentioned in Hertell's troubleshooting) replace the Kickstart ROMs entirely and implement their own test suites.
---
## 7. Post-ColdStart Diagnostics
After `ColdStart` successfully hands off to `InitCode`, two additional diagnostic systems operate at higher levels of the boot process.
### 7.1 System Expansion Board Check (syscheck)
**Source:** `kickstart/bootmenu/old/syscheck/`
A ROM-tag module (`RTF_SINGLETASK`, priority set to run after expansion.library but before boot devices) that checks for expansion board memory failures during the autoconfig process.
```mermaid
flowchart TD
A["syscheck ROM module<br/>initializes"] --> B{"EBF_BADMEM flag<br/>set in<br/>ExpansionBase?"}
B -->|No| C["Exit silently<br/>(normal boot continues)"]
B -->|Yes| D["Open graphics View<br/>640×200 HIRES"]
D --> E["Draw RED screen<br/>Title: System Expansion Board Check"]
E --> F["List each ConfigDev:<br/>Status | Manufacturer | Product | Chain"]
F --> G["Render CONTINUE button<br/>with mouse sprite"]
G --> H["Wait for mouse click"]
H --> I["Close View<br/>Continue boot with<br/>bad device disabled"]
```
This is the **red diagnostic screen** with the device listing — distinct from the `CC_BADROMSUM` solid red screen. The `syscheck` screen has text, rendered using the graphics library's `Text()` call with a custom `RastPort`. It specifically flags devices whose `ConfigDev` structure has the `CDF_BADMEMORY` flag set.
> **Trigger mechanism:** Can also be forced by holding both mouse buttons during the boot cycle (noted in the source as "will be taken out before final release, or maybe it won't" — it wasn't).
### 7.2 The Alert System (alert.asm)
After ColdStart completes and the OS is running, hardware and software failures are reported through Exec's `Alert()` function — the infamous red/yellow "Guru Meditation" screen. This is architecturally separate from the ColdStart color diagnostics:
| Feature | ColdStart Colors | Alert System |
|---|---|---|
| **When** | Before OS exists | After OS is running |
| **Output** | Solid screen color | Red/yellow bars with hex error code |
| Brightness change → normal boot | All tests passed | Line 578 → `InitCode` |
### 8.3 Caps Lock Diagnostic (Not in ColdStart)
The "press Caps Lock 20–30 times" test mentioned in Hertell's guide is **not** part of the Kickstart diagnostic system. It exploits the fact that the keyboard controller (an independent 6500/1 microcontroller) toggles the Caps Lock LED autonomously. If the main CPU has crashed but the keyboard MPU is alive, Caps Lock will still toggle. If it stops responding after a few presses, the keyboard buffer is full because the CPU isn't draining it — confirming a CPU hang rather than a total system death.
---
## 9. Historical Context & Competitive Landscape
The Amiga's color-code POST system was designed in 1985 — an era when every home computer needed some way to communicate boot failures without a working display. The approach each platform chose reveals its hardware philosophy:
| **Amiga 1000–4000** | Full-screen solid color + LED blink | 5 colors (ROM, RAM, exception, modules, chips) | No — requires lookup table | Yes — maps to specific failed component |
| **IBM PC/AT (BIOS)** | POST beep codes via PC speaker | Dozens of codes (1-long-3-short = video, etc.) | Moderate — audible, documented in BIOS manuals | Yes — extensive service manuals map each code |
| **Macintosh 128K/512K** | "Sad Mac" icon + error code + chime variant | Chime type (normal, death chime) + hex code | Moderate — iconic Sad Mac face is recognizable | Yes — error codes map to specific hardware tests |
| **Atari ST** | None — silent boot | No diagnostics | N/A | No — technicians rely on scope/logic probe |
| **Commodore 64** | Black screen on failure, blue screen on success | Binary: works or doesn't | No — no codes | No — requires hardware troubleshooting |
| **Acorn Archimedes** | POST beep codes (similar to PC) | Multiple codes | Moderate | Yes |
**What made the Amiga approach unique:**
1.**Full-screen color fill** — not a beep, not a text code, but the entire display painted a single diagnostic color. This is immediately visible even on a monitor with dead sync or misadjusted brightness.
2.**No audio hardware needed** — the color system uses only the Denise/Lisa color register and CIA-A LED. The Paula audio chip, serial port, and floppy controller are all unverified at POST time. A beep-based system would require working audio DACs and speakers.
3.**LED blink confirmation** — the asymmetric blink pattern (long dark, brief bright) provides a secondary diagnostic channel independent of the display. If the monitor is disconnected, the LED pattern alone confirms the CPU reached `coldCrash`.
### Modern Analogies
| Amiga Concept | Modern Equivalent | Why the Analogy Holds | Where It Breaks Down |
|---|---|---|---|
| Grey screen flash (`OK_HARDWARE`) | UEFI firmware splash logo | Both confirm CPU executed first code | UEFI has a full framebuffer; Amiga has 12-bit color |
| Red/Green/Yellow/Purple screens | Motherboard 7-segment debug LEDs ("debug codes") | Both map specific codes to specific failures | 7-segment shows 2-digit hex; Amiga shows 1 color |
| `coldCrash` LED blink | Q-Code display on ASUS boards | Both provide secondary visual channel without display | Q-Code is numeric; Amiga blink is just presence/absence |
| ROM checksum (additive carry) | UEFI Secure Boot signature validation | Both verify firmware integrity before execution | Secure Boot uses PKI cryptography; checksum is trivially forgeable |
| Diagnostic cartridge ($F00000) | IPMI/BMC out-of-band management | Both allow external tools to intercept boot | BMC runs on a separate SoC; cartridge shares the main CPU |
| Exception vector test | RAM training / margin testing | Both validate memory before trusting it | Modern RAM training is per-DIMM, per-frequency; Amiga tests 180 bytes |
| `syscheck` expansion screen | Windows Device Manager yellow-bang | Both flag faulty hardware but allow boot to continue | `syscheck` disables the device; Windows may BSOD |
| Guru Meditation (post-boot) | Windows BSOD / Linux kernel panic | Both are last-resort crash displays | Guru shows hex alert number; BSOD shows driver name + stack trace |
> **Key design insight:** The Amiga POST uses the absolute minimum hardware — one color register, one CIA bit — because it must work when *everything else is broken*. Modern UEFI systems achieve the same goal with dedicated BMC chips and debug LEDs, but the principle is identical: diagnose using the simplest output path that could possibly work.
