pureboot: the 1284P rides a 1 KiB slot — its own boot-sector minimum

The far machinery (ELPM reads, RAMPZ page commands, wire-word math)
costs ~46 B over the m328P's 504, and the tsb-calibrated C++-to-asm
gap says no implementation of this feature set reaches 512 on this
chip — a boundary its hardware does not have anyway: the 1284P's
smallest boot sector is 1 KiB. The slot therefore becomes
per-geometry (512 B, or 1 KiB past 64 KiB), which the host derives
from the word-addressing flag; slot arithmetic unifies (the index is
the wire high byte with its low bit dropped in either unit), the
update preflight demands a two-slot boot section in the chip's own
terms, and pbapp's hand-back jumps to the real slot base. libavr's
far primitives split their RAMPZ/Z asm operands (a page never
crosses 64 KiB, so callers keep a byte and a 16-bit cursor — the
32-bit address folds away; flash_load_far's byte form becomes the
out-RAMPZ+elpm pair avr-libc's pgm_read_byte_far rebuilds per call),
and the host splits reads at 64 KiB boundaries. All ten chips pass
the full suite — the 1284P at 558 B including protocol, relocation,
and the power-fail self-update — with pureboot byte-identical across
generated and reflect modes everywhere, and the original three
chips' images unchanged to the byte (488/502/504).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

pureboot/README.md

@@ -2,22 +2,28 @@
 
 A serial bootloader on [libavr](https://git.blackmark.me/avr/libavr), pure by
 constraint: one C++ source, no inline assembly, no global register variables
-(attributes allowed), built for every chip libavr targets, **512 bytes on
-each** — 488 B on the ATtiny13A, 502 B on the ATtiny85, 504 B on the
-ATmega328P. The device speaks primitives; every composite — verify, erase,
+(attributes allowed), built for every chip libavr targets, **fitting each
+chip's smallest boot sector**: 512 bytes everywhere — 488 B on the
+ATtiny13A, 502 B on the ATtiny85, 466–504 B across the megas — except the
+ATmega1284P, whose smallest boot sector is 1 KiB and whose far-flash
+machinery (ELPM reads, RAMPZ page commands, word-addressed wire) lands at
+558 B in a 1 KiB slot: the 512-byte figure is a hardware boundary that chip
+simply does not have, and no implementation of this feature set fits it
+there. The device speaks primitives; every composite — verify, erase,
 reset-vector surgery, updating the loader itself — lives in the host tool
 (`pureboot.py`).
 
 The image is **position-independent**: control flow is PC-relative, the
-read/write paths take wire addresses, the write guard protects the 512-byte
-slot the code is *running* in (from the runtime return address), the info
-block is addressed from that same anchor, and the application jump is an
-indirect call to an absolute entry. The identical binary therefore runs from
-any 512-byte slot with every command intact — which makes pureboot **its own
-staging loader**: the host installs the same binary one slot below the
-resident, jumps into it, and lets it rewrite the resident. On the tinies the
-budget is 510, not 512: a slot's last word belongs to the host-managed
-trampoline (below).
+read/write paths take wire addresses, the write guard protects the slot the
+code is *running* in (from the runtime return address), the info block is
+addressed from that same anchor, and the application jump is an indirect
+call to an absolute entry. The identical binary therefore runs from any
+slot with every command intact — which makes pureboot **its own staging
+loader**: the host installs the same binary one slot below the resident,
+jumps into it, and lets it rewrite the resident. The slot is 512 bytes
+(1 KiB on the word-addressed large chips, matching their boot-sector
+minimum); on the tinies the budget is 510, not 512: a slot's last word
+belongs to the host-managed trampoline (below).
 
 ## Link