[JC-000]

What

make package-m3-demo builds a "just run it" disk for the BACKEND=uci-m3 variant (#271): TLS runs on the Ultimate's ESP32, and the C64 speaks HTTP. It writes four files to dist/m3-demo/, the release assets:

• c64-https-uci-m3-demo.prg: 6,519 B, sha256 e4814599c783aeefe03d37b194debc067c18afff3589069a97af8630edb34e24. Default target en.wikipedia.org /wiki/Commodore_64; host and path can be typed.
• c64-https-uci-m3-demo.d64: sha256 28a8741fe7cb0b152901a24634e440a548380a41b710f1e15ead7959d00f98ba. It holds that PRG alone, as c64-https-m3.
• README.txt: provenance (commit, make line, flags, toolchain path + sha256), what it needs, how to run it, three test URLs, and measured results.
  • Firmware line: "M3-SPEC v1 + errata v1.1/v1.2 firmware (validated on esp-tls/m3-master 3a1ff9ff: fw 3.15, FPGA 126, ESP 1.309)", with a marked slot for the 1541ultimate upstream PR number(s).
• SHA256SUMS: sha256 of the other three files.

Scope: PACKAGE_VARIANTS, make package and the shipped products are untouched. No release or tag was created.

The build script (tools/package/build_m3_demo.sh)

• Refuses a dirty tree, untracked files included. The README names a commit, so the PRG must be what that commit builds.
  • Red: the old git diff --quiet HEAD check exits 0 with only an untracked src/stray.s present.
  • Green: the script dies listing ?? src/stray.s.
• Builds in a scrubbed environment (env -i PATH HOME TMPDIR), so neither an exported knob nor one passed on the make package-m3-demo VAR=… command line (it arrives through MAKEFLAGS) reaches the demo build. It then asserts build/flags.stamp: BACKEND=uci-m3, -C cfg/c64-https-uci-m3.cfg, exactly -D BACKEND_UCI=1 -D BACKEND_UCI_M3=1, and the demo target in https_host.inc.
  • Red: make package-m3-demo HTTPS_PORT=8443 built PRG 217e043e with -D HTTPS_PORT=8443 in the README.
  • Green: the same command now gives the clean hash. A mutant without env -i dies on "unexpected defines: … -D HTTPS_PORT=8443".
• Records the toolchain: the README carries flags.stamp's TOOLCHAIN line (path + sha256 of ca65/ar65/ld65).
  • Red: a ca65 shim on PATH built PRG 217e043e behind a silent README.
  • Green: the same shim is now named in the README.
• Proves its own output: two clean builds must give identical PRG bytes, and c1541 reads the PRG back out of the .d64 byte for byte. C1541= overrides the tool, in the script and the rig.

Rigs

• tools/uci/rig_https_m3_demo.py mounts the .d64 on drive A, runs LOAD"*",8,1 / RUN, then fetches three targets:
  • the default target: HTTP 200, complete by its own framing;
  • github.com /robots.txt: HTTP 200, complete;
  • a name-mismatch host, judged by rig_https_m3.verdict_refuse (94 on screen, $8D, no handle, no REQUEST SENT), using only rows after its own banner.
• Shared fix in both M3 rigs: waits no longer count stale screen text.
  • The boot prints "DHCP OK" before the menu, so after 'I' the old wait returned at once, and a re-init that then failed read as a pass. press_init now counts only text after the menu line and needs the finished address, read the same twice.
  • wait_after no longer falls back to the whole screen, and the demo waits for each fetch's banner first. Before, the previous fetch's CONNECTION CLOSED could end a wait and skip the UCI rigs release the DeviceLock over a live firmware socket on an abnormal exit (exception / Ctrl-C) — next lane's reset poisons the lease #234 socket teardown.
  • Red: adv-m3demo/race_wait_after.log (it returns on poll 1).
• Drive A is restored and checked against what was read:
  • the old image is re-mounted by path (fw 3.15 reports it whole in image_file);
  • the drive is switched back off if it was off, including when our mount failed after drive_on;
  • our own /Temp/cache/upload/image[_N].d64 upload is deleted over FTP, last, with ftplib.all_errors caught.
  • Red: adv-m3demo/delete_aborts_restore.log. An FTP 421 escaped the delete, which ran first, leaving calls == ['unmount']: the operator's disk not re-mounted and the drive left on.
• Per-run artifact dir: both M3 rigs pass _create_run_dir(...), not the base dir.
• Device prep for uci-m3 (_reu_preflight.py, _device_prep.py). A uci-m3 build was classified as REU-profile, so prep ENABLED a 16 MB REU, though the README says "No REU".
  • It is now profile "none": m3_owned present, viewer_enter absent, and no nistcurves equate (which stays authoritative).
  • For "none", prep sets the REU Disabled. An unreadable state writes anyway; a refused write is exit 4. The preflight makes no device call.
  • An M3 build with HTTPS_BODY_TO_REU=1 (it links the viewer) still classifies reu.
  • Red: the new tests fail against the old modules, 5 of 6 plus the body-sink case.
• rig_https_m3 ab refuses a B that is not on-chip. The device is prepared for A, which now runs with the REU off. Red by code reading: the previous rig never classified argv[5].
• tools/test_device_prep.py: the demo rig (it boots from the drive, so the discovery rule cannot see it) is registered by name; rig_https_m3.py is now discovered.
  • Red/green on master with UCI trust policy: build pin > signed bundle > TOFU (#155 phase 2, L3) #268: a demo rig with prepare_device removed gives 34 passed, 1 failed when registered, but 35/0 when unregistered (the old blind spot). Clean: 35/0.

Acceptance (head b54fcb6, on master 489efd0)

• make package-m3-demo: PRG e4814599…, .d64 28a8741f…, shasum -c SHA256SUMS OK. The bytes are identical to the build on the c26e268 base, where the hardware ran.
• check_m3_client.py: 50/50, 335 assertions.
• mutate_m3_client.py: 62 mutants, 62 killed. No M3 check tool or uci-m3 source changed between c26e268 and 489efd0.
• test_device_prep + test_reu_preflight + test_rig_skip_contract: 63 passed.
• uci-m3 margin (demo target): MAIN $0801-$9FFF, last used $2175, 32,394 B free.

Hardware

U64E fw 3.15 git 3a1ff9ff, FPGA 126, core 1.50; 48 MHz; DeviceLock; PRG e4814599, .d64 28a8741f. Both runs had the REU Disabled by device prep (device_state.json in each per-run dir: profile none, wanted Disabled, REU Enabled → Disabled).

• Mounted .d64 (rig_https_m3_demo.py, 2026-10-06): PASS.
  • Wikipedia: HTTP 200, 751,848 B, complete (chunked), 207 s.
  • github /robots.txt: HTTP 200, 16,739 B == Content-Length, 9 s.
  • nip.io name mismatch: 94,CERTIFICATE NAME MISMATCH: 0x00000004, $8D, m3_owned=0.
  • Drive A restored exactly; the rig printed deleted /Temp/cache/upload/image.d64.
• rig_https_banner.py: PASS. The banner names EN.WIKIPEDIA.ORG; HTTP 200, 751,848 B == Content-Length; the fetch had settled when its state was read.

🤖 Generated with Claude Code