mirror of https://github.com/alfishe/amiga-bootcamp.git synced 2026-06-12 16:16:28 +00:00

Ilia Sharin a0fc3e05db Restructure - dedicated for copper and blitter separate subfolders to have the room to expand

2026-05-31 13:52:45 -04:00

41 KiB

Raw Permalink Blame History

← Home · Hardware · Common

Video Signal & System Timing — Clock Derivation, Beam Mechanics, and Output Paths

Why It Matters

The Amiga is a video computer that happens to have a CPU. Jay Miner's original design started not with a processor specification, but with a television signal: generate legal NTSC composite video, then derive every other clock in the system — including the CPU clock — from the video crystal. This single decision shaped every aspect of Amiga performance, from why the 68000 runs at 7.09 MHz instead of its rated 8 MHz, to why changing your display mode changes how fast your code executes.

This architecture has no parallel in the IBM PC world, where CPU and video clocks are independent. The closest modern equivalent is an SoC with a unified memory architecture — Apple's M-series or AMD APUs — where the display engine and CPU share memory bandwidth and the display refresh rate constrains available compute cycles. On the Amiga, this coupling is absolute: every DMA slot, every Copper instruction, every Blitter cycle, and every CIA timer tick traces back to a single quartz crystal oscillating at 28.375 MHz (PAL) or 28.636 MHz (NTSC).

This article documents the complete signal path from crystal to screen — the clock tree, beam counter mechanics, sync generation, video output, genlock overlay, and display adaptation. It is the "timing and signal" companion to DMA Architecture (which covers bus bandwidth) and Display Modes (which covers the OS API layer).

Note

What this article covers vs. existing references:

Clock derivation and signal generation — primary coverage here

DMA slot allocation and bandwidth — see DMA Architecture

ModeID selection and OS display API — see Display Modes

Copper instruction programming — see Copper Programming

The Clock Tree — From Crystal to CPU

Master Oscillator

Every Amiga contains a single quartz crystal that serves as the master timing reference for the entire system. The frequency is chosen to produce a legal television color subcarrier:

Parameter	PAL	NTSC
Master crystal	28.37516 MHz	28.63636 MHz
Relationship to color subcarrier	4 × 4 × PAL Fsc	8 × NTSC Fsc
PAL color subcarrier (Fsc)	4.433619 MHz	—
NTSC color subcarrier (Fsc)	—	3.579545 MHz

Division Hierarchy

All system clocks are derived by integer division from the master crystal. No PLL, no frequency synthesis — just dividers:

graph TD
    XTAL["Master Crystal<br/>28.375 MHz (PAL) / 28.636 MHz (NTSC)"]
    DOT["Dot Clock  ÷2<br/>14.19 / 14.32 MHz<br/><i>Hires pixel rate</i>"]
    CPU["CPU Clock  ÷4<br/>7.09 / 7.16 MHz<br/><i>68000 system clock, lores pixel rate</i>"]
    CCK["Color Clock  ÷8<br/>3.55 / 3.58 MHz<br/><i>DMA slot width, Copper granularity</i>"]
    ECLK["E-Clock  ÷40<br/>709 / 716 kHz<br/><i>CIA timers, slow peripherals</i>"]

    XTAL --> DOT
    XTAL --> CPU
    XTAL --> CCK
    XTAL --> ECLK

Complete Clock Domain Table

Clock	Divisor	PAL Frequency	NTSC Frequency	Period	Drives
Master	÷1	28.37516 MHz	28.63636 MHz	~35 ns	Internal chipset logic
Dot clock	÷2	14.18758 MHz	14.31818 MHz	~70 ns	Hires/superhires pixels, shift registers
CPU / System	÷4	7.09379 MHz	7.15909 MHz	~141 ns	68000 CLK input, lores pixels
Color clock (CCK)	÷8	3.54690 MHz	3.57955 MHz	~282 ns	DMA slots, Copper WAIT resolution
E-clock	÷40	709,379 Hz	715,909 Hz	~1.41 µs	CIA-A/B timers, 6502-bus peripherals

Why the 68000 Runs Below Its Rating

The Motorola 68000 in the Amiga is rated for 8 MHz but clocked at ~7.09 (PAL) or ~7.16 (NTSC) MHz. This is not a cost-saving measure — it's a mathematical necessity. The CPU clock must be an exact integer fraction (÷4) of the master crystal to maintain synchronous bus access with the custom chipset. Agnus, Denise, and the 68000 all share Chip RAM on a time-division basis, and any frequency mismatch would corrupt DMA transfers.

Note

Fast RAM is not constrained by video timing. Accelerator boards with 68020/030/040/060 processors run at independent frequencies (14, 25, 33, 40, 50, 66 MHz) because Fast RAM lives on a separate bus that doesn't participate in DMA arbitration. The video-derived clock only constrains Chip RAM access.

The E-Clock — CIA Timer Reference

The E-clock is the slowest derived clock, running at 1/10th of the CPU clock (or 1/40th of the master crystal). Its unusual duty cycle — 4 clocks high, 6 clocks low (40/60) — comes directly from the 68000's legacy 6800-bus compatibility mode. The CIA chips (8520A) use the E-clock as their timer input:

