You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
UCI PRG load writes zeros through $D000-$DFFF I/O on KERNAL LOAD (possible cause of the TDE .d64 'never completes') #288
The UCI PRGs are file-padded through $FDFF. A KERNAL LOAD (a real drive, or the Ultimate's emulated 1541 used through LOAD rather than DMA "Run") therefore writes zero bytes through $D000-$DFFF. Those bytes land in the I/O registers (VIC, SID, CIA1, CIA2, and $DE/$DF, which includes the UCI registers), not in RAM.
Measured (link only, master 75dd519)
The UCI PRG is 62,977 B, running $0801→$FDFF. That needs OVERLAY_FILE_PAD (cfg/c64-https-uci.cfg:181, fill = yes, $C000-$DFFF; on comb cfg/c64-https-uci-onchip-cold.cfg:249, $D000-$DFFF) and the file-backed OVERLAY_BLOB_CURVE_RAM at $E000 (:187 / :258).
The cfg comment at cfg/c64-https-uci.cfg:176-180 already names the hazard ("the PRG load WOULD momentarily corrupt VIC / SID / CIA registers"). It dismisses it because production targets are VICE warp and U64 fast-load, which inject bytes directly into RAM.
ip65 is not affected: its file image ends at $BFFF (cfg/c64-https-ip65.cfg), and its $E000 region has size 0.
Hypothesis (NOT verified)
docs/engineering-notes.md:2818 and tools/package/verify_release.py:205 record that a .d64 boot under VICE true drive emulation "never completes inside any sane budget", which is why verify_release.py uses -trapdevice8 +drive8truedrive.
That was attributed to slowness. But about 250 blocks at stock 1541 speed should take a few minutes, not "never". Zeroing CIA2 ($DD00/$DD02, the serial-bus port and its DDR) partway through a serial load would hang the load in exactly that way.
If the hypothesis is right, the shipped UCI .d64s cannot be LOADed through the KERNAL at all, and only DMA "Run" works.
Suggested check
Boot dist/c64-https-uci-onchip.d64 in VICE with true drive emulation (no traps) and a long budget.
Note whether the load hangs once the load address passes $D000. The harness can read the current load pointer at $AE/$AF.
If it does, fix it. One option: stage the $E000 payload below $C000 in the file and copy it at boot, so the file ends before $D000.
Found during the ML-KEM placement spike (the PQ_HYBRID P0 branch); the hazard predates that work.
Activity
curve refusal: test the scheme gate itself; run on the store builds; …
Merge pull request #295 from JC-000/fix/288-drop-trailing-pad
Merge pull request #298 from JC-000/fix/288-drop-trailing-pad
PQC P0: pin libs/mlkem v0.6.0 and place it behind PQ_HYBRID=1
PQC P0: ML-KEM loads at $A000, boot copies it to $E000; pq_mlkem_call…