mirror of
https://github.com/RetroPortingToolKit/psxrecomp
synced 2026-10-26 02:11:36 -04:00
Matthew Stanley
ba33564dc5
DMA-to-RAM writes were captured (all dma.c writes route through psx_write_word -> the wtrace/parity hooks), but with misleading provenance: `pc`/`ra` came from g_debug_last_store_pc, i.e. whatever CPU store ran last — meaningless mid-DMA, and worse for async channels whose RAM writes run frames after the kick. There was no way to tell a DMA write from a CPU store, or which channel produced it. Fix (framework-level, all channels): - dma.c: capture the DMA kick PC (the CHCR store) into g_dma_initiator_pc at trigger, stash per-channel, and re-publish it for the async channels whose RAM writes run in a deferred advance step (CDROM ch3; MDEC-out ch1, which also lacked the g_dma_exec_depth marking entirely and is now wrapped like CDROM). - debug_server.c: WriteTraceEntry gains dma_ch (0-6, or -1 = CPU store); when a DMA is in flight, the entry's pc is the kick PC, not the stale store PC. Emitted as "dma_ch" in wtrace_dump. - memory.c: parity note_write uses effective_store_pc() (kick PC during DMA). Verified on MMX5: CD-streamed font buffer fills (0x800D5208) now tag dma_ch=3 with pc=0x80067264 (the CD loader kick); BIOS scratch CPU stores tag dma_ch=-1. This is what let write-provenance see the font buffer's clear->CD-load->clear cycle and localize the upload-races-the-load bug. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>