CIA Timer	E-Clock Ticks	Duration (PAL)	Typical Use
1 tick	1	1.41 µs	Minimum timer resolution
1 scanline (~227 CCK)	~57	~80 µs	Raster timing reference
1 frame (PAL)	~17,734	20 ms	VBL interval
CIA-B TOD	counts VSYNC	20 ms/tick	Time-of-day clock

XCLK — External Clock Override

The master crystal can be overridden via the XCLK pin (pin 1 of the 23-pin video connector, active when /XCLKEN on pin 2 is asserted). Genlock devices use this to slave the entire Amiga clock tree to an external video source's timing, enabling frame-accurate overlay. When XCLK is active, the CPU clock, DMA timing, CIA timers, and all video generation shift to match the external reference — the entire machine runs at a slightly different speed.

Anatomy of a Scanline

A single horizontal scanline is the fundamental timing unit of the Amiga display. Understanding its internal structure is essential for Copper programming, DMA budget calculation, and genlock synchronization.

Horizontal Timing Structure

Each scanline consists of 227.5 color clocks (alternating 227 and 228 per line to maintain half-line interlace timing). The scanline is divided into distinct regions:

 ←────────────────── 227.5 color clocks ──────────────────→

 ┌──────┬──────┬─────────┬──────────────────────┬──────────┐
 │ SYNC │BLANK │  Back   │    Active Display    │  Front   │
 │      │      │  Porch  │  (visible pixels)    │  Porch   │
 └──────┴──────┴─────────┴──────────────────────┴──────────┘
 H=0                     H=$81                         H=$E3
         ← HBLANK →      ← DDFSTRT...DDFSTOP →

Color Clock Position Map

The beam's horizontal position is measured in color clocks (each = 2 lores pixels = 4 hires pixels). Position $00 is the start of HSYNC:

H Position (hex)	Region	Notes
$00–$03	HSYNC	Sync pulse generation
$04–$08	Back porch	Color burst inserted here (composite only)
$09–$18	Left blanking	Off-screen, DMA active (refresh, disk, audio, sprites)
$19–$27	Left border	Visible if overscan enabled, no bitplane data
$28–$D7	Active display	Bitplane DMA region (standard: $38–$D0)
$D8–$E2	Right border	Visible if overscan, no bitplane data
$E3	Front porch	Line ends, wraps to next

Mapping Positions

Color clocks, pixels, and DMA slots are all synchronized:

Unit	Per Scanline	Relationship
Master clocks	1,820	= 227.5 × 8
Dot clocks (hires pixels)	910	= 227.5 × 4
CPU clocks (lores pixels)	455	= 227.5 × 2
Color clocks	227.5	Base unit — 1 CCK = 1 DMA slot
DMA slots (even+odd)	227	Available for allocation (see DMA Architecture)

Beam Position to Screen Coordinates

The Copper and the CPU see beam positions in color clocks. Converting to pixel coordinates:

Lores pixel X  = (H_position - DDFSTRT) × 2
Hires pixel X  = (H_position - DDFSTRT) × 4
Screen pixel 0 = H position $81 (standard non-overscan)

The Copper's WAIT instruction compares against the beam position with 2-pixel (1 color clock) horizontal granularity — it cannot distinguish individual lores pixels within the same color clock.

HBLANK Registers (ECS/AGA)

On ECS and AGA machines, horizontal blanking boundaries are programmable via BEAMCON0:

Register	Address	Function
`HBSTRT`	$DFF1C8	Horizontal blank start position
`HBSTOP`	$DFF1CA	Horizontal blank stop position
`HSSTRT`	$DFF1C4	Horizontal sync start
`HSSTOP`	$DFF1C6	Horizontal sync stop
`HTOTAL`	$DFF1C0	Total color clocks per line − 1

On OCS, these values are hardwired in Agnus and cannot be changed.

Anatomy of a Frame

Vertical Structure

A complete video frame follows the same sync-blank-active-blank pattern vertically as a scanline does horizontally. The number of lines differs between PAL and NTSC:

Parameter	PAL (non-interlaced)	NTSC (non-interlaced)	PAL (interlaced)	NTSC (interlaced)
Total lines/field	312 or 313	262 or 263	625 (2 fields)	525 (2 fields)
Active display lines	256 (standard)	200 (standard)	512	400
VBLANK lines	~56	~62	~56/field	~62/field
Frame rate	50 Hz	~59.94 Hz	25 Hz	~29.97 Hz
Frame duration	20.0 ms	16.7 ms	40.0 ms	33.4 ms

Vertical Regions

Line 0 ──────────── VSYNC pulse (2–3 lines)
Line 3 ──────────── Post-equalization / blanking
Line ~26 ─────────── Active display begins (DIWSTRT vertical)
Line ~282 ────────── Active display ends (DIWSTOP vertical)
Line ~300 ────────── Pre-equalization
Line 312 ────────── Frame ends, beam retraces to top

The vertical blank interrupt (INTREQ bit 5, VERTB) fires at line 0 — the start of VSYNC — giving software the entire VBLANK period (~56 lines × ~64 µs ≈ 3.6 ms on PAL) to perform buffer swaps, input polling, and game logic before the beam reaches active display.

Interlace — Long Frame and Short Frame

Standard television produces interlaced images by alternating two fields: one draws even-numbered lines, the other draws odd-numbered lines. The Amiga implements this through the Long Frame (LOF) / Short Frame mechanism:

Short frame: 312 lines (PAL) / 262 lines (NTSC) — the beam returns to exactly the same starting position
Long frame: 313 lines (PAL) / 263 lines (NTSC) — the extra half-line shifts the beam by half a scanline height

In non-interlaced mode, every frame is a short frame (the beam always starts at the same position). In interlaced mode (BPLCON0 bit LACE set), Agnus alternates long and short frames automatically. The display hardware presents two different copper lists — LOFlist and SHFlist — allowing different bitplane pointers for even and odd fields.

The LOF Bit — Field Identification

VPOSR ($DFF004) bit 15 is the Long Frame (LOF) flag:

LOF Value	Meaning	Current Field
0	Short frame	Odd lines (field 1)
1	Long frame	Even lines (field 2)

Software that performs double-buffering in interlaced mode must check LOF to synchronize buffer swaps with the correct field. Writing to VPOSW can force LOF, but this is dangerous — it desynchronizes the interlace sequence and produces visible jitter.

Why Interlace Flickers

On a CRT, each field illuminates only half the lines. The phosphor on the non-illuminated lines decays between fields, producing visible 30/25 Hz flicker on high-contrast horizontal edges. This is a physical property of the display, not a chipset limitation — LCDs and FPGA scalers eliminate it entirely by buffering both fields.

Note

Flicker fixers (Commodore A2320, Indivision, modern scandoublers) solve interlace flicker by capturing both fields into a frame buffer and displaying the combined 512-line image at 50/60 Hz progressive scan. See Scandoublers & Flicker Fixers below.

Beam Counters and Position Registers

VPOSR — Vertical Position Read ($DFF004)

Bit 15:     LOF      — Long Frame flag (1 = long frame / even field)
Bits 14-8:  ID[6:0]  — Agnus chip ID (read-only)
Bit 0:      V8       — Bit 8 of vertical beam position (lines 256+)

The Agnus ID field identifies the chipset generation:

ID Bits [14:8]	Chip	Chipset
$00	8361 (Agnus, DIP)	OCS (A1000)
$00	8367 (Agnus, PLCC)	OCS (A500/A2000)
$20	8372A (Fat Agnus)	OCS (1 MB Chip)
$20-$22	8375 (Super Agnus)	ECS (A3000/A600)
$20-$23	8374 (Alice)	AGA (A1200/A4000)

VHPOSR — Combined Beam Position ($DFF006)

Bits 15-8:  V[7:0]  — Vertical position (low 8 bits)
Bits 7-0:   H[7:0]  — Horizontal position (in color clocks)

Combined with V8 from VPOSR, this gives the full beam position as a 9-bit vertical (0–312) and 8-bit horizontal (0–227) value.

Reading Beam Position — The Atomic Pattern

Reading VPOSR and VHPOSR separately risks a race condition at line boundaries (the vertical counter can increment between the two reads). The standard safe pattern reads both as a single longword:

; Safe beam position read — single longword access
    move.l  $DFF004, d0     ; d0 = VPOSR:VHPOSR (atomic longword read)
    ; d0 bits 24-16: V[8:0] (9-bit vertical line number)
    ; d0 bits 7-0:   H[7:0] (horizontal color clock position)

Wait for Specific Line

; Wait for beam to reach line 44 ($2C)
.wait:
    move.l  $DFF004, d0
    and.l   #$1FF00, d0     ; mask to vertical bits
    cmp.l   #$2C00, d0      ; line $2C shifted into position
    bne.s   .wait

Warning

Busy-waiting wastes CPU cycles. For game loops, prefer the VBL interrupt (INTREQ bit 5) or a Copper interrupt at the target line. Busy-waits also fail if system interrupts are enabled — interrupt handlers can cause the polling loop to miss the target line entirely.

VPOSW / VHPOSW — Write Registers ($DFF02A / $DFF02C)

These write-only registers can force the beam position. Legitimate uses:

Forcing LOF: toggling bit 15 of VPOSW to select the interlace field
Genlock synchronization: aligning the beam to an external source

Caution

Writing arbitrary values to VPOSW/VHPOSW corrupts the display timing. The beam counter is the master clock for all DMA scheduling — moving it desynchronizes bitplane fetch, sprite fetch, and audio DMA. Only genlock hardware and the OS should write these registers.

Raster Profiling — The Color-Change Trick

A classic demoscene technique for measuring CPU time consumption: change the background color at the start and end of a code section, then observe how many scanlines the color band spans:

    move.w  #$0F00, $DFF180     ; COLOR00 = red (start marker)
    bsr     ExpensiveRoutine
    move.w  #$000F, $DFF180     ; COLOR00 = blue (end marker)

