Skip to content

m3 demo README: name the PRG the figures were measured with; upstream #952 - #300

Merged
JC-000 merged 11 commits into
masterfrom
docs/m3-demo-readme-provenance
Oct 15, 2026
Merged

m3 demo README: name the PRG the figures were measured with; upstream #952#300
JC-000 merged 11 commits into
masterfrom
docs/m3-demo-readme-provenance

Conversation

@JC-000

@JC-000 JC-000 commented Oct 15, 2026 •
edited
Loading

Copy link
Copy Markdown
Owner

Note

Merge conditions: met (2026-10-15). Both were verified independently by the lane lead and by this lane:

  1. The prerelease https://github.com/JC-000/1541ultimate/releases/tag/tls-preview-f3df8261 is live and marked pre-release. Its tag is a commit ref to f3df8261b59ea5883cc5b6d9bb1eb4c79f8f0fd4. The asset update_tls_f3df8261.u64 is 5,779,464 B with sha256 15e9ff7cd8a11daf1f4698d574480381d475db7754e1d276d9aa95e8013ded3c, which equals FIRMWARE_IMAGE_SHA (lead: downloaded and hashed; this lane: the release asset's recorded digest).
  2. TLS client sockets for the Ultimate 64 through its ESP32: a 5-PR series, and coordinating with the other TLS work GideonZ/1541ultimate#952's body now links pr/3-tls-r1 (f3df8261) in place of esp32-tls-offload, so the README's "Not upstream; proposed on TLS client sockets for the Ultimate 64 through its ESP32: a 5-PR series, and coordinating with the other TLS work GideonZ/1541ultimate#952" is accurate.

What

tools/package/build_m3_demo.sh writes the README for the M3 demo disk. That README said "Measured with THIS image" for a PRG that had never run, and the template's firmware and upstream lines were placeholders. This PR changes the template only: the PRG and .d64 are byte-identical to master's (916d41628a17b9436bbf58a71f7350c721a06e459cf5c33e5baeb1ad61af9a24, ae2cc5b7d40190ddfc911cb40e7a7d62e406c134f304b3fe9e2f04ea540ff498).

