2026-07-28 04:36:28 +00:00
5 changed files with 141 additions and 825 deletions
--- a/02_boot_sequence/README.md
+++ b/02_boot_sequence/README.md
@ -12,6 +12,6 @@ From power-on to Workbench desktop: hardware init, ROM validation, kernel creati
 | [kickstart_rom.md](kickstart_rom.md) | **Kickstart ROM internals: binary structure, module inventory, extraction tools, custom ROM building, EPROM burning** |
 | [kickstart_init.md](kickstart_init.md) | ExecBase creation, capture vectors, resident module scan algorithm, 4-phase initialization, bootstrap handoff |
 | [dos_boot.md](dos_boot.md) | strap module, boot block format and execution, MountList/DOSDrivers, system assigns, Startup-Sequence walkthrough. See also: [CD-ROM Filesystems](../07_dos/cdfs.md) |
-| [disk_boot.md](disk_boot.md) | **Disk boot deep dive: floppy MFM physics, HDD/IDE/SCSI boot (PIO vs DMA), RDB partitioning, controller & driver ecosystem (Gayle, GVP, A4091, TF1260), CompactFlash, disk image preparation (amitools, WinUAE, HDToolBox), failure modes** |
+| [floppy_vs_hdd_physical_boot.md](floppy_vs_hdd_physical_boot.md) | Physical hardware mechanisms: floppy MFM streaming, HDD RDB scanning, DMA transfers, and physical failure modes |
 | [early_startup.md](early_startup.md) | Early Startup Control menu: boot device selection, display mode override, recovery scenarios |
 | [kickstart-boot-diagnostics.md](kickstart-boot-diagnostics.md) | **Kickstart POST: color-screen self-test architecture, 7-phase ColdStart sequence, coldCrash handler, diagnostic cartridge intercept, troubleshooting cross-reference** |
