Skip to content

UCI PRG load writes zeros through $D000-$DFFF I/O on KERNAL LOAD (possible cause of the TDE .d64 'never completes') #288

Closed

Description

@JC-000

Summary

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

  1. Boot dist/c64-https-uci-onchip.d64 in VICE with true drive emulation (no traps) and a long budget.
  2. Note whether the load hangs once the load address passes $D000. The harness can read the current load pointer at $AE/$AF.
  3. 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.

🤖 Generated with Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions