CADR-WEB-303 ABI 1.3 boot-media controller reimplementation specification

Status, target, and nonclaims

CADR-WEB-303/ABI1.3/C-M4-BOOT-MEDIA-v1 specifies the disk path needed by the selected maintained System 303 world from its first disk START through the source-identified terminal boot-media chain and a quiet controller suffix. It is the M4 compatibility profile for the browser roadmap.

The selected successful chain is exact:

1. the earlier diagnostic START under command 0405;
2. command 011, unit 0, LBA 1, memory page 0: guest-to-media write;
3. command 010, unit 0, LBA 1, memory page 0: media-to-guest comparison;
4. command 000, unit 0, LBA 0, memory page 0: media-to-guest read;
5. after the first 0405 START, executed micro-PC 0355, p1 0356, next micro-PC 0357 at stabilized boundary S1,029,996;
6. no later disk event through S1,030,044.

Nonclaim: this profile does not establish LMFS mounting, FILE-SYSTEM-RUNNING, pack membership, historical disk timing, arbitrary media compatibility, browser UI behavior, persistence, or a historical MIT format. The later CADR-WEB-303-LMFS-OVERLAY profile owns filesystem semantics. The base disk is a local unresolved import and is not redistributed.

This subsystem is headless. There is no visible application state for which a runtime screenshot would add evidence; the normative visual requirement is therefore not applicable. The exact machine, controller, and media transcripts serve as the runtime observation.

Normative language and release profile

MUST, MUST NOT, SHOULD, and MAY constrain an independent implementation of this reconstruction profile. They do not assert that the historical CADR used the new host ABI or evidence formats.

The public System 46 tree remains historical comparison evidence, not the implementation target for this profile. Maintained LM-3 source supplies the selected controller and boot behavior. Exact source links and verification date belong in the release record because a changing browser or repository view is not itself a frozen artifact.

Evidence ledger

Source, compiled artifact, runtime observation, manuals, and papers remain separate evidence categories. Equality between native and Wasm is a portability witness, not an independent oracle; the maintained-usim projection is required to guard against a shared portable-core error.

The selected local load-band/base is compiled-image and runtime-input evidence; its identity and observed bytes constrain this profile, but the image is not redistributed and does not establish source intent. No manual or paper is normative for the reconstructed ABI1.3 host interface, volatile overlay, or evidence formats. Historical manuals and papers provide hardware context only; they were not used to substitute for the selected source and runtime transition witnesses.

Components and ownership

guest microengine
  -> XBUS disk registers
      -> controller state + CCW fetch
          -> payload-bearing or payload-free host request
              -> one attached range service
                  -> read-only base descriptor / immutable Blob
                  -> volatile block-1 overlay
              -> copied completion
          -> controller completion application
              -> page write, comparison, or write acknowledgement

portable core -> CDRM4CTRL1
host service  -> CDRM4MEDIA1
every quiet boundary -> CDRSTATE1/2/3 transcript
final quiet state -> CDRSTATE4

The core owns controller, request, copied completion, and diagnostic evidence state. The host service owns the range source, latency policy, staged write, and committed overlay. The dedicated worker serializes all JavaScript requests; a second poll, detach, snapshot, or restore cannot race an earlier poll.

No guest pointer, host pathname, file descriptor, JavaScript object, wall clock, or C structure representation crosses the ABI. All multi-byte evidence fields are fixed-width little-endian values. Page hashes use the canonical 1,024-byte stream formed by encoding 256 guest words least-significant byte first.

Controller registers and status

The disk occupies four XBUS word offsets. Read and write meanings differ.

The selected state contains command, CLP, DA, LMA, pending CCW address and index, pending guest page address, pending LBA, transfer-active, reset, done-interrupt enable, attention-interrupt enable, full status, and bus-interrupt state.

Required status bits are:

Reset command 016 clears controller state, retains the selected compatibility profile, sets not-active, and enters reset condition. Command zero releases reset. Diagnostic evidence history is not erased by an in-guest controller reset; cold power clears it. Unit selection admits only unit zero. Cylinder, head, and block must be within the selected T-300 geometry. An unavailable unit sets offline; an invalid CHS or end-of-media continuation sets seek error.