Each visible scanline of red represents ~64 µs of CPU time (PAL). This technique is visible on real hardware, in WinUAE, and on MiSTer — it remains the fastest way to profile Amiga code.

Programmable Sync — BEAMCON0 (ECS/AGA)

OCS Limitation — Fixed Timing

On OCS (Agnus 8361/8367/8372), sync timing is hardwired. The horizontal total, sync pulse width, and blanking boundaries are fixed in silicon — the only things software can control are the display window (DIWSTRT/DIWSTOP) and data fetch positions (DDFSTRT/DDFSTOP). This means OCS machines can only produce 15 kHz PAL or NTSC compatible signals.

ECS Revolution — BEAMCON0 ($DFF1DC)

Super Agnus (8375) and Alice (8374) introduce BEAMCON0, a write-only register that switches horizontal and vertical timing from hardwired to programmable. This is how the Amiga gained support for productivity monitors, VGA-compatible output, and multiscan display modes.

BEAMCON0 Bit Map

Bit	Name	Function
15	HARDDIS	Disable hardwired limits (required for custom timing)
14	LPENDIS	Disable lightpen latch
13	VARVBEN	Variable vertical blank enable
12	LOLDIS	Long line disable
11	CSCBEN	Composite sync / blank enable
10	VARVSYEN	Variable VSYNC enable — use VSSTRT/VSSTOP
9	VARHSYEN	Variable HSYNC enable — use HSSTRT/HSSTOP
8	VARBEAMEN	Variable beam counter enable — use HTOTAL/VTOTAL
7	DUAL	Dual playfield beam counter mode
6	PAL	PAL/NTSC select (1 = PAL)
5	VARCSYEN	Variable composite sync enable
4	BLANKEN	Blank enable
3	CSYTRUE	CSYNC true polarity
2	VSYTRUE	VSYNC true polarity
1	HSYTRUE	HSYNC true polarity
0	—	Reserved

Associated Timing Registers

When VARBEAMEN is set, Agnus/Alice uses these registers instead of hardwired values:

Register	Address	Function	Default PAL
`HTOTAL`	$DFF1C0	Total H clocks per line − 1	$E3 (227)
`HSSTRT`	$DFF1C4	H sync start	$0F
`HSSTOP`	$DFF1C6	H sync stop	$19
`HBSTRT`	$DFF1C8	H blank start	$01
`HBSTOP`	$DFF1CA	H blank stop	$21
`VTOTAL`	$DFF1C2	Total V lines per frame − 1	$137 (311)
`VSSTRT`	$DFF1E6	V sync start	$02
`VSSTOP`	$DFF1E8	V sync stop	$04
`VBSTRT`	$DFF1E4	V blank start	$000
`VBSTOP`	$DFF1EA	V blank stop	$01C
`HCENTER`	$DFF1E2	H position for V sync in interlace (long field)	$71

Productivity / Multiscan Modes

By programming these registers to produce 31 kHz horizontal / 60 Hz vertical timing, ECS/AGA machines generate VGA-compatible signals. The A3000 was the first Amiga to ship with a multisync monitor as standard — its "productivity mode" (640×480 @ ~57 Hz) uses BEAMCON0 to generate the non-standard timing. See ECS Productivity Modes for register programming examples.

AGA extends this with DBLPAL (31.25 kHz, 50 Hz, 640×512) and DBLNTSC (31.47 kHz, 60 Hz, 640×400) scan-doubled modes that use BEAMCON0 internally.

Warning

BEAMCON0 can damage hardware. Incorrect sync timing values can produce signals outside a CRT monitor's operating range, potentially causing overheating of deflection circuits. Always validate timing against the target monitor's specifications. Modern flat panels are safe — they simply refuse to sync.

Video Output Signals — From Denise to the World

Signal Generation Pipeline

The Amiga's video output is a collaboration between Agnus (timing + DMA) and Denise/Lisa (pixel serialization + DAC):

graph LR
    subgraph Agnus_Alice["Agnus / Alice"]
        Beam["Beam Counter"]
        DMA["DMA Engine"]
    end
    subgraph Denise_Lisa["Denise / Lisa"]
        Shift["Bitplane Shift Registers"]
        Prior["Priority MUX<br/>(playfield + sprite)"]
        Palette["Color Lookup<br/>OCS: 12-bit / AGA: 24-bit"]
        DAC["R/G/B DACs"]
    end
    subgraph Output["Output"]
        RGB["Analog RGB<br/>(23-pin)"]
        CSYNC["Composite Sync"]
        DRGB["Digital RGB<br/>(internal slot)"]
    end

    DMA -- "bitplane/sprite data" --> Shift
    Beam -- "sync timing" --> CSYNC
    Shift --> Prior --> Palette --> DAC --> RGB
    Palette --> DRGB

23-Pin Video Connector (DB-23)

All Amigas from the A1000 through the A4000 use a female 23-pin D-subminiature connector for video output:

