Matthew Stanley 948df06a75 librecomp: auto-increment RSP DMA addresses after each transfer ... Real RSP DMA hardware advances SP_MEM_ADDR and SP_DRAM_ADDR by (length + 1) after each transfer (verified against Ares' n64/rsp/dma.cpp: pbusAddress += 8 / dramAddress += 8 per 8-byte chunk). The runtime's DO_DMA_READ / DO_DMA_WRITE macros didn't replicate this, so any ucode that fires DMAs in a loop without re-writing SP_MEM_ADDR/SP_DRAM_ADDR each iteration would reload the same DMEM region forever. Observed as Pokemon Stadium's aspMain hanging in its dispatch loop: the L_10EC <-> L_11B4 DMA pump (which walks through the audio command stream chunk by chunk on real hardware) collapsed into a tight no-progress cycle. With the auto-increment in place the dispatch makes forward progress and aspMain advances past the hang point. (A downstream UnhandledJumpTarget then surfaces — a separate issue with the recompiler's static indirect-branch-target list, not this layer.) Diff verified via diff_aspmain.py against the standalone Ares oracle. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-05-05 22:16:23 -07:00
..
include/librecomp	librecomp: auto-increment RSP DMA addresses after each transfer	2026-05-05 22:16:23 -07:00
src	Add recomp::Configuration and ultramodern::MessageQueueControl + plumbing (#131)	2026-01-15 20:23:39 -05:00
CMakeLists.txt	Implement displaylist event extension functions for easier game scheduling modifications (#128)	2025-12-12 02:11:14 -05:00