Head 6d6e750 records the 2026-10-15 hardware window. It ran this exact PRG, built from daaef33, on the U64E with firmware image update_tls_f3df8261.u64. That image has sha256 15e9ff7cd8a11daf1f4698d574480381d475db7754e1d276d9aa95e8013ded3c and reports git f3df8261 in /v1/info, plus ESP module 1.8 in the client-side INFO record. A build of this commit therefore says "Measured with THIS image".

  • Hash-gated provenance. The template has new constants: MEASURED_PRG_SHA (now 916d4162…), MEASURED_COMMIT (now daaef33, "the merge of uci: unfence UCI register reads in the 6510 products (wiki 375->175 s onchip, 364->163 s comb on U64E); UCI_READ_FENCE=1 restores them #299") and MEASURED_BUILT ("daaef33 on 2026-10-14").

    • If the built PRG matches, the README says "Measured with THIS image".
    • Otherwise it says "NOT measured with this image" and names the measured PRG, commit and build. It then reports whether the M3 adapter's sources changed since MEASURED_COMMIT. "The adapter's sources" are everything under src/net/uci-m3/ (git ls-files, plus the directory as a pathspec), every file in build/net/uci-m3/*.d, and cfg/c64-https-uci-m3.cfg: 13 files. The result is "unchanged since", "changed since … ", or "unknown here".

  • Firmware. FIRMWARE is the firmware side's agreed one-liner: "TLS client sockets for the Ultimate 64 / U64 Elite, from JC-000/1541ultimate branch pr/3-tls-r1 (f3df8261), prebuilt image in prerelease tls-preview-f3df8261. Not upstream; proposed on TLS client sockets for the Ultimate 64 through its ESP32: a 5-PR series, and coordinating with the other TLS work GideonZ/1541ultimate#952." It is followed by:

    All of these are plain constants, so the README is a function of the commit.

  • Upstream status (the UPSTREAM_PRS constant, with no env override): "not upstream yet. TLS client sockets for the Ultimate 64 through its ESP32: a 5-PR series, and coordinating with the other TLS work GideonZ/1541ultimate#952 is the proposal issue; this demo follows its proposed command numbering ($21/$23/$25). No upstream PR implements these commands yet (Add NET_CMD_GET_RANDOM: hardware random bytes for C64 programs GideonZ/1541ultimate#953 adds GET_RANDOM only)."

  • Runs. For this image: "The run recorded for this image is the one under "Measured" below." Then "Earlier demo images were validated on the non-public builds esp-tls/m3 f2e46946 and esp-tls/m3-master 3a1ff9ff", taken from this script's own history.

  • Measured (2026-10-15, U64E, f3df8261 / ESP 1.8, 48 MHz, REU disabled). URLs 1-3 used the .d64 from drive 8 (rig_https_m3_demo.py):

    • wiki: 759,171 B == Content-Length, 20 s.
    • github robots.txt: 16,739 B, 5 s.
    • nip.io: refused with 94,CERTIFICATE NAME MISMATCH: 0x00000004.
    • New URL 4, badssl.com (TLS 1.2 only): refused with 14,TLS ALERT RECEIVED: 40 and the client's THE SERVER DOES NOT DO TLS 1.3. This one was measured with the same PRG written over REST (rig_https_m3.py refuse), and the README says so.

  • The 1 MHz figure now comes from the window: "17.5 s from G to the whole body at 1 MHz (turbo off), handshake done at 5.8 s (sink build 146647e4, firmware f3df8261, 2026-10-15)". The 6 s at 48 MHz is kept and attributed: "6 s from G at 48 MHz (esp-tls/m3-master 3a1ff9ff, 2026-10-13)". Both rig timings start from the same t0 at G (rig_https_m3.py, timed_attempt), so the handshake time is inside the 17.5 s, not added to it. 937718b's wording ("body … after a 5.8 s handshake") was wrong and is corrected in 6d6e750. The trace build's 6.55 s is not used, since that is a different (M3_TRACE) PRG.

  • Firmware URLs and the image sha256 sit on their own lines, so every line this PR adds is at most 80 columns. The only README lines over 80 are ones master already has: the make/CA65FLAGS/toolchain provenance lines and the SPEC line.

  • "The same client source" becomes "The same M3 adapter".

Checked against GitHub:

Evidence

Hardware window, 2026-10-15 06:10-06:40, U64E 10.43.23.81. Every run took its own DeviceLock and gated on /v1/info git == f3df8261. Raw logs are kept by the lane.

run PRG result
C1 916d4162 INFO record at boot, I and I: ver 1, max 2, in_use 0, trust 07, ready 07, versions 03, module 1.8, date FF FF FF
C2 (demo .d64, drive 8) 916d4162 wiki HTTP 200, 759,171 B == CL, 20 s; github 16,739 B, 5 s; nip.io 94 refused, m3_owned 0, $8D
C5a (rig_https_m3.py refuse badssl.com 14) 916d4162 14,TLS ALERT RECEIVED: 40 plus the no-TLS-1.3 hint, m3_owned 0, $8D
C4 v3 (I×2, 3 fetches, I, fetch) 916d4162 PASS. All 4 fetches HTTP 200, 16,739 B, net_last_error $00; pre-open INFO in_use 0 before every Open, so no leaked session
C4 v1, v2 916d4162 Not passes: they are aborted by detector bugs in the lane's one-off script. v1's screen anchor wrapped at 40 columns, and v2 compared screens that were byte-identical after a repeated fetch. In both, the fetches on screen ended CONNECTION CLOSED and the socket guard confirmed it before Q. v2's fetch 3 has screen evidence only (net_last_error, m3_owned, the $DF1F line and the byte count were not captured), so it is INCONCLUSIVE. v3 starts the wait from a memory sentinel and is the result that counts

Build evidence at 2cb2d51, re-confirmed at 937718b and 6d6e750. All make package-m3-demo runs exit 0 with PRG 916d4162.