Pin	Signal	Description
1	XCLK	External clock input (genlock)
2	/XCLKEN	External clock enable (active low)
3	RED	Analog red (0–0.7 V)
4	GREEN	Analog green (0–0.7 V)
5	BLUE	Analog blue (0–0.7 V)
6	DI (intensity)	Digital intensity / OCS digital green MSB
7	DB	Digital blue
8	DG	Digital green
9	DR	Digital red
10	CSYNC	Composite sync
11	HSYNC	Horizontal sync
12	VSYNC	Vertical sync
13	GND	Ground
14	/PIXELSW	Pixel switch — genlock overlay control
15	C1	CCK clock phase 1
16	GND	Ground
17	GND	Ground
18	+5V	Power (active low, some models)
19	GND	Ground
20	GND	Ground
21	−5V	Negative supply (active low, some models)
22	+12V	Positive supply (active low, some models)
23	−12V	Negative supply (A1000 only)

Analog RGB Output

The primary video output is analog RGB on pins 3–5. The DAC resolution evolved with each chipset:

Chipset	DAC Resolution	Color Depth	Voltage Range
OCS (Denise 8362)	4-bit per channel	12-bit (4096 colors)	0–0.7 V
ECS (Super Denise 8373)	4-bit per channel	12-bit (4096 colors)	0–0.7 V
AGA (Lisa 4203)	8-bit per channel	24-bit (16.7M colors)	0–0.7 V

The analog output drives 75 Ω impedance loads directly — no external amplification needed for standard monitors. The A520 modulator (sold with the A500) converts the RGB output to composite NTSC/PAL for televisions.

Composite and S-Video

The Amiga does not natively generate composite video or S-Video on the 23-pin connector. These require external encoding:

A520 RF Modulator — converts RGB to composite NTSC/PAL + RF (channel 3/4)
Commodore A520 — external dongle, significant quality loss
A3000/A4000 internal encoder — some revisions include a composite encoder on the motherboard
Third-party cables — passive cables that combine sync with luma for S-Video-like output

Internal Video Slot (A2000/A3000/A4000)

The "big box" Amigas provide direct access to the chipset's digital RGB bus via an internal expansion slot:

Machine	Connector	Digital Bus Width	Purpose
A2000	2 × 36-pin edge	12-bit (4 bits/channel)	Genlock, flicker fixer, Video Toaster
A3000	2 × 36-pin edge	12-bit (4 bits/channel)	Same + productivity video
A4000	36-pin + 54-pin	24-bit (8 bits/channel)	AGA full-depth digital output

The video slot carries the raw digital pixel data before DAC conversion, system clocks (C1, CDAC, 7MHz), and sync signals. This is why the Video Toaster requires a big-box Amiga — it intercepts the digital stream for real-time switching and effects processing that would be impossible through the analog output alone.

Genlock, Video Overlay & Production

What Genlock Means

Generator Locking (genlock) is a broadcast television technique where one device slaves its timing to another's sync signal, ensuring both produce frames at exactly the same rate with zero phase offset. On the Amiga, this means replacing the internal crystal oscillator with an external reference derived from a video source — typically a camera, VTR, or character generator.

When genlocked, the Amiga's entire clock tree (CPU, DMA, CIA timers) shifts to match the external source's timing. The machine runs at a slightly different speed than its native PAL/NTSC rate.

The Overlay Mechanism

The Amiga was designed from the start to support video overlay — Jay Miner specifically included the genlock signals in the A1000's video connector. The overlay works through two mechanisms:

1. Clock Synchronization (XCLK / /XCLKEN)

The genlock device feeds a substitute master clock into pin 1 (XCLK) and asserts pin 2 (/XCLKEN) to activate it. Agnus's internal oscillator is bypassed, and the entire system locks to the external frequency. The PLL in the genlock device adjusts the XCLK frequency to maintain phase lock with the incoming video signal.

2. Pixel-Level Keying (/PIXELSW)

Pin 14 (/PIXELSW) is an active-low output from Denise/Lisa that indicates Color 0 (the background/transparent color) on a per-pixel basis. The genlock device uses this as a keying signal:

/PIXELSW State	Displayed Source
LOW (asserted)	External video (Amiga pixel is Color 0 = transparent)
HIGH (deasserted)	Amiga RGB (opaque pixel)

This creates a hardware chroma-key effect where any pixel drawn in Color 0 becomes transparent and the external video shows through — without any CPU involvement or software compositing.

Software Control — BPLCON0 Genlock Bits

BPLCON0 Bit	Name	Function
Bit 1	ERSY	Enable external resync — allow genlock to control beam
Bit 3	LPEN	Lightpen/genlock mode
Bit 9	GENLOCK_VIDEO	Enable genlock video output
Bit 10	GENLOCK_AUDIO	Enable genlock audio mixing

Genlock Device Catalog

Device	Connection	Features	Market
A2300	Internal (A2000)	Basic overlay, auto-config	Commodore OEM
SuperGen	23-pin external	Broadcast-grade, manual sliders, fade control	US broadcast
GVP G-Lock	23-pin + video slot	Software-controllable, multi-input, genlock + TBC	Professional
Hama 292	SCART-based	Simple overlay, PAL-optimized	European market
Mimetics AmiGen	23-pin external	Budget consumer genlock	Home/prosumer

NewTek Video Toaster

