DMAgic Enhanced Attic copy: CPU-visible target converged hundreds of milliseconds after trigger return

[novemberist]

We observed two MEGA65 hardware runs in which an Enhanced-DMA copy from
Attic memory to a 1,156-byte Bank-0 target was not yet stable when CPU code
resumed.

The historical run did not capture its exact core revision. Two immediate
CPU CRC passes were different and wrong, and a chained one-byte fill marker
was already visible. A hold-before-wipe diagnostic measured:

after launch	destination CRC	bytes differing
1 ms	$e8d8	1,133
691 ms	$e856	0
2,381 ms	$e856	0

We then repeated the same-size Enhanced Attic-to-Bank-0 transfer while
recording the project's registered core identity git-03b24c6b:

after launch	destination CRC	bytes differing
2 ms	$1490	1,132
714 ms	$e856	0
2,414 ms	$e856	0

In both runs the Attic source was unchanged and no software write or mapping
change occurred between captures. Our local product rule is therefore
content-defined completion with a bounded target-CRC/readback retry;
neither return from the trigger nor a chained marker is accepted as
completion.

Evidence limits: git-03b24c6b is the exact tested project core identity,
not current upstream mega65-core HEAD, and this is not yet a standalone
reduced reproducer. We are not claiming an internal controller mechanism.
The current User Guide still says the CPU pauses until the DMA job is
complete and that no additional wait logic is required.

Does the documented CPU-stall guarantee include draining slow Attic reads
into a CPU-visible target for Enhanced jobs, or is an additional completion
contract required?

[dansanderson]

Yes, the intended behavior is that the DMA copy is complete before the CPU executes the next instruction.

Can you post your test program?