Carry project memory in the repo, with tools/memory-sync.sh

Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:

  - D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
    invisible until moved across by hand.
  - Development happens from Windows and from Linux, and each looks in a
    different place for the same checkout.

Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.

The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.

.claude/memory/schunix-iso-boot.md

@@ -0,0 +1,49 @@
+---
+name: schunix-iso-boot
+description: "`make iso` builds a bootable CD; it needs El Torito no-emulation plus ATAPI because the loader never uses INT 13h"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: a665e14b-86bd-4b41-a228-51377f3e9225
+  modified: 2026-08-04T17:28:16.714Z
+---
+
+**`make iso` produces a bootable `schunix.iso`** (added 2026-08-04). Always a
+RAMROOT build — a disc that needed a second disk for its root would not be an
+install medium, and read-only media cannot host a writable root anyway.
+
+**Why it is built the way it is.** Schunix's loader never calls INT 13h: it
+drives the IDE registers directly, and stage2 has already switched to
+protected mode before it reads the kernel. That rules out both El Torito
+emulation modes (hard-disk emulation exists only through the BIOS) and floppy
+emulation (2.88 MB cap). So:
+
+- `boot/cdboot.S` — a separate stage 1 for optical media. `tools/mkiso.sh`
+  passes `-boot-load-size 25`, so the BIOS loads cdboot *and* all 24 sectors of
+  stage2 before anything of ours runs, putting stage2 at 0x7E00 exactly where
+  `bootasm.S` would have. cdboot only records the medium and jumps.
+- The medium flag is one byte past the verbose flag, at `VBE_INFO_ADDR + 0x101`.
+  **`bootasm.S` must clear it** or a warm reboot from a disc sends a hard-disk
+  boot looking for an optical drive.
+- `stage2main.c` gained an ATAPI reader (PACKET + SCSI READ(12), 2048-byte
+  blocks with a one-block cache) and finds where it was loaded from by reading
+  the El Torito boot catalog: LBA 17, pointer at offset 0x47, then Load RBA at
+  catalog offset 40.
+- **Do not pass `-boot-info-table`** to xorriso — it patches 56 bytes over
+  offset 8 of the boot image, which is the middle of cdboot's code. That is
+  why the boot catalog is parsed instead.
+
+**The trap that cost the most time here:** ATAPI's 0x14/0xEB signature is only
+valid until something issues a command, and the BIOS has just finished reading
+the disc to load us — so on a CD boot the signature is *always* stale.
+`atapi_reset()` (SRST via the control port at `io + 0x206`) is what makes the
+probe work.
+
+Two unbounded waits were hiding behind that, both of which hung with no
+message on a machine with no ATA disk: `waitdisk()` in stage2main.c and
+`idewait()` in kernel/dev/ide.c. Both are bounded now, `ideinit()` tolerates an
+empty channel, and anything that *probes* a disk must call
+`ide_disk_present()` first — `iderw()` rightly panics on an absent drive.
+
+Check it with `pwsh -File tools/bootcheck.ps1 -Iso -Fb`, which boots with no
+hard disk attached at all. See [[schunix-verify-by-driving-shell]].