The Video Toaster is not merely a genlock — it is a complete broadcast production system that uses the A2000's video slot to:

Switch between 4 video inputs in real time (production switcher)
Apply effects — wipes, dissolves, and 3D page turns computed in custom hardware
Generate CG — broadcast-quality character generation (title overlay)
Capture frames — single-frame digitization to Chip RAM

The Toaster requires the internal video slot because it intercepts the raw 12-bit digital RGB bus, performs real-time switching in hardware, and feeds the composited result back to the output. This cannot work through the analog 23-pin connector due to DAC latency and analog noise. The later Video Toaster Flyer added non-linear editing capability, making the A2000+Toaster combination a complete post-production system used in broadcast television (notably Babylon 5, SeaQuest DSV, and hundreds of local TV stations worldwide).

Timing Side Effects of Genlock

When genlocked to an external source, the system clock deviates slightly from its nominal frequency:

CIA TOD counter: counts VSYNC pulses, so the time-of-day clock tracks the external field rate. If the external source runs at 59.94 Hz instead of exactly 60 Hz, the TOD counter drifts ~3.6 seconds per hour
Audio sample rate: audio DMA runs from the same clock tree, so pitch shifts slightly when genlocked
Game timing: any VBL-locked game loop runs at the external field rate instead of the native rate

Scandoublers, Flicker Fixers & Modern Display

The 15 kHz Problem

All OCS/ECS/AGA native display modes produce 15.625 kHz (PAL) / 15.734 kHz (NTSC) horizontal scan rates — standard broadcast television frequencies. Modern displays (VGA monitors, HDMI TVs, computer monitors) require minimum 31 kHz horizontal scan. This makes the Amiga incompatible with virtually all modern displays without signal conversion.

A secondary problem is interlace flicker: Workbench in high-resolution (640×512 interlaced) flickers visibly on CRTs due to 25/30 Hz per-field phosphor decay.

Commodore's Own Solutions

Solution	Era	Method	Output
A2320 Deinterlacer	1991	Internal card for A2000 video slot; captures both fields, outputs progressive	31 kHz VGA
ECS Productivity Mode	1991	BEAMCON0 reprograms sync for 31 kHz native output (A3000)	31 kHz analog
AGA Scan-Doubled Modes	1992	DBLPAL/DBLNTSC modes double scanlines in hardware	31 kHz native

AGA's scan-doubled modes are a chipset-level solution: Lisa reads each scanline from the frame buffer and outputs it twice, converting 15 kHz interlaced to 31 kHz progressive within the chip itself. No external hardware needed — but only available on A1200/A4000.

Important

AGA scan-doubled modes are opt-in, not default. A stock A1200 boots in PAL or NTSC (15 kHz) — the same as OCS. To get 31 kHz output you must explicitly select a DblPAL or DblNTSC monitor driver in Prefs (IControl or ScreenMode) and set the Workbench to a scan-doubled mode. Kickstart 3.0 (39.106) introduced DblPAL/DblNTSC support; Kickstart 3.1 (40.68) refined it. Many games and demos bypass the OS entirely and drive the chipset at 15 kHz regardless, so an A1200 connected to a VGA-only monitor will show nothing during boot and during most game loads unless a scandoubler/scaler is installed.

Historical Third-Party Solutions

Device	Type	Connection	Amiga Models
MicroWay Flicker Fixer	Deinterlacer	A2000 video slot	A2000
GVP Spectrum	Scan doubler + 24-bit card	Zorro II + video slot	A2000/A3000
ICD Flicker Free Video	Scan doubler	A2000 video slot	A2000
3-State Megachip	Chip RAM expander + scan doubler	Internal	A500/A2000

Modern Display Solutions

Device	Technology	Installation	Target Models	Output
Indivision ECS	FPGA over Denise socket	Internal (Denise replacement)	A500/A600/A2000	HDMI/VGA
Indivision AGA MK3	FPGA over Lisa socket	Internal (Lisa replacement)	A1200/A4000/CD32	HDMI/VGA
RGB2HDMI	RPi Zero + CPLD	Internal (Denise tap)	A500/A600/A2000	HDMI
OSSC	External line multiplier	23-pin SCART/RGB	Any (external)	HDMI
OSSC Pro	Advanced FPGA scaler	SCART/VGA/component	Any (external)	HDMI 2.0
GBS-Control	Budget external scaler	23-pin SCART/RGB	Any (external)	HDMI/VGA
RetroTINK 5X Pro	External scaler + deinterlacer	SCART/component/S-Video	Any (external)	HDMI
RetroTINK-4K	Next-gen external scaler	SCART/component/S-Video	Any (external)	HDMI 2.1 (4K)
Retro Access cables	High-quality RGB SCART/BNC	23-pin → SCART/BNC	Any (cable only)	—

How They Work — Architecture Comparison

Internal tap solutions (Indivision, RGB2HDMI) connect directly to the Denise/Lisa chip's digital output pins — they see the same 12/24-bit digital pixel data as the video slot, but at the chip level. This provides:

Zero analog noise — no DAC conversion artifacts
Pixel-perfect capture — exact 1:1 digital samples
Mode detection — can identify PAL/NTSC, lores/hires, interlaced/progressive from sync signals
V-Sync alignment — FPGA solutions can lock output to input for tear-free scrolling

External solutions (OSSC, OSSC Pro, GBS-Control, RetroTINK 5X/4K) process the analog RGB output from the 23-pin connector. Quality depends on the analog cable and the scaler's ADC precision. The OSSC Pro and RetroTINK-4K represent the current state-of-the-art — both handle the Amiga's unusual 15 kHz PAL/NTSC signals with minimal latency and support advanced features like per-game profiles and adaptive scan rate detection.

Choosing an Adapter

Your Amiga	Best Internal	Best External	Notes
A500 / A2000 (OCS)	RGB2HDMI or Indivision ECS	OSSC	RGB2HDMI is cheapest, Indivision is highest quality
A600 (ECS)	RGB2HDMI	OSSC	Same as A500
A1200 (AGA)	Indivision AGA MK3	OSSC	Indivision supports all AGA modes including RTG
A3000 (ECS)	A2320 (original)	OSSC	Built-in productivity mode reduces need
A4000 (AGA)	Indivision AGA MK3	OSSC	Video slot also available for period-correct solutions
CD32 (AGA)	Indivision AGA MK3	OSSC	Internal Indivision is the cleanest option

Timing Relations — The Unified View

From Crystal to Every Subsystem

The following diagram shows how the single master crystal drives every timing domain in the system:

graph TD
    XTAL["🔷 Master Crystal<br/>28.375 / 28.636 MHz"]

    subgraph Video["Video Domain (synchronous)"]
        DOT["Dot Clock ÷2<br/>Hires pixels"]
        CCK["Color Clock ÷8<br/>DMA slots, Copper"]
        BEAM["Beam Counter<br/>VPOSR / VHPOSR"]
        SYNC["Sync Generator<br/>HSYNC, VSYNC"]
        DENISE["Denise / Lisa<br/>Pixel serialization + DAC"]
    end

    subgraph Chipset_Bus["Chipset Bus Domain (synchronous)"]
        CPUCLK["CPU Clock ÷4<br/>7.09 / 7.16 MHz"]
        AGNUS["Agnus / Alice<br/>DMA arbitration"]
        CHIPRAM["Chip RAM Bus<br/>Time-division access"]
    end

    subgraph Slow["Slow Peripheral Domain"]
        ECLK["E-Clock ÷40<br/>709 / 716 kHz"]
        CIA["CIA-A / CIA-B<br/>Timers, TOD, I/O"]
    end

    subgraph Async["Asynchronous Domain (accelerators)"]
        ACCEL["Accelerator Clock<br/>14–66 MHz (independent)"]
        FAST["Fast RAM<br/>Private bus"]
        CACHE["CPU Cache<br/>L1/L2"]
    end

    XTAL --> DOT --> DENISE
    XTAL --> CCK --> BEAM --> SYNC
    CCK --> AGNUS --> CHIPRAM
    XTAL --> CPUCLK --> CHIPRAM
    XTAL --> ECLK --> CIA

    ACCEL -. "bus adapter<br/>(synchronizes on<br/>Chip RAM access)" .-> CHIPRAM
    ACCEL --> FAST
    ACCEL --> CACHE

The Architectural Split — Synchronous vs. Asynchronous

The original A1000/A500/A2000 architecture is fully synchronous: the 68000 runs at the video-derived clock and shares every bus cycle with the custom chipset. There is exactly one clock domain — everything traces to the crystal.

This changed fundamentally with accelerator boards:

Generation	CPU Clock	Bus Relationship	Memory Architecture
A500/A2000 stock	7.09 MHz (= crystal ÷ 4)	Fully synchronous	Chip RAM only (shared bus)
A3000 stock	25 MHz (68030)	Asynchronous with bus adapter	Fast RAM on CPU local bus, Chip RAM via Gary
Accelerator (e.g., Blizzard 1230)	50 MHz (68030)	Asynchronous + cache	32-bit Fast RAM private bus, Chip RAM access throttled to 7 MHz
A4000/040 stock	25 MHz (68040)	Asynchronous, burst-capable	Fast RAM on local bus, Chip RAM via Ramsey + bus adapter
Accelerator (e.g., Cyberstorm 060)	50/66 MHz (68060)	Fully asynchronous	Private SIMM bus, Chip RAM access incurs ~10:1 penalty

What changed and what didn't:

✅ CPU and Fast RAM became asynchronous — running at independent, higher frequencies on a private bus with no DMA contention
❌ The chipset stayed synchronous — Agnus/Alice, Denise/Lisa, Copper, Blitter, sprite DMA, audio DMA, and disk DMA all remain locked to the video crystal at 3.55/7.09 MHz
🔄 Chip RAM access bridges two domains — when an accelerated CPU reads or writes Chip RAM, the bus adapter forces it to wait for a free DMA slot at the chipset's native clock rate. This is the "Chip RAM penalty" that makes Fast RAM 5–10× faster for CPU-intensive code

