Three prebuilt products, one disk each. No assembler, no cc65, no Python packages, no build step.
Which one do I want?
| image | for | |
|---|---|---|
c64-https-ip65-onchip |
bone-stock C64 + RR-Net cartridge | maximum compatibility — no REU, no turbo, nothing optional. If you are unsure what you have, this is the one that runs. ~36 min per handshake at 1 MHz. |
c64-https-uci-onchip |
Ultimate 64 / C64 Ultimate at turbo, REU off | boots straight to the menu |
c64-https-uci-comb |
Ultimate 64 / C64 Ultimate at turbo, REU on | fastest — 1.73x quicker verify (16.4 s vs 28.4 s, U64E at 48 MHz). Builds a 16 KB table into REU bank 2 at each boot first: ~34 s at 64 MHz, ~45 s at 48 MHz. |
MANIFEST.txt walks through the choice, and c64-https-listener.py is a single self-extracting file that stands up the server side — it mints its own certificate and needs only a python3 whose ssl has TLS 1.3.
New: the comb profile ships
uci-comb is new, and it is the first configuration whose handshake lands where a normal internet server will still be waiting. It needs an REU (bank 2, for the Lim-Lee comb table) and turbo — below about 5 MHz the plain REU multiply path is faster, so this is strictly a turbo product.
The two REU-profile images (uci-reu, ip65-reu) are retired from the lineup. They remain buildable and are still the fastest choice below ~18 MHz. The cost falls on a stock C64 with an REU, which now gets ip65-onchip at ~1,820 s per handshake where ip65-reu would have done ~1,082 s at 1 MHz. That is a curation decision, not a measurement one — restoring it is one line in PACKAGE_VARIANTS.
Per-backend combo disks are gone: three UCI variants are 744 blocks against a .d64's 664, so a combo image would have had to silently omit a product. One variant per disk means the label is the whole contents.
New: the screen blanks during the slow crypto
Every image now blanks the VIC-II across the two X25519 scalar multiplies and the ECDSA verify. The progress line returns between handshake phases, so a blank screen for minutes at a time is the crypto running, not a hang.
It is worth ~6.3%, not the ~20-25% this project previously claimed — a figure that turned out to be wrong by about 3.5x and has been corrected here and upstream in both crypto libraries. Measured four ways that agree:
6.31% first principles (25 badlines x ~43 cyc / 17,045-cyc NTSC frame)
6.35% VICE, 1 MHz, x25519
6.60% U64E, 48 MHz, REU profile n=3
6.78% U64E, 48 MHz, on-chip profile n=3
Two predictions failed on the way: turbo does not shrink the tax (it is flat across a 48x clock range), and the REU profile's DMA floor does not dilute it. Badline DMA taxes the bus, not the CPU — REU DMA pays it too.
Contract alignment
Pins move to libs/nistcurves v0.11.2 and libs/x25519 v0.11.2, read against c64-lib-contract v0.10.6.
c64-https no longer edits any archive member set — SPEC §6.1 is satisfied by construction, since the archive linked is byte-for-byte the one upstream's make produces. The §8.0 shape is requested through CONTRACT_DEFINES instead, so the manifest attests the deferral and the §8.0 disjointness and coverage asserts are live for the first time.
§13 (network backend ABI) remains the one open gap, tracked at #70.
Verification
- ECDSA KAT oracle 6/6 on the REU, on-chip and comb builds — 3 valid accepted, 3 invalid rejected on each
make package-verify: 31/31 gate logic tests, 11/11 artifact checks, no skips — every PRG rebuilt and hash-compared, every disk read back withc1541and byte-compared, every image booted in VICE, listener selftest run in a clean temp dir- built from a clean checkout of
masterwith committed submodule pins
For demonstration and educational purposes — not cryptographically secure.