Command 4 seeks, command 5 performs the source-ordered at-ease/recalibrate/fault clear compound behavior, and command 6 is the source-visible offset-clear no-op. Unsupported command codes end the transfer with fault and CADR_STATUS_UNIMPLEMENTED_DEVICE.

CCW and transfer algorithm

START validates unit and CHS, makes the controller active, sets CCW index zero, then reads the current CCW. Under SYSTEM_303, the high 16 CLP bits remain fixed while addition of the CCW index wraps the low 16 bits. USIM_330D unmasked addition is a separately selectable compatibility rule and MUST NOT be averaged into this profile.

For each CCW:

1. set pending CCW address and LMA; set CCW-cycle status;
2. read one 32-bit guest word; on failure, set NXM and finish;
3. clear CCW-cycle; decode guest page address as ccw & 0x00ffff00;
4. derive LBA from unit/cylinder/head/block;
5. issue exactly one 1,024-byte block operation;
6. after accepted completion, transfer or compare 256 words;
7. reread the CCW; bit zero clear ends the chain, bit zero set advances the CCW index and disk address before issuing the next request.

Write command 011 copies the guest page into canonical bytes before publishing the request. Compare command 010 reads a page without modifying memory and sets the read-compare bit on any differing word. Command 000 reads and writes all 256 words. A page transfer is atomic at the selected host boundary: a rejected or short completion does not expose a partial page.

ABI1.3 request and completion lifecycle

ABI major remains 1; ABI minor 3 adds cadr_host_request_m4, whose fixed fields are operation, generation, request ID, descriptor count, expected completion count, and request-payload count. The frozen payload-free request API remains valid for a current-minor caller; it rejects only a request whose payload cannot be represented by that API.

Read descriptor:

u64 first-block
u32 block-count
u32 block-bytes

Write descriptor:

u64 transaction-id
u64 first-block
u32 block-count
u32 block-bytes

The selected write requires transaction ID equal to the core-assigned request ID, first block 1, one 1,024-byte block, a 1,024-byte request payload, and zero completion bytes. The descriptor and payload MUST be validated and copied before request publication. Trace code 6 records both hashes in that same preflighted transaction. Enabling trace therefore cannot reject or misdescribe a valid write.

The lifecycle is:

ISSUE -> CAPTURE -> [guest-tick latency] -> DELIVERY -> APPLICATION
                    \-> rejection/abort leaves controller and overlay uncommitted

Generation, request ID, operation, descriptor, request-payload hash, and expected completion count are immutable through the chain. Completion acceptance and controller application are separate transitions. Stale, duplicate, wrong generation, wrong request, wrong operation, short, oversized, or malformed completions fail without applying a page.

Range source and volatile overlay

The final host interface is a bounded range reader. Native retains one read-only descriptor; JavaScript retains an immutable Blob/File identity or an equivalent range source. Neither runner reopens a pathname between requests. Artifact ingress verifies the selected size and SHA-256 before execution, and the release gate rehashes the base afterward.

The boot sequence genuinely writes LBA 1. Calling M4 “read-only” would therefore be incorrect. The M4 host service implements a deliberately narrow volatile overlay:

• only one block at LBA 1 may be written;
• bytes are staged before completion delivery;
• accepted successful delivery publishes the page and increments generation from 0 to 1 exactly once;
• the following comparison reads the overlay, not the unchanged base;
• LBA 0 reads from the base;
• an identical replay of the same (generation, request ID, transaction ID, payload hash) is idempotent and does not increment generation;
• mismatched reuse, an older identity, host failure, detach during capture, or a rejected completion discards staging and cannot publish;
• reset after host commit retains the already committed volatile overlay; reset before accepted delivery discards the stale stage;
• explicit service discard clears overlay bytes and identity.

SHA-256(
  "CDRM4OVERLAY1\0" ||
  base-sha256 ||
  LE64(entry-count) ||
  sorted(LE64(block-number) || page-sha256)
)