--- a/02_boot_sequence/disk_boot.md
+++ b/02_boot_sequence/disk_boot.md
@ -1,666 +0,0 @@
 [← Home](../README.md) · [Boot Sequence](README.md)
 # Disk Boot — Floppy, Hard Drive, and Storage Media
 ## Overview
 The Amiga's disk boot process is orchestrated by the Kickstart ROM, transitioning the system from hardware initialization into a running operating system. After the CPU resets and `exec.library` initializes the system, resident device drivers (like `trackdisk.device` for floppies and `scsi.device` for internal IDE/SCSI) are brought online. The `expansion.library` then performs the AutoConfig scan, executing boot ROMs on expansion cards which parse Rigid Disk Blocks (RDB) and mount hard drive partitions into the system.
 Finally, the `strap` module orchestrates the boot process by enumerating all discovered boot nodes, sorting them by priority, and attempting to read a 1024-byte bootblock from the highest-priority device. The physical journey to fetch this bootblock differs significantly depending on the media. Floppy disks rely on CPU-driven MFM decoding and direct hardware control of the CIA and Paula chips. Hard drives use a smart controller (SCSI or IDE) that abstracts the media behind a block-device interface. Despite these differences, both the floppy and hard drive paths converge at the same bootblock execution and subsequent `dos.library` handoff.
 Understanding these two paths — and the ecosystem of controllers, drivers, and modern storage media that surrounds them — is essential for anyone working with real hardware, FPGA cores, emulators, or disk image tooling. This article covers the physical details of floppy and hard drive boot, RDB partitioning, the controller/driver landscape, CompactFlash as a modern replacement, and practical workflows for preparing disk images.
 **Prerequisites:** [Cold Boot](cold_boot.md) (what happens before media is touched), [Kickstart Init](kickstart_init.md) (how resident modules and device drivers are initialized).
 **What happens next:** [DOS Boot](dos_boot.md) (how the bootblock hands off to `dos.library` and the Startup-Sequence).
 ---
 ## The Generic Boot Flow
 Regardless of whether the boot medium is a DD floppy, a 4 GB SCSI hard drive, or a CompactFlash card plugged into a Gayle IDE port, every Amiga boot passes through the same high-level phases. The differences are in *how* each phase discovers and reads the medium — not in *what* it does with the data once loaded.
 ```mermaid
 graph TD
    A["Power On / Reset"] --> B["Kickstart ROM Init"]
    B --> C["exec: Initialize resident modules<br/>(trackdisk.device, scsi.device, etc.)"]
    C --> D["expansion.library: AutoConfig scan<br/>(discover Zorro cards, boot ROMs)"]
    D --> E["strap module: Enumerate bootable devices"]
    E --> F{"Boot medium found?"}
    F -->|"Yes"| G["Read 1024-byte bootblock<br/>from selected device"]
    F -->|"No"| H["Display 'Insert Workbench' hand"]
    G --> I["Validate bootblock checksum"]
    I -->|"Valid"| J["Execute bootblock code at $000C"]
    I -->|"Invalid"| H
    J --> K["dos.library mounts volume"]
    K --> L["Execute S:Startup-Sequence"]
 ```
 The critical insight is that the bootblock is always **1024 bytes** (two 512-byte sectors), always loaded into a **dynamically allocated memory buffer** (typically Chip RAM as requested by the boot node), and always **checksummed identically** — whether it came off a floppy track via MFM DMA or off an IDE drive via a CPU PIO loop. The boot code in the bootblock itself doesn't know or care what physical medium it was read from. This abstraction is what makes the Amiga's boot architecture elegant: the complexity is in the *path to the bootblock*, not in the bootblock itself.
 ### What Does the Bootblock Code Actually Do?
 A common misconception is that the 1024-byte bootblock contains the filesystem driver (e.g., FFS or PFS3) or complex logic to read the disk. It does not. 
 For standard AmigaOS bootable disks, the bootblock code is **completely identical** regardless of whether the disk is formatted as OFS, FFS, Directory Caching (DC-FFS), or International FFS. The standard bootblock (written by the Workbench `Install` command) contains less than 100 bytes of 68000 assembly code. Its sole purpose is to bridge the gap between the low-level `strap` module and the higher-level operating system.
 When `strap` executes the bootblock at offset `$000C`, the code performs a very specific, minimal handoff:
 1. It uses `exec.library` to locate `dos.library` in the ROM.
 2. On OS 2.0+, it opens `dos.library`, sets a specific initialization flag in the library's base structure, and closes it.
 3. It locates `expansion.library` (or `dos.library` on OS 1.3) and extracts the pointer to its `rt_Init` (ROM initialization) vector.
 4. It returns this pointer to `strap` (in CPU register `A0`), along with a success code (`D0 = 0`).
 5. `strap` then executes a direct `JMP` to that ROM routine, handing off control to the OS to mount the boot volume and execute `S:Startup-Sequence`.
 Because this standard boot code only manipulates ROM pointers and does no actual disk I/O, it is **filesystem-agnostic** and **medium-agnostic**. The actual filesystem driver used to read `S:Startup-Sequence` is either resident in the Kickstart ROM (for FFS/OFS) or was previously loaded into RAM from the Rigid Disk Block during the AutoConfig scan (for third-party filesystems like PFS3).
 *(Note: Custom bootblocks, such as those used by trackloading games or the demoscene, replace this standard code entirely to bypass `dos.library` and take direct control of the hardware. See [Custom Loaders and DRM](../05_reversing/custom_loaders_and_drm.md) for details.)*
 For the detailed bootblock format, checksum algorithm, and `dos.library` handoff sequence, see [DOS Boot](dos_boot.md).
 ---
 ## Booting from Floppy (DF0:)
 ### The Hardware Chain
 Floppy boot is the most hardware-intimate boot path on the Amiga. There is no smart controller, no command protocol, and no abstraction layer between the CPU and the spinning magnetic disk. The system uses three chips in concert:
 | Component | Role |
 |---|---|
 | **CIA-B** ($BFD000) | Motor control, drive select, head stepping, side select, /DSKCHANGE detection |
 | **Paula** ($DFF000) | Disk DMA engine — streams raw MFM bitstream to/from Chip RAM |
 | **CPU** | Decodes MFM data, validates checksums, executes bootblock |
 The Kickstart ROM's `trackdisk.device` orchestrates this hardware. It is a true device driver in the exec sense — it responds to `CMD_READ`, `TD_MOTOR`, `TD_CHANGESTATE` — but internally it is doing bare-metal register manipulation, not issuing commands to a smart controller.
 ### Step-by-Step Physical Process
 ```mermaid
 sequenceDiagram
    participant KS as Kickstart (trackdisk.device)
    participant CIA as CIA-B ($BFD100)
    participant Paula as Paula ($DFF020–$DFF026)
    participant RAM as Chip RAM
    KS->>CIA: Select DF0: (drive select bits)
    KS->>CIA: MTR ON (start motor)
    Note over CIA: Motor spin-up (~500 ms)
    KS->>CIA: Step head to Track 0
    KS->>CIA: Select Side 0 (lower head)
    KS->>Paula: Set DSKPT → Chip RAM buffer
    KS->>Paula: Set DSKLEN → track length + DMA enable
    Note over Paula: Paula waits for $4489 MFM sync word
    Paula->>RAM: DMA streams raw MFM bitstream (one full track)
    Paula-->>KS: DSKBLK interrupt (transfer complete)
    KS->>KS: Decode MFM → extract sectors 0–1 (bootblock)
    KS->>KS: Validate bootblock checksum
    KS->>KS: JMP to bootblock code ($00000C)
 ```
 ### MFM Encoding — What the Hardware Actually Sees
 The magnetic surface of an Amiga floppy does not store bytes. It stores a continuous stream of **flux transitions** — magnetic polarity changes that Paula's disk DMA reads as a raw bitstream. The data is encoded using **Modified Frequency Modulation (MFM)**, which interleaves clock bits between data bits to ensure the bitstream never has too many consecutive zeros (which would cause the read head to lose synchronization).
 Each Amiga sector on disk is preceded by a **sync word**: `$4489`. Paula's hardware is specifically designed to watch for this pattern in the raw MFM stream. When it detects `$4489`, it knows the next bits are the start of a sector header. This is a hardware-level pattern match — Paula has a dedicated sync register at `$DFF07E` (DSKSYNC) that holds the word to watch for.
 The encoding works as follows:
 | Data Bit | MFM Encoding Rule |
 |---|---|
 | 1 | Always preceded by clock bit 0: → `01` |
 | 0 (after a 1) | No clock needed: → `00` |
 | 0 (after a 0) | Clock bit inserted: → `10` |
 This means every data byte expands to 16 MFM bits (2 bytes on disk). A DD floppy track stores 11 sectors × 512 bytes = 5632 data bytes, which become ~12,668 bytes of MFM-encoded data (including sector headers, gaps, and checksums) — fitting within the ~12,800 raw bytes per track that the drive physically supports at 300 RPM.
 > [!NOTE]
 > `trackdisk.device` reads an entire track into a Chip RAM buffer as raw MFM, then decodes it in software to extract individual sectors. It does not read individual sectors — the granularity of the DMA transfer is always one full track. This is why AmigaDOS floppy access is track-oriented, and why reading a single byte from a floppy still reads 5.5 KB of data into the track buffer.
 ### Custom Trackloaders and the Floppy's Unique Property
 The floppy boot path has a property that no other Amiga boot medium shares: **the bootblock code can bypass DOS entirely**. Because `trackdisk.device` provides raw sector access and the bootblock executes with full supervisor privileges, game developers routinely replaced the standard bootblock with custom trackloaders that read non-standard disk formats (extra sectors per track, long tracks, modified MFM encoding) directly via Paula's DMA registers. This is the foundation of Amiga game copy protection and the demoscene's disk-based intros.
 For an in-depth treatment of custom trackloaders, non-standard disk formats, and physical DRM tricks, see [Custom Loaders and DRM](../05_reversing/custom_loaders_and_drm.md).
 ---
 ## Booting from Hard Drive
 ### The Smart Device Paradigm
 Hard drive boot is architecturally the opposite of floppy boot. Instead of the CPU directly controlling motors and reading raw bitstreams, a **smart controller** handles all physical media interaction. The CPU communicates with the controller through a command/response protocol — either ATA task file registers (for IDE) or SCSI command descriptor blocks (for SCSI). The controller translates these high-level commands into the low-level operations needed to read sectors from the physical media.
 This abstraction means the CPU never sees MFM encoding, head positioning, or rotational timing. It sends a command ("read sector at LBA N"), waits for the controller to signal completion, and then retrieves the data. The data path from controller to RAM is where the critical architectural distinction lies — and where the existing documentation in this repository had an error that needs correcting.
 ### PIO vs DMA — The Critical Distinction
 > [!WARNING]
 > **Stock Commodore IDE controllers have no DMA.** The Gayle chip (A600, A1200) and the A4000 motherboard IDE interface are strictly PIO (Programmed I/O). The CPU executes a `MOVE.W` loop to transfer every word of data between the IDE data register and system RAM. This consumes 100% of the CPU during disk I/O. Only SCSI controllers (A3000, A4000T, Zorro cards) and the third-party FastATA Zorro IDE card have DMA capability. This distinction is fundamental to understanding Amiga storage performance.
 | Transfer Method | How It Works | CPU Load | Controllers |
 |---|---|---|---|
 | **PIO (Programmed I/O)** | CPU reads/writes every word via `MOVE.W` loop between device register and RAM | **100%** during transfer | Gayle IDE (A600/A1200), A4000 IDE, Buddha, Catweasel, TF1260 |
 | **DMA (Direct Memory Access)** | Controller's DMA engine transfers data to/from RAM autonomously; CPU is free | **~0%** during transfer | A3000 SCSI (SDMAC), A4000T SCSI, A2091, GVP Series II, A4091, FastATA |
 ### IDE Boot — Step by Step (PIO Path)
 This is the boot path for the most common Amiga hard drive setup: an A1200 or A600 with a 2.5" hard drive or CompactFlash card connected to the Gayle IDE port.
 ```mermaid
 sequenceDiagram
    participant KS as Kickstart (scsi.device)
    participant Gayle as Gayle IDE Registers ($DA0000)
    participant Drive as IDE Drive / CF Card
    participant RAM as System RAM (Chip or Fast)
    KS->>Gayle: Write ATA command: IDENTIFY DEVICE ($EC)
    Gayle->>Drive: Forward command to drive
    Drive-->>Gayle: Drive sets DRQ (data ready)
    Note over KS,RAM: CPU MOVE.W loop — 256 words
    KS->>Gayle: Read data register ($DA0000), word by word
    KS->>RAM: Store each word to RAM buffer
    Note over KS: Parse drive identity, confirm media present
    KS->>Gayle: Write ATA command: READ SECTORS ($20), LBA 0
    Gayle->>Drive: Forward command
    Drive-->>Gayle: DRQ set (sector ready)
    KS->>Gayle: CPU MOVE.W loop — read 256 words (512 bytes)
    KS->>RAM: Store to RAM — this is the first RDB sector
    KS->>KS: Check for "RDSK" signature ($5244534B)
    Note over KS: Parse RDB → find PartitionList → select boot partition
    KS->>Gayle: READ SECTORS for bootblock (2 sectors)
    KS->>RAM: CPU PIO transfer — 1024 bytes
    KS->>KS: Validate bootblock checksum
    KS->>KS: Execute bootblock → dos.library
 ```
 Note the key difference from floppy boot: there is no MFM decoding, no motor control, and no DMA from the disk subsystem. But there is also no DMA *to* RAM — every word passes through a CPU register. On a stock 68020 at 14 MHz (A1200), this yields approximately 1.5 MB/s sustained throughput, regardless of how fast the drive itself is.
 ### SCSI Boot — Step by Step (DMA Path)
 This is the boot path for an A3000 with its onboard WD33C93/SDMAC SCSI controller, or a big-box Amiga with a Zorro SCSI card.
 ```mermaid
 sequenceDiagram
    participant KS as Kickstart (scsi.device)
    participant SCSI as WD33C93 / NCR 53C710
    participant DMA as SDMAC / Card DMA Engine
    participant Drive as SCSI Hard Drive
    participant RAM as Fast RAM
    KS->>SCSI: Issue SCSI READ(10) CDB — LBA 0, count 1
    SCSI->>Drive: SCSI bus arbitration → selection → command
    Drive-->>SCSI: Data-In phase — sector data on SCSI bus
    SCSI->>DMA: Signal data ready
    DMA->>RAM: Bus-mastering DMA transfer (512 bytes)
    DMA-->>KS: Interrupt: transfer complete
    Note over KS: CPU was free during the entire transfer
    KS->>KS: Check for "RDSK" signature
    Note over KS: Parse RDB → find boot partition
    KS->>SCSI: READ(10) for bootblock (2 sectors)
    SCSI->>Drive: SCSI bus transfer
    DMA->>RAM: DMA — 1024 bytes to Fast RAM
    DMA-->>KS: Interrupt
    KS->>KS: Validate bootblock, execute → dos.library
 ```
 The key advantage: the CPU is idle during data transfer. On a system with a 68040 or 68060 doing background computation (rendering, decompression), SCSI DMA means disk I/O doesn't stall the CPU. This is why the A3000's SCSI architecture was considered superior to the later A4000's cost-reduced IDE — despite IDE drives being cheaper and more readily available.
 ### AutoConfig and Boot ROMs — How Controllers Appear
 Before any hard drive can boot, its controller must be discovered and its device driver must be loaded. For onboard controllers (Gayle IDE, A3000 SCSI), the drivers are resident modules in the Kickstart ROM — they initialize automatically during the RomTag scan. For Zorro expansion cards, the process is more involved:
 1. **AutoConfig scan** — `expansion.library` walks the Zorro bus, reading each card's configuration registers to determine manufacturer ID, product ID, and memory requirements. See [AutoConfig](../01_hardware/common/autoconfig.md).
 2. **DiagArea check** — If a card's AutoConfig ROM contains a **DiagArea** structure, the Kickstart copies it into RAM and calls its `da_DiagPoint` routine. This is where SCSI controllers install their device driver (`scsi.device`, `gvpscsi.device`, etc.) into the exec device list — *before* any boot device is selected.
 3. **Boot ROM execution** — If the DiagArea also contains a boot vector (`da_BootPoint`), the card can participate in the boot device selection process. The boot ROM typically scans the attached SCSI bus for drives, reads their RDB, and registers bootable partitions with the strap module.
 This DiagArea mechanism is what allows a GVP SCSI card to boot an Amiga 2000 from a SCSI drive without any software on a floppy — the card's ROM contains both the device driver and the boot code.
 > [!NOTE]
 > The TF1260 accelerator's IDE port is a notable exception to this pattern. It has **no boot ROM** — the `ehide.device` driver is not in the card's ROM or the Kickstart ROM. You must boot from another device (typically the A1200's internal Gayle IDE port) and load the driver with `LoadModule DEVS:ehide.device` during the Startup-Sequence. This means TF1260 IDE storage is never the primary boot device.
 ---
 ## RDB Partitioning — From the Boot Perspective
 The **Rigid Disk Block (RDB)** is the Amiga's partitioning standard — a self-describing, linked-list structure that is far more flexible than the PC's contemporary MBR scheme. Understanding how the Kickstart interprets the RDB at boot time is essential for setting up bootable hard drives.
 For the complete RDB on-disk structure (field offsets, checksums, PartitionBlock layout, FileSysHdr format), see [Filesystem — RDB section](../07_dos/filesystem.md).
 ### The RDB Scan — Blocks 0 Through 15
 When a hard drive device driver reports a drive to the Kickstart, the boot code doesn't just read block 0. It scans **blocks 0 through 15** (`RDB_LOCATION_LIMIT`), looking for the 4-byte signature `RDSK` (`$5244534B`) at offset `$00` of each block. This range exists for three reasons:
 1. **Coexistence with other schemes** — If the RDB were locked to block 0, it would conflict with PC MBR partitioning. Allowing it at blocks 1–15 enables dual-format disks.
 2. **Bad block resilience** — If block 0 develops a physical defect, the RDB at block 1 (or 2, etc.) remains accessible. The partition map survives a single-block failure.
 3. **Layout flexibility** — Some controllers reserve block 0 for their own use. The 16-block scan accommodates this.
 In practice, most tools (HDToolBox, `rdbtool`) write the RDB to block 0 (or block 2 for legacy SCSI compatibility). The scan is a safety net, not a routine necessity.
 ### Boot Priority — How Kickstart Picks a Partition
 Once the RDB is found, the Kickstart walks the PartitionBlock linked list (starting from `rdb_PartitionList`) and collects every partition that has:
 - The **`PBF_BOOTABLE`** flag set (bit 0 of `de_Flags`)
 - The **`PBF_AUTOMOUNT`** flag set (bit 1 of `de_Flags`)
 These partitions are sorted by their **`de_BootPri`** field (a signed 8-bit value, range −128 to +127). The partition with the highest BootPri wins. Ties are broken by list order (first in the RDB's linked list wins).
 | BootPri | Typical Use |
 |---|---|
 | 5 | Default for DH0: (Workbench partition) |
 | 0 | Default for secondary partitions (DH1:, DH2:) |
 | −128 | Never auto-boot (data-only partition) |
 | ≥ 15 | Overrides floppy boot (floppy BootPri is typically 5 on KS 2.0+) |
 > [!IMPORTANT]
 > Floppy drives (DF0:) have a **built-in boot priority** that varies by Kickstart version. On KS 1.3, the floppy always boots first if a disk is inserted. On KS 2.0+, the floppy's effective BootPri is around 5, so a hard drive partition with BootPri ≥ 6 boots first even with a floppy inserted. Setting a partition's BootPri to 15 or higher guarantees it boots before any floppy — useful for CF card setups where you never want floppy boot.
 ### Filesystem Loading from RDB
 The RDB can store **complete filesystem driver binaries** inline — this is how third-party filesystems like PFS3 and SFS work without modifying the Kickstart ROM. The mechanism:
 1. The RDB's `rdb_FileSysHdrList` field points to a chain of **FileSysHdr** blocks, each containing a DosType identifier and the binary code for a filesystem handler.
 2. Each PartitionBlock's `de_DosType` field specifies which filesystem to use (e.g., `DOS\1` for FFS, `PFS\3` for PFS3).
 3. At boot time, the Kickstart matches each partition's DosType to a FileSysHdr in the RDB. If a match is found, it loads the filesystem binary from the RDB into RAM and uses it to mount the partition.
 4. If no match is found in the RDB, the Kickstart falls back to the ROM-resident filesystem (FFS from the Kickstart ROM).
 This design means you can install PFS3 on a brand-new hard drive using HDToolBox, and the drive will boot with PFS3 even though the Kickstart ROM knows nothing about PFS3 — the filesystem binary is stored on the drive itself, in the RDB reserved area before the first partition.
 ### HDToolBox — The Standard Partitioning Tool
 HDToolBox is the Workbench utility for creating and editing RDB partition tables. It ships on the Workbench Install floppy (OS 2.0+) and in the `Tools` drawer of a Workbench installation. Key operations:
 - **Read Configuration** — detect drive geometry (cylinders, heads, sectors)
 - **Partition Drive** — create, resize, and delete partitions
 - **Change Filesystem** — add filesystem binaries (PFS3, SFS) to the RDB
 - **Set Boot Priority** — configure which partition boots first
 - **Save Changes to Drive** — write the RDB and partition blocks to disk
 > [!NOTE]
 > HDToolBox requires the correct device driver name in its `SCSI_DEVICE_NAME` ToolType (accessible via the Workbench Icon > Information menu). For Gayle IDE, this is `scsi.device`. For GVP cards, it's `gvpscsi.device`. For WinUAE emulated drives, it's `uaehf.device`. Getting this wrong is the most common reason HDToolBox shows "no drives found."
 ---
 ## Controllers and Drivers — The Ecosystem
 The Amiga storage ecosystem spans Commodore's own controllers, dozens of Zorro expansion cards, and accelerator-integrated interfaces. Each has its own device driver, performance characteristics, and boot behavior.
 ### Commodore Native Controllers
 | Controller | Models | Device Driver | Transfer | DMA? | Boot? | Peak Throughput |
 |---|---|---|---|---|---|---|
 | **Gayle IDE** | A600, A1200 | `scsi.device` (v43+) | PIO mode 0 | ❌ No | ✅ Yes (ROM driver) | ~1.5 MB/s (68020@14 MHz) |
 | **A4000 IDE** | A4000, A4000T | `scsi.device` | PIO | ❌ No | ✅ Yes (ROM driver) | ~2.5 MB/s (68030@25 MHz) |
 | **A3000 SCSI** | A3000, A3000T | `scsi.device` (v39) | SCSI-1 | ✅ SDMAC | ✅ Yes (ROM driver) | ~3.5 MB/s |
 | **A4000T SCSI** | A4000T | `scsi.device` | SCSI-2 | ✅ NCR 53C710 | ✅ Yes (ROM driver) | ~5 MB/s |
 The confusing naming — both the IDE and SCSI interfaces use drivers called `scsi.device` — is a historical accident. Commodore named the A600/A1200 IDE driver `scsi.device` for compatibility with existing RDB tools that hardcoded the name. Despite the name, the Gayle `scsi.device` speaks ATA, not SCSI. See [SCSI](../10_devices/scsi.md) for the full driver interface specification.
 For Gayle IDE hardware details — register layout, byte-lane mapping, interrupt routing via CIA-A — see [Gayle IDE & PCMCIA](../01_hardware/common/gayle_ide_pcmcia.md).
 ### Zorro Expansion SCSI Cards
 | Card | Chip | Device Driver | Bus | DMA? | Peak Throughput | Notes |
 |---|---|---|---|---|---|---|
 | **A2091** | WD33C93 | `scsi.device` | Zorro II | ✅ Yes | ~2.5 MB/s | Commodore. 14 MHz clock hack popular |
 | **A2090** | WD33C93 | `scsi.device` | Zorro II | ✅ Yes | ~1.5 MB/s | Earlier design, less reliable |
 | **GVP Series II** | WD33C93A | `gvpscsi.device` | Zorro II | ✅ DPRC | ~3.5 MB/s | Proprietary driver — incompatible with Commodore `scsi.device` |
 | **GVP HC+8** | WD33C93A | `gvpscsi.device` | Zorro II | ✅ DPRC | ~3.5 MB/s | 8 MB RAM onboard. No termpower — issue with modern SCSI emulators |
 | **A4091** | NCR 53C710 | `2nd.scsi.device` | Zorro III | ✅ Yes | ~8–10 MB/s | Fastest stock Commodore SCSI. ReA4091 open-source revival |
 | **Blizzard SCSI Kit** | NCR 53C80 | `BlizkitSCSI.device` | Accelerator bus | ✅ Yes | ~3 MB/s | Plugs into Blizzard 1230/1260 |
 | **Cyberstorm SCSI** | NCR 53C710/720 | `cybscsi.device` | Accelerator bus | ✅ Yes | ~10 MB/s | Phase5 accelerator boards |
 > [!NOTE]
 > GVP cards use a proprietary DPRC (Dual-Port RAM Controller) chip and require GVP-specific partitioning software (FaaastPrep or ExpertPrep). They are **not compatible** with Commodore's HDToolBox or `scsi.device`. If you're working with a GVP card, you must use `gvpscsi.device` in all tooltype and script references.
 ### Third-Party IDE Controllers (Zorro)
 | Card | Device Driver | Bus | DMA? | Peak Throughput | Notes |
 |---|---|---|---|---|---|
 | **Buddha** | `buddha.device` | Zorro II | ❌ PIO | ~2 MB/s | 2 IDE ports. Popular for big-box Amigas |
 | **FastATA** | `fastatahd.device` | Zorro II | ✅ DMA | ~6–8 MB/s | **Only Amiga IDE card with DMA** — UDMA/33 support |
 | **Catweasel** | `catweasel.device` | Zorro II | ❌ PIO | ~2 MB/s | Also includes floppy controller for HD/ED disks |
 ### Accelerator-Integrated Storage
 | Accelerator | Interface | Device Driver | Boot? | Notes |
 |---|---|---|---|---|
 | **TF1260** (TerribleFire) | IDE | `ehide.device` | ❌ **No autoboot** | Driver not in ROM. Must boot from Gayle IDE first, then `LoadModule DEVS:ehide.device` |
 | **Blizzard 1230/1260** | SCSI (optional kit) | `BlizkitSCSI.device` | ✅ DiagArea boot ROM | NCR 53C80 based |
 | **Cyberstorm MK II/III** | SCSI (onboard) | `cybscsi.device` | ✅ DiagArea boot ROM | NCR 53C710/720. High performance |
 | **ACA-1233n** | — | — | — | No onboard storage interface |
 | **Warp 1260** | — | — | — | No onboard storage interface |
 #### TF1260 IDE — The LoadModule Workaround
 The TerribleFire TF1260 accelerator for the A1200 includes an onboard IDE port, but it **cannot autoboot** because the `ehide.device` driver is not stored in the card's flash ROM. The setup workflow:
 1. Install your primary boot volume on the A1200's **internal Gayle IDE** port (typically a CF card via adapter)
 2. Copy `ehide.device` to `DEVS:` on the boot volume
 3. Add to `S:Startup-Sequence` (before `SetPatch`):
   ```
   C:LoadModule >NIL: DEVS:ehide.device
   ```
 4. Connect a second drive to the TF1260 IDE port — it will appear as an additional device after boot
 > [!WARNING]
 > The TF1260 IDE interface can be temperamental. It is recommended to remove capacitors E123C and E125C from the A1200 motherboard for stability, and to use high-quality 3.3V CompactFlash cards. Some users create custom Kickstart ROMs that include `ehide.device` to enable autobooting from the TF1260 port.
 ---
 ## CompactFlash — The Modern Boot Medium
 CompactFlash cards have become the standard storage medium for classic Amigas, replacing mechanical hard drives in virtually all modern setups. The reason is simple: CF cards implement **True IDE mode** — they present themselves as standard ATA devices, speak the same command protocol as a hard drive, and plug into the same 44-pin or 40-pin IDE connector via a passive adapter (no active electronics needed).
 ### Why CF Works
 | Property | Mechanical HDD | CompactFlash |
 |---|---|---|
 | Interface protocol | ATA (IDE) | ATA (True IDE mode) — identical |
 | Seek time | 8–20 ms | ~0.1 ms (no moving parts) |
 | Power consumption | 2–5 W | 0.1–0.5 W |
 | Noise | Audible | Silent |
 | Shock resistance | Fragile | Solid-state |
 | Availability (2020s) | Extinct (2.5" PATA) | Widely available |
 ### Practical Setup
 For an A1200 with Gayle IDE:
 1. **Adapter** — A 44-pin 2.5" IDE to CF adapter. Passive adapters work; no active electronics needed. Ensure the adapter supports the correct voltage (3.3V for most modern CF cards).
 2. **Card selection** — Not all CF cards work reliably. Industrial-grade cards with genuine True IDE mode are preferred. Some consumer cards implement only a subset of ATA commands, causing compatibility issues.
 3. **MaxTransfer setting** — This is the most common CF pitfall.
 > [!WARNING]
 > **The MaxTransfer gotcha**: The Gayle IDE interface can corrupt data if a single transfer exceeds a certain size. You **must** set `MaxTransfer` to `$0001FE00` (130,560 bytes) in the RDB PartitionBlock for every partition. In HDToolBox, this is under the partition's "Advanced Options." Failure to set this correctly causes **silent data corruption** — files appear to write successfully but contain garbage. This applies to all Gayle-connected devices (hard drives and CF cards alike). See [ATAPI](../10_devices/atapi.md) for a detailed explanation.
 ### SD Cards and MicroSD
 SD and MicroSD cards can be used with IDE-to-SD adapters, but these adapters contain active bridge electronics (SD uses a different protocol from ATA). Compatibility is less reliable than with CF cards, and some adapters introduce latency or compatibility issues. CF remains the recommended solid-state option for classic Amiga IDE.
 ---
 ## Preparing Disk Images and Media
 Whether you're setting up a CF card for real hardware, building an HDF for an emulator, or creating an ADF floppy image, there are three distinct workflows available — each suited to different situations.
 ### amitools — Modern Cross-Platform Workflow
 The `amitools` Python package provides `rdbtool` and `xdftool` for creating and manipulating Amiga disk images entirely from a modern computer (macOS, Linux, Windows). This is the fastest workflow for headless/scripted setups.
 **Installation:**
 ```bash
 pip install amitools
 ```
 **Complete recipe — Create a bootable HDF from scratch:**
 ```bash
 # 1. Create a 500 MB HDF file and initialize the RDB
 rdbtool work.hdf create size=500Mi + init
 # 2. Add two partitions: DH0 (100 MB, bootable) and DH1 (rest)
 rdbtool work.hdf add size=100Mi name=DH0 bootable=True boot_pri=5 \
  + add name=DH1
 # 3. (Optional) Add PFS3 filesystem to the RDB
 rdbtool work.hdf fsadd pfs3aio dos_type=PFS3 version=19.2
 # 4. Format partitions with FFS (DOS\3 = FFS + International mode)
 xdftool work.hdf open part=DH0 + format "Workbench" ffs intl
 xdftool work.hdf open part=DH1 + format "Work" ffs intl
 # 5. Pack a Workbench installation into DH0
 xdftool work.hdf open part=DH0 + pack ./wb31_files/
 # Verify the RDB:
 rdbtool work.hdf info
 rdbtool work.hdf list
 # Verify the filesystem:
 xdftool work.hdf open part=DH0 + list
 ```
 **ADF floppy images:**
 ```bash
 # Create a blank DD floppy image
 xdftool blank.adf create
 # Format it
 xdftool blank.adf format "MyDisk" ofs
 # Pack files
 xdftool blank.adf pack ./my_files/
 # List contents
 xdftool blank.adf list
 ```
 > [!NOTE]
 > `rdbtool` creates the RDB and partition table; `xdftool` handles the filesystem layer (formatting, file operations). For PFS3 partitions, `rdbtool` can add the filesystem binary to the RDB (`fsadd`), but the partition must be quick-formatted from within a booted Amiga or WinUAE — `xdftool` cannot write PFS3 filesystem structures, only FFS/OFS.
 ### WinUAE — GUI-Based Workflow
 WinUAE provides the most complete disk preparation workflow because it runs a real AmigaOS instance, giving you access to HDToolBox and all native formatting tools. This is the recommended approach when you need PFS3, complex partition layouts, or when preparing a CF card for real hardware.
 **Creating an HDF image:**
 1. In WinUAE, go to **Settings → Hard Drives → Add Hardfile**
 2. Set the size (e.g., 500 MB), choose a filename, click **Create**
 3. Set controller to **UAE** or **IDE (Auto)**
 4. Boot from a Workbench Install ADF
 5. Open HDToolBox (see below for ToolType setup)
 6. Partition, format, and install Workbench
 **Partitioning with HDToolBox in WinUAE:**
 1. Select HDToolBox in the `Tools` drawer — **do not double-click yet**
 2. Open **Icon → Information** and change the `SCSI_DEVICE_NAME` ToolType:
   - For UAE hardfiles: `uaehf.device`
   - For real CF cards accessed via WinUAE: `uaehf.device`
 3. Double-click HDToolBox — it should detect your drive
 4. **Change Drive Type → Define New → Read Configuration** (auto-detect geometry)
 5. **Partition Drive** — create your partitions, set BootPri, select filesystem
 6. **Save Changes to Drive** — writes the RDB
 7. Reboot the emulation for partitions to appear
 **Writing to a real CF card from WinUAE:**
 1. Insert CF card into a USB card reader
 2. On Windows, open an **Administrator Command Prompt**:
   ```
   diskpart
   list disk          (identify your CF card by size)
   select disk N      (replace N with CF card number)
   clean              (removes all Windows partitions)
   exit
   ```
 3. Launch WinUAE **as Administrator** (right-click → Run as Administrator)
 4. Go to **Hard Drives → Add Hard Drive** and select the physical CF card
 5. Set controller to **IDE0** and ensure **Read/Write** is checked
 6. Boot and use HDToolBox with `SCSI_DEVICE_NAME=uaehf.device`
 > [!WARNING]
 > When using `diskpart clean`, double-check the disk number. Selecting the wrong disk will erase your Windows drive. Always verify by disk size.
 **Transferring an HDF to a CF card:**
 On **Windows**, use `Win32DiskImager` to write the `.hdf` file directly to the CF card. On **macOS/Linux**:
 ```bash
 # Identify the CF card device (e.g., /dev/disk4 on macOS, /dev/sdc on Linux)
 # WARNING: Triple-check the device — writing to the wrong device destroys data
 # macOS:
 diskutil list                    # identify CF card
 diskutil unmountDisk /dev/diskN  # unmount
 sudo dd if=work.hdf of=/dev/rdiskN bs=1m
 # Linux:
 lsblk                           # identify CF card
 sudo dd if=work.hdf of=/dev/sdX bs=1M status=progress
 sync
 ```
 ### Native Amiga Workflow
 If you're working on a running Amiga with a hard drive already installed, you can prepare additional drives or partitions natively.
 **HDToolBox (partitioning):**
 ```
 ; From Workbench: open the Tools drawer, run HDToolBox
 ; Or from Shell:
 1> SYS:Tools/HDToolBox scsi.device
 ```
 **Install (write bootblock):**
 ```
 ; Make a partition bootable by writing a standard bootblock:
 1> Install DH0:
 ```
 **Format (from Shell):**
 ```
 ; Quick format a partition:
 1> Format DRIVE DH1: NAME "Work" FFS INTL QUICK
 ```
 **Format (from Workbench):**
 Select the partition icon → **Icons → Format Disk** → choose Quick Format.
 ### Decision Guide — Which Workflow to Use
 | Scenario | Recommended Workflow |
 |---|---|
 | **Building an HDF for an emulator** | `amitools` (fast, scriptable, no GUI needed) |
 | **Preparing a CF card for real hardware** | WinUAE (full HDToolBox access, PFS3 support) |
 | **Creating an ADF floppy image** | `amitools xdftool` (simplest) |
 | **Adding PFS3 to an existing drive** | WinUAE or native HDToolBox (PFS3 requires Amiga-side formatting) |
 | **Automated/CI disk image builds** | `amitools` (fully scriptable, headless) |
 | **Repartitioning a drive on a running Amiga** | Native HDToolBox |
 | **Mass-producing identical CF cards** | `amitools` to create master HDF → `dd` to clone |
 ---
 ## Physical Failure Modes
 ### Floppy Failures
 | Failure | Symptom | Cause | Recovery |
 |---|---|---|---|
 | **No boot (hand icon)** | Kickstart shows "Insert Workbench" | Bootblock corrupt, disk unformatted, or wrong filesystem ID | Re-install bootblock with `Install DF0:` |
 | **Read errors (blinking drive light)** | Repeated retries, eventual failure | Dirty heads, media degradation, demagnetization | Clean heads with isopropyl alcohol; disk may be unrecoverable |
 | **Track 0 failure** | Drive clicks repeatedly, never boots | Track 0 sensor misalignment or physical media damage at track 0 | Replace drive mechanism |
 | **Alignment drift** | Reads own disks but not disks from other drives | Stepper motor calibration drift | Realign with reference disk (Amiga Test Kit) |
 | **Motor doesn't spin** | No activity | CIA-B failure, broken belt (rare on Amigas), or power supply issue | Check CIA-B; replace drive |
 ### Hard Drive / IDE Failures
 | Failure | Symptom | Cause | Recovery |
 |---|---|---|---|
 | **No drive detected** | HDToolBox shows no drives | Wrong device driver name in ToolType, cable issue, drive DOA | Verify `SCSI_DEVICE_NAME`, check cable, test drive in another system |
 | **RDB not found** | Drive detected but no partitions | RDB corrupted or overwritten (e.g., by a PC partitioning tool) | Restore RDB from backup; or re-partition (data lost) |
 | **Filesystem validation on every boot** | "Validating DH0:" message on every reboot | Unclean shutdown with FFS, bitmap corruption | Let validation complete; switch to PFS3 for instant recovery |
 | **Data corruption (silent)** | Files contain garbage | `MaxTransfer` not set correctly on Gayle IDE | Set `MaxTransfer=$0001FE00` in RDB; re-copy affected files |
 | **Spin-up timeout** | Drive detected intermittently | Power supply insufficient for mechanical drive spin-up | Use a powered CF adapter, or replace with CF card |
 ### CompactFlash-Specific Failures
 | Failure | Symptom | Cause | Recovery |
 |---|---|---|---|
 | **Incompatible card** | Drive not detected or read errors | Card lacks True IDE mode, or uses incompatible ATA commands | Try a different CF brand (industrial-grade recommended) |
 | **Write protect** | Writes fail silently or with errors | CF card's internal write-protect activated | Replace card, or check adapter switch |
 | **Capacity mismatch** | Partition extends beyond physical media | HPA (Host Protected Area) reduces reported size | Disable HPA with `hdparm` or equivalent tool |
 | **Wear-out (rare)** | Increasing bad sectors over time | Flash cell exhaustion after millions of write cycles | Replace card; industrial CF rated for 2M+ cycles |
 ---
 ## Floppy vs Hard Drive vs CompactFlash — Summary
 | Property | DD Floppy (DF0:) | IDE Hard Drive (DH0:) | CompactFlash (DH0:) |
 |---|---|---|---|
 | **Capacity** | 880 KB | 20 MB – 4 GB (FFS limit) | 512 MB – 4 GB (FFS), 128 GB (PFS3) |
 | **Boot discovery** | Bootblock at sectors 0–1 | RDB scan → partition → bootblock | Same as IDE HDD (True IDE mode) |
 | **Transfer method** | Paula DMA (MFM → Chip RAM) | PIO (CPU `MOVE.W` loop) | PIO (same as IDE HDD) |
 | **DMA?** | Yes (Paula disk DMA, but MFM-encoded) | No (stock Gayle/A4000 IDE) | No (same interface) |
 | **CPU load during I/O** | Moderate (DMA reads, CPU decodes MFM) | 100% (CPU transfers every word) | 100% (same as IDE) |
 | **Throughput** | ~50 KB/s | ~1.5 MB/s (A1200), ~2.5 MB/s (A4000) | Same as IDE (limited by interface, not card) |
 | **OS bypass possible?** | Yes (custom trackloaders) | No (always goes through device driver and RDB) | No |
 | **Partitioning** | None (whole disk = one volume) | RDB (multiple partitions, boot priority) | RDB (same as HDD) |
 | **Filesystem options** | OFS, FFS | OFS, FFS, PFS3, SFS | Same as HDD |
 | **Removable at runtime?** | Yes (trackdisk.device tracks /DSKCHANGE) | No (hot-removal = data loss) | No (treated as fixed disk) |
 | **Failure mode** | Media degradation, alignment | Mechanical failure, spin-up timeout | Wear-out (rare), incompatibility |
 ---
 ## Historical Context and Modern Analogies
 ### How Competitors Handled Disk Boot
 The Amiga's RDB/AutoConfig/DiagArea architecture was remarkably advanced for its era. Contemporary systems used much simpler (and more limited) approaches:
 | System | Partitioning | Boot Discovery | Driver Loading |
 |---|---|---|---|
 | **Amiga (1985+)** | RDB — linked-list, unlimited partitions, embedded filesystem drivers | RDB scan → BootPri sort | AutoConfig DiagArea boot ROM |
 | **IBM PC (1981+)** | MBR — 4 primary partitions, 446-byte bootloader | INT 13h BIOS calls → MBR → VBR | BIOS provides basic INT 13h; OS loads its own drivers |
 | **Atari ST (1985+)** | Boot sector only — no partition table on floppies; AHDI for HDD | Read boot sector → execute | No expansion bus; driver in boot sector |
 | **Mac (1984+)** | Apple Partition Map — tagged partitions | SCSI Manager → boot blocks | ROM-resident SCSI Manager; no expansion ROM support until NuBus |
 ### Modern Analogies
 | Amiga Concept | Modern Equivalent |
 |---|---|
 | **RDB** | GPT (GUID Partition Table) — both use linked structures, both allow many partitions, both store metadata |
 | **AutoConfig + DiagArea** | UEFI Option ROMs — expansion cards install their drivers into the firmware's driver database at boot |
 | **`trackdisk.device`** | Linux block device layer (`/dev/sdX`) — abstraction over physical media |
 | **FileSysHdr in RDB** | Linux initramfs — filesystem drivers loaded from disk before the root filesystem is mounted |
 | **BootPri** | UEFI Boot Order — numbered priority list determining which device boots first |
 | **HDToolBox** | `gdisk`/`parted` — partition table editors |
 | **`amitools rdbtool`** | `sgdisk` — scriptable partitioning from the command line |
 ---
 ## MiSTer / FPGA Notes
 FPGA Amiga cores (MiSTer, Minimig, PiStorm) emulate the Gayle IDE interface to present `.hdf` files stored on an SD card as virtual hard drives.
 - **HDF compatibility** — MiSTer expects RDB-partitioned `.hdf` files. Create them with `rdbtool` or WinUAE. The core maps the HDF file to the emulated Gayle registers at `$DA0000`.
 - **ADF mounting** — Floppy images (`.adf`) are mapped to the emulated `trackdisk.device` — Paula's disk DMA reads from the ADF file as if it were a physical track.
 - **SCSI emulation** — Some cores provide a virtual SCSI controller for higher performance; this bypasses the Gayle PIO bottleneck and can theoretically deliver higher throughput since the "DMA" is just a memory copy on the FPGA.
 - **MaxTransfer** — The Gayle `MaxTransfer` issue applies to MiSTer's Gayle emulation too. Set `$0001FE00` in the RDB to avoid corruption, even though the "hardware" is emulated.
 ---
 ## References
 - **NDK 3.9**: `devices/trackdisk.h`, `devices/scsidisk.h`, `dos/filehandler.h`
 - **ADCD 2.1**: `Devices_Manual_guide/TrackDisk`, `Devices_Manual_guide/SCSI`
 - **amitools**: https://github.com/cnvogelg/amitools — `rdbtool`, `xdftool`, `romtool`
 - See also: [Cold Boot](cold_boot.md) — what happens before disk access
 - See also: [DOS Boot](dos_boot.md) — bootblock format and `dos.library` handoff
 - See also: [Kickstart Init](kickstart_init.md) — how device drivers are initialized
 - See also: [Early Startup](early_startup.md) — manual boot device selection
 - See also: [Gayle IDE & PCMCIA](../01_hardware/common/gayle_ide_pcmcia.md) — Gayle register layout
 - See also: [AutoConfig](../01_hardware/common/autoconfig.md) — Zorro bus and expansion ROM protocol
 - See also: [SCSI](../10_devices/scsi.md) — `scsi.device` driver interface and `HD_SCSICMD`
 - See also: [ATAPI](../10_devices/atapi.md) — ATA protocol, ATAPI packets, CF card details
 - See also: [Filesystem](../07_dos/filesystem.md) — RDB structure, FFS/OFS block layout, PFS3/SFS comparison
 - See also: [Custom Loaders and DRM](../05_reversing/custom_loaders_and_drm.md) — custom floppy trackloaders
--- a/02_boot_sequence/floppy_vs_hdd_physical_boot.md
+++ b/02_boot_sequence/floppy_vs_hdd_physical_boot.md
@ -0,0 +1,123 @@
 [← Home](../../README.md) · [Boot Sequence](../README.md)
 # Physical Boot Process: Floppy vs Hard Drive
 While [DOS Boot](dos_boot.md) covers the logical software handoff (from Kickstart to `dos.library` to the Startup-Sequence), it's equally important to understand the *physical* hardware mechanisms involved when an Amiga boots from a storage medium.
 The physical boot sequence dictates how raw data is pulled from magnetic media into Chip RAM before the CPU ever sees a `DOS\0` signature or an executable bootblock. This is especially relevant when analyzing [Custom Trackloaders](../05_reversing/custom_loaders_and_drm.md) which bypass the OS and interact with the hardware directly.
 ---
 ## 1. Booting from Floppy (DF0:)
 The Amiga's floppy drive interface is entirely "dumb." Unlike a modern SATA drive with its own onboard microcontroller, the Amiga CPU and custom chips must manually control the floppy drive's motors and decode its raw magnetic data.
 ### 1.1 The Hardware Handoff
 When the Kickstart ROM's `strap` module decides to boot from `DF0:`, it invokes `trackdisk.device`. This device driver issues commands directly to the CIA (Complex Interface Adapter) and Paula chips.
 ### 1.2 Step-by-Step Physical Process
 ```mermaid
 sequenceDiagram
    participant CPU (trackdisk.device)
    participant CIA (8520)
    participant Floppy Drive
    participant Paula (8364)
    CPU->>CIA: Set Motor On (CIA-B Port B)
    CIA->>Floppy Drive: Spin up spindle motor
    CPU->>CIA: Assert /STEP until /TRK0 is low
    CIA->>Floppy Drive: Move read head to Cylinder 0
    CPU->>Paula: Write $4489 to DSKSYNC
    CPU->>Paula: Write buffer address to DSKPTH
    CPU->>Paula: Write $8000+size to DSKLEN
    Paula->>Floppy Drive: Start reading flux transitions
    Floppy Drive-->>Paula: Raw MFM bitstream
    Paula-->>Paula: Wait for $4489 Sync Word
    Paula->>Chip RAM: DMA stream data
    CPU->>CPU: Decode MFM to binary (Sectors 0 & 1)
 ```
 1. **Spin Up**: The CPU toggles a bit on CIA-B Port B (`$BFD100`) to turn on the floppy drive motor. It waits a few milliseconds for the spindle to reach a stable 300 RPM.
 2. **Seek Track 0**: The CPU pulses the `/STEP` line while monitoring the `/TRK0` sensor. The drive clicks as the read/write head physically moves to the outermost cylinder (Track 0).
 3. **MFM DMA Read**: The CPU configures Paula for a disk read:
   - Sets the sync word in `DSKSYNC` (`$4489`).
   - Points `DSKPTH` (Disk Pointer) to an empty buffer in Chip RAM.
   - Writes to `DSKLEN` to start the DMA transfer.
 4. **Data Streaming**: Paula watches the raw magnetic flux stream coming from the drive. The moment it sees the magnetic pattern for `$4489`, it starts streaming the subsequent MFM data straight into Chip RAM via DMA.
 5. **Software Decode**: `trackdisk.device` reads the MFM data from RAM and runs an EOR/Bit-shift loop to convert the MFM bits back into standard binary bytes. It extracts the first two sectors (the 1024-byte bootblock).
 6. **Execution**: If the bootblock is executable, the CPU jumps to it. At this exact moment, **Custom Trackloaders** (used by games) will typically execute `Forbid()` and `Disable()`, permanently locking out `trackdisk.device` and manually repeating steps 2-5 for the rest of the game's data.
 ---
 ## 2. Booting from Hard Drive (IDE / SCSI)
 Unlike floppies, Hard Disk Drives (HDDs) are "smart." They have onboard controllers that handle physical head stepping, sector addressing (LBA or CHS), and error correction automatically. The Amiga simply asks the drive for a specific block of data.
 However, the Amiga's architecture means it doesn't intrinsically know how to read an HDD upon power-up.
 ### 2.1 The AutoConfig Phase
 Before an HDD can boot, the Amiga must discover its controller.
 1. **Zorro / AutoConfig**: During early startup, Kickstart probes the expansion bus.
 2. **ROM Mapping**: The HDD controller board (e.g., A2091 SCSI or A1200 internal IDE) responds. Kickstart maps the controller's onboard ROM into the Amiga's memory space.
 3. **Driver Initialization**: The controller's ROM contains the device driver (e.g., `scsi.device`). Kickstart runs the initialization code in this ROM, which binds the driver to the OS.
 ### 2.2 Reading the RDB
 The Amiga does not use PC-style MBR (Master Boot Record) or GPT. It uses the **Rigid Disk Block (RDB)**.
 1. **RDB Scan**: `scsi.device` asks the drive to read Block 0. If it doesn't find the ASCII signature `RDSK`, it checks blocks 1 through 15 until it finds it.
 2. **Partition Discovery**: The RDB contains a linked list of partitions (e.g., `DH0:`, `DH1:`).
 3. **Filesystem Loading**: Crucially, the Amiga supports loadable filesystems. If `DH0:` uses a custom filesystem (like PFS3 or SFS) that isn't in Kickstart, the RDB actually contains the *binary code for the filesystem itself*. `scsi.device` loads the filesystem code from the RDB into RAM and initializes it.
 ### 2.3 Step-by-Step Physical Process
 ```mermaid
 sequenceDiagram
    participant CPU (scsi.device)
    participant HDD Controller
    participant HDD
    participant Fast RAM
    CPU->>HDD Controller: Send READ command (LBA 0)
    HDD Controller->>HDD: Fetch RDB Sector
    HDD-->>HDD Controller: Sector Data
    HDD Controller->>Fast RAM: DMA Transfer
    CPU->>CPU: Parse RDB & Mount DH0:
    CPU->>CPU: Load Filesystem from RDB (if needed)
    CPU->>HDD Controller: Request Bootblock (LBA of DH0: root)
    HDD Controller->>HDD: Fetch Bootblock
    HDD-->>HDD Controller: Data
    HDD Controller->>Fast RAM: DMA Transfer
    CPU->>CPU: Execute Bootblock / Mount DOS
 ```
 Unlike floppies, HDD DMA transfers can typically go directly into **Fast RAM**, bypassing the chipset entirely (depending on the controller). Once the partition's bootblock is loaded and executed, control passes to `dos.library` and the `Startup-Sequence` exactly as it does for a floppy.
 ---
 ## 3. What Can Go Wrong (Failure Modes)
 Because physical boot sequences rely on moving parts and magnetic media, they are prone to specific physical failure states.
 ### 3.1 Floppy Failures
 *   **Track 0 Sensor Failure**: If the drive's `/TRK0` microswitch is dirty or broken, the drive will repeatedly slam the read head against the physical stop, producing a loud, rapid "grinding" or "machine gun" noise. It cannot find sector 0.
 *   **Alignment Drift**: Over time, the stepper motor can drift. The drive's head will physically rest between two tracks, reading a garbled mix of flux transitions. Paula will never see the `$4489` sync word. The system hangs or presents a "Not a DOS disk" error.
 *   **Dirty Read Heads**: Dust on the magnetic head weakens the flux signal. The hardware reads the `$4489` sync word, but random bits in the payload flip. The software MFM decode loop succeeds, but the Bootblock Checksum fails, kicking the user back to the Kickstart screen.
 ### 3.2 Hard Drive Failures
 *   **Spin-Up Timeout**: Older SCSI drives take up to 15 seconds to reach operational RPM. If the Kickstart ROM's wait loop times out before the drive asserts the `READY` signal, the Amiga will boot to the Kickstart screen, ignoring the HDD entirely. (Fixed by pressing `Ctrl-Amiga-Amiga` for a warm reboot after the drive is spinning).
 *   **RDB Corruption**: If the RDB sectors are overwritten, `scsi.device` will scan blocks 0-15, find nothing, and report the drive as unformatted/empty, even if all partition data is perfectly intact.
 *   **Filesystem Validation**: If the Amiga was powered off during a write, the filesystem's bitmap (which tracks free space) is left in an inconsistent state. On the next boot, `dos.library` locks the partition as Read-Only and launches a background "Validator" process. The hard drive LED will blink rapidly for minutes while it rebuilds the bitmap. If validation fails, the drive remains Read-Only.
 ---
 ## 4. Summary
 | Feature | Floppy (DF0:) | Hard Drive (IDE/SCSI) |
 |---|---|---|
 | **Hardware Control** | CPU directly controls motors & head stepping | Onboard controller handles mechanics |
 | **Data Encoding** | Raw MFM (decoded by CPU in software) | Hardware handles sector decoding |
 | **Boot Discovery** | Hardcoded to Track 0, Sector 0 | Scans blocks 0-15 for RDB (Rigid Disk Block) |
 | **DMA Target** | Must go to Chip RAM | Usually goes to Fast RAM |
 | **OS Bypass** | Trivial (Custom Trackloaders) | Rare (Requires full IDE/SCSI driver implementation) |
--- a/02_boot_sequence/kickstart_rom.md
+++ b/02_boot_sequence/kickstart_rom.md
@ -10,8 +10,6 @@ The Kickstart ROM is a single binary image containing the entire AmigaOS kernel
 ## ROM Types
 The Amiga's Kickstart ROM underwent significant evolution throughout the machine's lifespan, growing from a lean 256 KB firmware in the early days to a packed 512 KB kernel in the later 32-bit era. Understanding the physical constraints and memory mapping of these different versions is critical when modifying or swapping ROMs across different Amiga models. 
 | Kickstart | Size | Base Address | Models | ROM Chips |
 |---|---|---|---|---|
 | 1.0–1.1 | 256 KB | `$FC0000` | A1000 (WCS) | 2× 128 KB |
@ -31,8 +29,6 @@ The Amiga's Kickstart ROM underwent significant evolution throughout the machine
 ### Memory Layout (512 KB Kickstart)
 The Kickstart binary is not a filesystem; it is a meticulously structured, flat memory image. Because the 68000 CPU must boot directly from this address space, the ROM begins with hardcoded architectural vectors. Following this boot stub, the ROM is simply a sequential concatenation of resident modules (libraries and device drivers), bounded by a final checksum. 
 ```
 $F80000 ┌──────────────────────────────────┐
        │ Reset Vectors (8 bytes)          │
@ -84,8 +80,6 @@ $FFFFFF └───────────────────────
 ### ROM Header
 Immediately following the CPU reset vectors sits the ROM Header. This 16-byte structure is the first piece of metadata that system diagnostics and expansion tools inspect to verify the integrity, size, and version of the OS payload.
 ```c
 /* At ROM_BASE + 8 */
 struct KickstartHeader {
@ -102,29 +96,8 @@ struct KickstartHeader {
 | `$1111` | 256 KB ROM (Kickstart 1.x) |
 | `$1114` | 512 KB ROM (Kickstart 2.0+) |
 ### Physical ROM Interleaving (32-bit Architectures)
 While a Kickstart ROM image (e.g., `kick31.rom`) is distributed as a single, contiguous 512 KB file, the physical reality on 32-bit Amigas (A1200, A3000, A4000) is different. 
 The 68020/030/040 CPUs fetch instructions over a **32-bit data bus**. Because standard EPROMs of the era (like the 27C400 or 27C800) only have a **16-bit data bus**, the Amiga motherboard achieves 32-bit throughput by pairing two 16-bit ROM chips side-by-side and reading them simultaneously:
 - **ROM 0 (U314 on A1200)**: Connected to data lines **D31–D16** (the upper 16 bits).
 - **ROM 1 (U315 on A1200)**: Connected to data lines **D15–D0** (the lower 16 bits).
 To make this work, the logical 512 KB Kickstart file must be **word-interleaved** (sometimes confusingly called "byteswapped") when burned to physical EPROMs. 
 Since the image is just a linear sequence of 16-bit words, the split works like this:
 - **Word 0** (offset `$0000`) goes to **ROM 0**
 - **Word 1** (offset `$0002`) goes to **ROM 1**
 - **Word 2** (offset `$0004`) goes to **ROM 0**
 - **Word 3** (offset `$0006`) goes to **ROM 1**
 When the CPU reads a 32-bit longword from `$F80000`, the hardware selects both chips. ROM 0 outputs Word 0 onto the high half of the bus, and ROM 1 outputs Word 1 onto the low half. The CPU sees the perfectly reassembled 32-bit longword.
 When burning custom ROMs, modern EPROM programmers usually have an "Interleave" or "Word Split" function to handle this automatically. Alternatively, command-line tools like `srec_cat` can pre-split the single `.rom` file into `.hi` and `.lo` binary halves before burning.
 ### Checksum Complement
 To ensure the ROM image is uncorrupted, the entire memory block is checksummed by the early boot code. However, instead of storing the final calculated sum, the ROM stores a **complement** value near its physical end. This clever design ensures that if you sum every 32-bit longword in the entire ROM (including the complement itself), the final mathematical result is always `0xFFFFFFFF`.
 The checksum complement is located at a fixed offset near the end of the ROM:
 | ROM Size | Complement Offset | Absolute Address |
@ -165,29 +138,8 @@ Module N:
    ← rt_EndSkip points here
 ```
 ### How Exec Discovers and Initializes Modules
 During the system cold start, `exec.library` (which is always the first module executed) scans the ROM address space looking for the `$4AFC` magic word that signifies a `RomTag`. To make this scan nearly instantaneous, `exec` uses the `rt_EndSkip` pointer: when it finds a valid `RomTag`, it reads the module's metadata, and then jumps its scanning pointer directly to the address contained in `rt_EndSkip`, skipping the entire body of the module.
 As `exec` discovers valid modules, it sorts them into an array called `ResModules` based on their `rt_Pri` (Priority) and `rt_Version`. Higher priority modules will be initialized first. 
 Once the ROM scan is complete, `exec` calls its internal `InitCode` function. This function iterates through the `ResModules` array and initializes each module by inspecting its `rt_Flags`.
 #### The AUTOINIT Flag
 If a module's `RomTag` does **not** have the `AUTOINIT` flag set, `exec` simply performs a `JMP` to the address specified in `rt_Init`, leaving the module to initialize itself entirely from scratch.
 However, if the `AUTOINIT` flag **is** set (which is true for almost all standard libraries and devices), `exec` performs an elegant automated initialization:
 1. It treats the `rt_Init` pointer not as code, but as a pointer to a structured initialization table (containing the library's size, its function vectors, and its data structure initializers).
 2. `exec` automatically calls `MakeLibrary` on this table, dynamically allocating and populating the module's Base Structure in RAM.
 3. `exec` then examines the module's `rt_Type` (e.g., `NT_LIBRARY` or `NT_DEVICE`) and automatically calls `AddLibrary`, `AddDevice`, or `AddResource` to permanently register the module in the system's public lists.
 This means a developer can write a complete device driver or library in C or Assembly, set the `AUTOINIT` flag, and let the OS handle the memory allocation and list registration automatically.
 ### Kickstart 3.1 (40.068) Module Inventory
 To illustrate the sheer density of the Kickstart ROM, below is the standard module inventory for AmigaOS 3.1. Notice how the core `exec.library` commands the highest priority to ensure it initializes the system lists before any other device attempts to register itself. Conversely, the `strap` module (the bootstrap that displays the insert disk screen) runs at a negative priority, guaranteeing it only executes after all hardware and filesystems have fully initialized.
 | Module | Type | Size (approx) | Init Priority |
 |---|---|---|---|
 | exec.library | `NT_LIBRARY` | ~48 KB | 126 |
@ -224,8 +176,6 @@ The remaining ~112 KB contains fonts, boot code, ROM entry, padding, and the che
 ### Using Python (romtool from amitools)
 For cross-platform development (macOS, Linux, Windows), the open-source `amitools` suite is the gold standard. Its `romtool` utility provides an elegant, non-destructive way to parse, split, and rebuild Kickstart ROMs directly from the command line.
 ```bash
 # Install amitools
 pip install amitools
@ -324,79 +274,18 @@ romtool split kick31.rom modules/
 # Replace a module:
 cp my_patched_dos.library modules/dos.library
 # Rebuild:
 # Rebuild:
 romtool build modules/ custom_kick.rom
 # romtool automatically:
-#   1. Packs all modules sequentially (concatenating their binaries)
+#   1. Packs all modules sequentially
-#   2. Ensures the $4AFC RomTag magic words remain word-aligned
+#   2. Builds the ResModules pointer table
-#   3. Re-calculates and updates all rt_EndSkip pointers to span the concatenated binaries
+#   3. Calculates and inserts checksum complement
-#   4. Calculates and inserts the global checksum complement at the end of the ROM
+#   4. Verifies the final image
 #   5. Verifies the final image
 # Verify:
 romtool info custom_kick.rom
 ```
 ### Adding Custom Auto-Initializing Modules
 If you write a custom module (e.g., a modern IDE driver or a new filesystem) and want it to be automatically loaded and initialized when the Amiga boots, you simply need to build it as a standard AmigaOS Resident Module.
 1. **Structure your code:** Ensure your compiled binary begins with a valid `RomTag` structure (magic word `$4AFC`).
 2. **Set the correct flags:** Set the `AUTOINIT` bit in `rt_Flags` and point `rt_Init` to your auto-init table so `exec` handles the `MakeLibrary`/`AddDevice` boilerplate.
 3. **Choose a priority:** Set your `rt_Pri` carefully. If your module replaces a standard ROM module (like `scsi.device`), it must have a higher priority than the original so it initializes first and takes over the device name. If it's a completely new driver, standard priority (usually 0 to 50) is fine.
 4. **Pack it into the ROM:** Add your compiled binary to the `romtool` build directory and list it in `index.txt`. When `romtool` builds the ROM, your module is physically appended. On the next boot, `exec`'s cold start scan will discover your `$4AFC` tag, add it to `ResModules`, and auto-initialize it.
 #### Wrapping Disk-Based Devices (e.g., ehide.device)
 Often, you will want to add a third-party driver to your ROM that was distributed as a standard AmigaDOS disk executable (Hunk format), such as the TerribleFire `ehide.device`. These files **do not have a RomTag** and contain relocations that must be resolved in RAM; they will crash if executed directly from the ROM address space.
 To pack them into a Kickstart ROM, you must wrap them using a **ROM Wrapper** (often called a *RomHeader* or *RomModule* loader).
 **How a ROM Wrapper works:**
 1. The wrapper is a tiny snippet of assembly containing a valid `$4AFC` `RomTag`.
 2. The original `ehide.device` file is embedded as a binary payload immediately following the wrapper.
 3. During cold boot, `exec` finds the wrapper's `RomTag` and jumps to its `rt_Init` routine.
 4. The wrapper's init routine allocates RAM (using `AllocMem`), unpacks the embedded Hunk payload into that RAM, applies all memory relocations (acting like a miniature `LoadSeg`), and finally jumps to the device's true initialization vector in RAM.
 **Tools & Projects:**
 * **Remus:** The Amiga-native GUI tool Remus has a built-in feature to wrap standard AmigaDOS executables. If you drag `ehide.device` into the build list, Remus automatically prepends a wrapper and pre-calculates relocations.
 * **DoRom / RomModule:** Classic command-line utilities found on Aminet that take a disk-based `.device` and output a `.rom` module ready to be packed by `romtool`.
 * **BlizKick / rommodule:** Toni Wilen and other developers have written standard open-source wrappers (often referred to as `rommodule`) originally designed for BlizKick and WinUAE, which are perfectly suited for building custom physical ROMs.
 **Illustrative Wrapper Snippet:**
 ```m68k
 RomTag:
        ; 1. Standard RomTag points to the loader
        DC.W    $4AFC           ; rt_MatchWord
        DC.L    RomTag          ; rt_MatchTag
        DC.L    EndSkip         ; rt_EndSkip
        DC.B    $81             ; rt_Flags (RTF_AUTOINIT | RTF_COLDSTART)
        DC.B    $25             ; rt_Version
        DC.B    $03             ; rt_Type (NT_DEVICE)
        DC.B    $40             ; rt_Pri (High priority to replace standard IDE)
        DC.L    NameString      ; "ehide.device"
        DC.L    IdString
        DC.L    InitRoutine     ; Jumps here on boot
 InitRoutine:
        ; 2. Allocate RAM for the payload
        move.l  #PayloadSize, d0
        move.l  #MEMF_PUBLIC, d1
        jsr     _LVOAllocMem(a6)
        ; 3. Copy and relocate the embedded Hunk payload into RAM
        ; ... (Mini-LoadSeg logic goes here) ...
        ; 4. Jump to the uncompressed/relocated device init in RAM
        jmp     (a0)            
        ; 5. The actual ehide.device hunk executable payload is appended here
 PayloadStart:
        INCBIN  "ehide.device"
 EndSkip:
 ```
 ### Using Remus (Amiga-native)
 Remus is a GUI-based Kickstart editor:
@ -459,8 +348,6 @@ def build_rom(modules, rom_size=524288):
 ### Extended ROMs (CD32, A4000T)
 As the Amiga architecture evolved, the 512 KB `$F80000` space became too small to house all the necessary drivers—especially for specialized hardware like the CD32 console or the A4000T's SCSI controllers. Commodore solved this by mapping a secondary "Extension ROM" into the `$E00000` address space.
 Some systems have a secondary ROM mapped at `$E00000`:
 | System | Main ROM | Extension ROM |
@ -469,60 +356,33 @@ Some systems have a secondary ROM mapped at `$E00000`:
 | A4000T | `$F80000` (512 KB) | (None — all in main ROM) |
 | A1000 | WCS (256 KB) | Loaded from floppy into WCS RAM |
-## MapROM, WCS, and Shadow RAM Architectures
+### MapROM / Soft-Kickstart
-While modern Amiga users associate "MapROM" with accelerator cards speeding up ROM access or soft-loading custom Kickstart images, the concept of mapping a disk-loaded OS into RAM was actually invented by Commodore out of sheer necessity. 
+Many accelerator boards support **MapROM** — loading a Kickstart image into Fast RAM and remapping the ROM address range:
-### Historical Origins: A1000 and A3000
+```
 1> LoadModule ROM:68040.library     ; Load replacement module
 1> MapROM kick32.rom                ; Copy to Fast RAM, remap $F80000
 1> Reset                            ; Warm reset — boots from RAM copy
 ```
-Commodore utilized RAM-mapped ROMs twice in the Amiga's history when hardware launch dates preceded the completion of the operating system:
+This allows running newer Kickstart versions without burning EPROMs.
-1. **The Amiga 1000 WCS (1985):** The original Amiga 1000 shipped without a Kickstart ROM chip. Instead, it contained a tiny 8KB boot ROM and 256KB of dedicated RAM called the **Writable Control Store (WCS)**. When powered on, the boot ROM prompted the user for a Kickstart floppy disk. It loaded the 256KB OS into the WCS RAM, triggered a hardware register to write-protect that RAM, and mapped it to the ROM address space (`$FC0000`). This allowed Commodore to ship the A1000 while Kickstart 1.0/1.1 was still heavily in beta.
+### 1 MB ROM Images
 2. **The Amiga 3000 "SuperKickstart" (1990):** When the Amiga 3000 was ready to launch, AmigaOS 2.0 was not finished. Commodore shipped early A3000s with physical **Kickstart 1.4** ROMs. These were not a complete OS; they were essentially a bootloader. Kickstart 1.4 read a file named `DEVS:kickstart` (containing OS 1.3 or a 2.0 beta) from the hard drive into Fast RAM. It then used the 68030 processor's internal **MMU (Memory Management Unit)** to transparently map that Fast RAM to the `$F80000` ROM address space. 
-It was only later that third-party accelerator manufacturers (like Phase5 and Apollo) co-opted and branded this concept as **"MapROM"**, realizing it was the perfect solution for both overcoming the 16-bit physical ROM speed bottleneck and allowing users to upgrade to Kickstart 3.1 without buying physical chips.
+Some setups combine a 512 KB Kickstart with a 512 KB extension ROM:
 ### Why Accelerators Use MapROM
 Because the physical Kickstart ROMs on the Amiga motherboard reside on a relatively slow 16-bit data bus (even on 32-bit machines, ROM access is significantly slower than Fast RAM), executing OS routines directly from ROM creates a bottleneck. MapROM solves this by copying the Kickstart image into fast 32-bit RAM, and redirecting all CPU reads for the ROM address space (`$F80000`) to that RAM.
 ### How the Remap Physically Happens
 The Amiga must always begin its initial power-on sequence using the physical ROM chips, because the MapROM redirect is not yet active. The remap happens in a multi-stage process:
 1. **Cold Boot:** The Amiga powers on. The CPU fetches its initial PC from the physical ROM chips at `$F80000` and boots normally.
 2. **Image Loading:** During `S:Startup-Sequence` (or manually in a shell), a MapROM tool (e.g., `BlizKick`, `MuMapROM`, or `CPU FASTROM`) is executed. The tool allocates 512KB of Fast RAM and copies either the physical ROM (for a speed boost) or a `.rom` file from disk into this RAM buffer.
 3. **The Redirect:** The tool activates the redirection using one of two methods:
   - **Hardware MapROM:** Accelerators with a dedicated memory controller (like Phase5 Blizzards) have a specific hardware register. When toggled, the accelerator's logic physically intercepts any CPU bus accesses to `$F80000` and routes them directly to a dedicated 512KB slice of Fast RAM on the card.
   - **MMU MapROM:** Tools like `MuMapROM` configure the 68030/040/060 Memory Management Unit (MMU). The MMU translation table is updated so that logical accesses to `$F80000` are translated in silicon to the physical address of the allocated Fast RAM. The MMU page is marked as Cacheable and Read-Only.
 4. **The Reset:** Once the redirect is configured, the tool triggers a system reset (often a "warm" soft-reset via CPU instruction, or triggering the chipset reset line). 
 5. **Execution:** The CPU resets and fetches the initial PC from `$F80000`. Because the Hardware MapROM latch or the specific MMU configuration is designed to *survive* a soft reset, the CPU is now reading from the Fast RAM copy. `exec.library` boots identically to a cold start, but executes entirely from the mapped image.
 ### Reset Survival and Limitations
 * **Soft Resets (Ctrl-A-A):** Hardware MapROM implementations usually survive a keyboard reset because the accelerator's CPLD retains the register state. MMU implementations often drop the MMU tables on a keyboard reset unless a resident program traps the reset vector to restore the MMU state immediately.
 * **Cold Resets (Power Cycle):** No MapROM implementation survives a power cycle. The machine will always fall back to the physical ROMs on a cold boot.
 * **Auto-Mapping:** Some accelerators have their own small boot ROM on the card (acting as an expansion device) that can automatically intercept the boot sequence, copy the physical ROM to RAM, and engage Hardware MapROM before DOS even loads.
 ### 1 MB Custom ROM Images
 Modern Amiga enthusiasts often exhaust the standard 512 KB limit when trying to pack third-party filesystems (like PFS3), updated SCSI/IDE drivers (like `ehide.device`), and patched `icon.library` files into a custom Kickstart. 
 To bypass this limit, modders can construct massive 1 MB custom ROM images. This is achieved by combining the primary 512 KB Kickstart with a custom 512 KB Extension ROM. When burned to a 1 MB EPROM (like the 27C800) or a modern Flash adapter, the Amiga effortlessly boots the main kernel from `$F80000` and then auto-discovers the extra drivers housed in the `$E00000` space.
 ```
 $E00000–$E7FFFF: Extension ROM (512 KB)
 $F80000–$FFFFFF: Main Kickstart (512 KB)
 ```
-Tools like Remus and Capitoline can effortlessly build these combined 1 MB images.
+Tools like Remus and Capitoline can build combined 1 MB images.
 ---
 ## Burning Physical ROMs
 Once you have meticulously crafted and verified a custom Kickstart image using tools like `romtool`, the final frontier is migrating that binary out of the digital realm and into physical silicon. Burning Amiga ROMs requires selecting the correct EPROM type that matches your motherboard's socket specifications, and—crucially—interleaving the data correctly if you are targeting a 32-bit machine.
 | ROM Size | EPROM Type | Pin Count | Notes |
 |---|---|---|---|
 | 256 KB | 27C020 | 32-pin | Used in pairs (Hi/Lo byte) |
@ -579,10 +439,9 @@ print(f'Checksum: \${ s:08X}', '✓' if s == 0xFFFFFFFF else '✗ BAD')
 ## References
- AmigaOS NDK 3.1 / 3.2: `exec/resident.h`, `exec/execbase.h`
+- NDK39: `exec/resident.h`, `exec/execbase.h`
 - amitools: `romtool` — https://github.com/cnvogelg/amitools
 - See also: [Cold Boot](cold_boot.md) — boot sequence using the ROM
 - See also: [Kickstart Boot Diagnostics](kickstart-boot-diagnostics.md) — ROM checksum algorithm, CC_BADROMSUM red screen
 - See also: [Kickstart Init](kickstart_init.md) — how residents are initialized
 - See also: [Resident Modules](../06_exec_os/resident_modules.md) — RomTag structure
 omTag structure
--- a/README.md
+++ b/README.md
@ -86,7 +86,7 @@ The Amiga's documentation was scattered across out-of-print manuals, Usenet post
 | [**kickstart_rom.md**](02_boot_sequence/kickstart_rom.md) | **Kickstart ROM internals: binary structure, module inventory, extraction tools, custom ROM building** |
 | [kickstart_init.md](02_boot_sequence/kickstart_init.md) | ExecBase creation, capture vectors, ROM scan algorithm, 4-phase resident init |
 | [dos_boot.md](02_boot_sequence/dos_boot.md) | strap module, boot block format and execution, MountList, Startup-Sequence walkthrough |
-| [disk_boot.md](02_boot_sequence/disk_boot.md) | **Disk boot deep dive: floppy MFM physics, HDD/IDE/SCSI boot (PIO vs DMA), RDB partitioning, controller & driver ecosystem (Gayle, GVP, A4091, TF1260), CompactFlash, disk image preparation (amitools, WinUAE, HDToolBox), failure modes** |
+| [floppy_vs_hdd_physical_boot.md](02_boot_sequence/floppy_vs_hdd_physical_boot.md) | Physical hardware mechanisms: floppy MFM streaming, HDD RDB scanning, DMA transfers, failure modes |
 | [early_startup.md](02_boot_sequence/early_startup.md) | Early Startup Control menu: device selection, display mode, recovery scenarios |
 | [kickstart-boot-diagnostics.md](02_boot_sequence/kickstart-boot-diagnostics.md) | **Kickstart POST: color-screen self-test, 7-phase ColdStart, coldCrash handler, diagnostic cartridge, troubleshooting** |