run README
RED: origin/master daaef33 Measured with THIS image for figures taken on 24a81766 / 3a1ff9ff; [TO BE FILLED IN …] upstream slot
GREEN: 2cb2d51 → 566c4bc (1 MHz line) → 937718b (wrapping) → 6d6e750 (timing from G): PRG 916d4162 and .d64 ae2cc5b7 each time Measured with THIS image (PRG sha256 above), validated on an Ultimate 64 Elite (U64E), firmware 3.15 git f3df8261 (the image above, ESP module 1.8), 48 MHz, REU disabled, 2026-10-15; firmware/source/prebuilt/sha lines as above; no NOTE in the log
probe-else: 2cb2d51 + MEASURED_PRG_SHA=0…0 (throwaway, unpushed) NOT measured with this image … reproducible from commit daaef33… (the merge of JC-000/c64-https#299); … built from daaef33 on 2026-10-14 (the M3 adapter's 13 source files … are unchanged since). The adapter list against daaef33 is empty, as expected: git diff --name-only daaef33 HEAD is only tools/package/build_m3_demo.sh

Earlier gate red-greens, at c79aac5 and before, all still hold:

  • A m3_https_get.inc edit flips the gate to "changed: src/net/uci-m3/m3_https_get.inc".
  • A uci_regs.inc UCI_FENCE_INNER edit flips it to "changed: src/net/uci/uci_regs.inc".
  • An absent commit gives "unknown here".
  • The UPSTREAM_PRS env var has no effect (README byte-identical).

bash -n passes under 5.3 and /bin/bash 3.2.

Not covered

  • C3 (1 MHz) and C7 (per-READ trace) also passed in the window, but on REU-sink builds (146647e4…, 2a23944f…), not this image. They are not in the README.
  • Long lines remain only where master already has them (build provenance, SPEC).

🤖 Generated with Claude Code

JC-000 and others added 11 commits October 14, 2026 20:31
@JC-000 @claude
m3 demo README: name the PRG the figures were measured with; upstream…
25044bd 
… #952

The "Measured with THIS image" sentence was carried over to PRG 916d4162
(#294 moved the image 20 B) although the 2026-10-13 run used 24a81766.
It is now said only when the built PRG's sha256 equals MEASURED_PRG_SHA;
otherwise the README names the measured PRG and commit, and says from git
whether src/net/uci-m3/ changed since.

Also: the upstream reference defaults to GideonZ/1541ultimate#952 (a plain
make package-m3-demo is reproducible without UPSTREAM_PRS), the README says
no demo image has run on that PR's firmware yet, and "same client source"
becomes "same M3 adapter".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: upstream status as it is (#952 is the issue, no PR ye…
902ce8d 
…t); measured-image provenance

adv-296 on #300: #952 is the proposal issue and links no draft PR, no
upstream PR implements $21/$23/$25 yet (#953 is GET_RANDOM only), and
esp-tls/m3-master is not public. The default upstream status now says so,
UPSTREAM_PRS still overrides it, and UPSTREAM_RUN no longer presupposes an
upstream build. The NOT-measured branch says the measured PRG is
reproducible from 71b047e (the merge of #296) and was built from 9eabd50
on 2026-10-13, and that with the adapter unchanged the PRG differs only by
changes outside it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: firmware source and image sha as their own constants
19094e6 
The window image is built from pr/3-tls-r1 f3df8261, which may later be
pushed to a public branch with the image attached. FIRMWARE_SOURCE ("not
yet public, and not upstream" for now) and FIRMWARE_IMAGE_SHA (its line
printed only when set) let one later commit swap in the URL and sha
without touching the upstream-status text.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: public source branch, earlier runs scoped, adapter ga…
13ded5f 
…te over its include closure

adv-296 round 2 on #300:
- The source for $20-$25 IS public: JC-000/1541ultimate esp32-tls-offload
  (tip 72f33796, network_target.h defines $20-$25, the 90-94 lines are in
  network_target.cc), linked from GideonZ/1541ultimate#952. FIRMWARE_SOURCE
  says so, that the demo has not run on a build of it, and the upstream
  status says not upstream (GideonZ/1541ultimate#953 is GET_RANDOM only).
- 'No demo image has been run on any firmware but the build named above'
  was false: the script's own history validated earlier images on
  esp-tls/m3 f2e46946. The line is now per-image (none recorded for a
  non-measured PRG) plus EARLIER_RUNS.
- The adapter gate diffed src/net/uci-m3 only, so a change to
  src/net/uci/uci_regs.inc (uci_fence) moved the PRG and the README still
  said 'unchanged'. It now diffs every file in build/net/uci-m3/*.d plus
  cfg/c64-https-uci-m3.cfg, and names the files that changed.
- #296, not #296.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: wrap the two new long lines
dbc872b 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: firmware source is the public pr/3-tls-r1 branch; UPS…
955b726 
…TREAM_PRS a constant

- FIRMWARE_SOURCE points at JC-000/1541ultimate pr/3-tls-r1 (f3df8261),
  the branch that will be proposed (not the older esp32-tls-offload): not
  upstream, proposed on GideonZ/1541ultimate#952, and this demo image has
  not been run on a build of it. The prerelease link and image sha are for
  the post-window commit.
- UPSTREAM_PRS loses its env override (adv-296 finding 5): it replaced the
  whole upstream paragraph without a trace, so the README was not a
  function of the commit.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: adapter gate covers all of src/net/uci-m3/; one chang…
c79aac5 
…ed file per line

adv-296 on #300 at 955b726:
- src/net/uci-m3/m3_https_get.inc and net_tuning.inc are included from
  boot.s/exports.s, not from the adapter's objects, so the .d closure
  missed them: an edit there left the README saying 'unchanged'. The
  pathspec is now src/net/uci-m3/ (git ls-files, and the directory as a
  pathspec for deletions) + the .d closure + the cfg.
- The changed-files list is one file per line (it ran past 80 columns).
- FIRMWARE_SOURCE: 'the series it implements is proposed on
  GideonZ/1541ultimate#952' (#952 does not name pr/3-tls-r1).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: post-window figures on pr/3-tls-r1 f3df8261 (ESP 1.8)
2cb2d51 
The 2026-10-15 window ran this demo image, PRG 916d4162 (built from
daaef33), on the U64E with firmware image update_tls_f3df8261.u64
(sha256 15e9ff7c..., git f3df8261, ESP module 1.8), REU disabled, 48 MHz:
wiki 759,171 B == Content-Length in 20 s, github robots.txt 16,739 B in
5 s, the nip.io name mismatch refused with 94, badssl.com (TLS 1.2 only)
refused with 14/40 and the no-TLS-1.3 hint.

- MEASURED_* now name that PRG and daaef33, so a build of this commit
  says 'Measured with THIS image'.
- FIRMWARE is the firmware side's agreed one-liner; the source branch,
  the prerelease and the image sha256 follow it.
- badssl.com joins the URLs to try, as the TLS 1.2 negative.

The prerelease tls-preview-f3df8261 is not published yet.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: 1 MHz figure from the 2026-10-15 window, 48 MHz figur…
566c4bc 
…e attributed

adv-296 at 2cb2d51: the 16 s at 1 MHz came from the 2026-10-13 run on
3a1ff9ff. It is now the window's figure, body 17.5 s after a 5.8 s
handshake (sink build 146647e4, firmware f3df8261), and the 6 s at
48 MHz names the build it was measured on (3a1ff9ff, 2026-10-13). The
trace build's 6.55 s is not used.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: firmware URLs and image sha256 on their own lines (<=…
937718b 
… 80 columns)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000 @claude
m3 demo README: the 1 MHz figure is from G (the handshake is inside it)
6d6e750 
adv-296 at 937718b: rig_https_m3.py times t_body and t_handshake from the
same t0 at G, so 17.5 s is G to the whole body with the handshake done at
5.8 s, not body after handshake.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@JC-000
JC-000 marked this pull request as ready for review October 15, 2026 12:48
@JC-000
JC-000 merged commit ded2247 into master Oct 15, 2026
@JC-000
JC-000 deleted the docs/m3-demo-readme-provenance branch October 15, 2026 12:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@JC-000