This dual-domain architecture is why Amiga programming advice consistently says: "put code and data in Fast RAM, put only DMA-visible buffers (screens, samples, copper lists) in Chip RAM." The chipset can't see Fast RAM at all, and the CPU pays a heavy synchronization penalty to access Chip RAM.

Per-Frame Time Budgets

Budget Item	PAL (50 Hz)	NTSC (60 Hz)	Notes
Total frame	20.0 ms	16.7 ms	100% of available time
VBL period	~4.5 ms	~4.1 ms	No display DMA — CPU gets full bandwidth
Active display	~15.5 ms	~12.6 ms	DMA contention reduces CPU throughput
CPU cycles (0 bitplanes)	~142,000	~119,000	Full bus — no display overhead
CPU cycles (4 planes lores)	~75,000	~63,000	~53% of bus available
CPU cycles (6 planes hires)	~24,000	~20,000	~17% of bus — severely constrained

Tip

Frame budget math: for a 50 Hz game with 4-plane lores, you have ~75,000 CPU cycles per frame. A 68000 move.l (a0)+,(a1)+ takes 20 cycles, so you can copy ~3,750 longwords (15 KB) per frame through the CPU. The Blitter — which uses DMA slots, not CPU cycles — can move far more data but also competes for bus bandwidth. See DMA Architecture for full bandwidth calculations.

Best Practices

Use VBL interrupts for frame synchronization — never busy-wait on VHPOSR for frame boundaries. The VBL interrupt fires reliably at the start of vertical blank and doesn't waste CPU cycles.
Read beam position atomically — always read VPOSR:VHPOSR as a single move.l $DFF004,Dn to avoid race conditions at line boundaries.
Never hardcode PAL/NTSC line counts — check GfxBase->DisplayFlags & PAL or read VPOSR to determine the video standard at runtime. Games that assume 200 lines break on PAL; games that assume 256 lines break on NTSC.
BEAMCON0: validate against monitor specs — when programming custom sync timing, ensure H-rate and V-rate are within the target monitor's advertised range. CRT monitors can be damaged by out-of-spec signals.
Account for genlock clock drift — if your software must run genlocked, test CIA timer accuracy. TOD and timer intervals shift with the external clock source.
Place DMA buffers in Chip RAM, everything else in Fast RAM — this is the single most impactful performance optimization on accelerated Amigas. The chipset cannot see Fast RAM, and the CPU pays a ~10:1 penalty accessing Chip RAM on a 50 MHz accelerator.
Profile with the color-change trick — move.w #color,$DFF180 before and after critical sections gives instant visual feedback on time consumption. Works on real hardware, WinUAE, and MiSTer.

Frequently Asked Questions

Q: Why does my game run faster on NTSC than PAL?

A: If the game loop is VBL-locked (one logic update per frame), NTSC runs at 60 Hz vs PAL's 50 Hz — 20% faster. The CPU clock is also slightly faster (7.16 vs 7.09 MHz), adding ~1%. Games designed for one standard often have timing bugs on the other.

Q: Can I switch PAL↔NTSC in software?

A: On OCS, no — the crystal is soldered to the motherboard. On ECS/AGA, BEAMCON0 bit 6 (PAL) selects the timing standard, but composite color encoding still depends on the physical crystal. Software PAL/NTSC switching produces correct sync timing but incorrect color subcarrier — composite output may be black-and-white or have wrong colors. RGB output is unaffected.

Q: Why is composite output black-and-white after a crystal mod?

A: If you install an NTSC crystal in a PAL machine (or vice versa), the color subcarrier frequency is wrong for the TV's decoder. The sync timing works (picture is stable) but chrominance decoding fails. RGB monitors don't care — they receive the color channels directly.

Q: My interlaced Workbench flickers horribly — is this a hardware defect?

A: No — interlace flicker is an inherent property of CRT displays. Each field illuminates half the lines, and phosphor decay between fields creates visible 25/30 Hz flicker on high-contrast edges. Use a flicker fixer (Indivision, A2320) or an LCD/FPGA display to eliminate it.

Q: How timing-accurate does a MiSTer/FPGA core need to be?

A: For basic display, ±10 ns per clock edge is sufficient. For genlock compatibility, sub-nanosecond phase accuracy to the color subcarrier is required. For cycle-accurate demo/game compatibility, every DMA slot must fire at the correct beam position — this is why accurate Amiga cores take years to develop.

References

Primary Sources

Amiga Hardware Reference Manual (HRM) — Appendix A: Signal Timing, Video Connector
A3000 Technical Reference Manual — Display Timing, BEAMCON0 Programming
AGA Hardware Reference — Lisa/Alice additions, scan-doubled modes
NDK 3.9 — hardware/custom.h (register definitions), graphics/gfxbase.h
Motorola MC68000 User Manual — E-clock specification, bus cycle timing

Community References

Amiga Dev Docs — Custom Chip Registers — comprehensive register map
Big Book of Amiga Hardware — genlock and video adapter database
EAB (English Amiga Board) — hardware modification and timing discussions
MiSTer FPGA Amiga Core — cycle-accurate timing implementation

41 KiB Raw Permalink Blame History Unescape Escape