Guest-time scheduling and worker lifecycle

Latency is measured only in clock_slots_completed. The selected gate uses zero: capture and delivery occur in the same between-boundaries service turn, followed by one zero-slot core call that applies the queued completion. Host fetch duration, event-loop delay, tab visibility, and wall time do not advance guest time.

JavaScript poll and detach share one lifecycle queue and attachment epoch. Detach marks the service synchronously before an awaited range read can begin; a capture from an older epoch cannot commit afterward. Completion dispatch is the point-of-no-return: if detach begins while the external complete callback is already in flight, that accepted delivery finishes, emits its delivery/commit evidence, and only then may the queued detach clear the volatile overlay. The same detach discards a returned positive-latency request that has staged bytes but has not begun completion dispatch; it does not require the caller to advance the service to its due tick first. The worker marks media busy before capture and clears it only after the service turn. A worker failure or termination discards the volatile service.

Dedicated-worker protocol version 2

ABI1.3 uses CADR-WEB dedicated-worker protocol version 2. The first well-formed, in-order request selects version 1 or 2 for that worker session; every later request MUST use the selected version, and every response or protocol error reports it. Unsupported versions and attempts to change version are malformed messages and do not consume the expected request identifier.

Version 1 remains the exhaustive M3 request tree specified by the headless-core companion. It rejects every M4-only operation with INVALID_ARGUMENT. Its host-next-request response has only request and descriptor, and a request with a nonzero payload count is invalid under that profile.

Version 2 includes all version-1 operations and adds this exact request subtree:

M4 additions
├─ media-overlay-state(
│    busy:boolean, dirty:boolean, snapshotBlocked:boolean,
│    overlayGeneration:u64 BigInt, detached?:true)
├─ run-digest-batch-m4(clockSlots: 1..4096)
├─ boundary-digest-v4
├─ boot-media-observation
└─ disk-evidence

In version 2, a successful host-next-request reply is:

{
  type: "cadr-response", version: 2, id, op, status: 0, ok: true,
  request: {
    operation:u32, generation:u64 BigInt, requestId:u64 BigInt,
    descriptorByteCount:u64 BigInt,
    completionByteCount:u64 BigInt,
    requestPayloadByteCount:u64 BigInt
  },
  descriptor: ArrayBuffer,
  requestPayload: ArrayBuffer
}

The descriptor is at most 64 bytes, request payload at most 1,024 bytes, and completion at most 1 MiB. Each is copied out of module memory before transfer. media-overlay-state is a worker-side snapshot fence: dirty state requires a nonzero monotonic generation; dirty or fault-progress state cannot be cleared without detached: true; and detach is valid only with busy, dirty, and snapshot-blocked false and generation zero. While any fence is set, snapshot size, save, and both restore forms return NOT_READY.

Reset and snapshot semantics

Core reset invalidates outstanding request identity and rejects a later stale completion. It does not prove that a host overlay was discarded. Service reset and core reset are coordinated explicitly:

• reset before completion acceptance discards staging;
• reset after accepted write delivery preserves the committed volatile overlay;
• later block-1 reads still observe that committed page.

CDRSNAP1 minor 1 does not serialize the host service, staged write, committed overlay, overlay generation, range attachment, latency queue, or targeted-fault occurrence progress. Snapshot size, save, and restore MUST return not-ready while media is busy or dirty, and after a nonzero one-based fault occurrence counter has begun matching. Checking only the core request-payload count is insufficient because it is zero after application while the overlay remains required. A future snapshot format may add an identity-bound overlay and fault-selector chunk; ABI1.3 does not silently extend CDRSNAP1.

Fault selection and failures

Fault selection is deterministic and identical in C and JavaScript. A selector is (operation or any, first block or any, one-based matching occurrence or every); the action mask may force host failure, flip the first completion byte, or delay one guest tick.

All of the following are hard gate failures:

• wrong base size/hash, mutated base, truncated or out-of-range range;
• invalid operation, descriptor, transaction identity, block size, or count;
• unavailable unit, invalid CHS, NXM, unsupported command, or evidence overflow;
• short/wrong-hash completion, host failure, stale/duplicate/wrong completion;
• request identity drift, apply without accepted delivery, or issue while another request remains outstanding;
• page hash disagreement, comparison mismatch in the successful profile, overlay generation/root disagreement, or an unexpected write;
• missing/reordered/extra selected transfer, missing first 0405 START, terminal before the three transfers, missing/duplicate terminal, or a disk event after the terminal during the quiet suffix;
• malformed, truncated, noncanonical, or hash-invalid evidence.

The controller may record its final error transition, but a failed gate MUST NOT emit a successful controller footer.

Evidence formats

Conformance matrix

The successful selected gate additionally requires:

• three controller requests with commands/LBAs/directions 011/1/write, 010/1/compare, 000/0/read;
• raw CCW address 511 and value zero for all three;
• write and comparison page SHA-256 5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef;
• LBA-0 page SHA-256 2002734fa44f32c7f74fc00bdee9f8ef1021a84a073bad86d814e30d7e03dc79;
• four interrupt-deassert attempts in the independently observed source profile;
• overlay generation one and unchanged base SHA-256;
• final CDRSTATE4 equality and no host work.

Release record

The closure record MUST state exact commands, compiler/Node/browser versions, native and Wasm artifact hashes, all transcript hashes, upstream prepared-source and instrumentation hashes, repeat identities, base pre/post identity, and the Git commit. It MUST distinguish a static unit pass, a native/Wasm differential pass, the independently rebuilt upstream oracle, and a live browser pass.

The locally observed upstream repeat after the CDRM4USIM1 schema rename produced 59 raw events and three chains in both runs. Raw streams were 23,182 bytes with SHA-256 aad0a1bcf3e40c5ba6d400b61ee3b6f8b076ba2d2b1b4895a81fff9e34908135; normalized streams were 23,536 bytes with SHA-256 e8b2b8921defabdd6a30c4ef0252cb71ef38612ccb99ab3c6311867abf1c583b. Both the input and disposable copy retained the selected base identity. These are local runtime observations from ignored build trees, not redistributed media.

The real-Chromium M4 test is intentionally a host-adapter smoke. It instantiates the M4 worker, exercises the empty disk-evidence and premature-CDRSTATE4 paths, then uses a synthetic two-block range source to test commit, exact replay, older-generation rejection, and overlay-shadowed read. The selected 269,562,880-byte disk boot remains the Node-worker/native differential gate; this browser smoke is not represented as a second full boot oracle.

CADR_M4_USIM_ORACLE="$PWD/build/cadr-oracle/m4-usim1-schema-repeat-a/media.cdrm4usim1.ndjson" \
  make -C cadr-web m4-differential
make -C cadr-web m3-snapshot-cross-target
make -C cadr-web m3-differential
scripts/run-cadr-m4-portability.sh
make -C cadr-web test
python3 .agents/skills/write-reimplementation-specs/scripts/audit_spec.py \
  docs/mit-cadr/cadr-boot-media-controller-reimplementation-specification.md

Open extensions

• CADR-WEB-303-LMFS-OVERLAY must specify arbitrary filesystem writes, pack incarnation and clean flags, mount ordering, and persistence separately.
• A future snapshot minor may own an overlay chunk and attachment identity.
• Nonzero deterministic latency profiles require separate release evidence.
• Other disk units, geometries, commands, and historical release profiles remain unselected.

Sources

• Maintained LM-3 System check-in 4df393c6 and maintained usim check-in 330d8248, verified 2026-07-29.
• Public System 46 source snapshot at commit 8e978d7d for historical comparison, not merged into the System 303 profile.
• Repository implementations and tests under cadr-web/core/, cadr-web/host/, cadr-web/wasm/, cadr-web/tests/, and tests/.
• CADR browser/WebAssembly implementation roadmap.
• CADR-WEB headless core specification.
• Deterministic trace and snapshot specification.