rom.ports: first divergence with field ports at unlisted sites (multi-frame Decompress loop JP, E9 meter US) #45
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found while validating PR #35 (field batch 1, all field ports on) with the classified
rom.portsreport of #34 (release, field-batch1 after merging main7877fde). Report only; the test passes.JP: FINDING (unlisted site)
$C2:FFB5(JP) isDecompress_ext+$48(src/btlgfx/decomp.asm, the bit-counter loopdec $fe / lsr $ff). The decompressor runs on the main thread across several frames, so both cores can end a frame at the same PC and S while one is further in the loop:$FEis its bit counter. This is a multi-frame loader case the census (workdocs/timing-census.md §5.2) does not list. It also shows a limit of the comparison: "same PC and S" does not mean "same progress" inside a long main-thread loop, so the memory difference is not necessarily a divergence of game state.US: classified by PC, but the real site is E9
$0630-$0632is the write-only CPU meter ofFieldLoop(census E9, never read). The site table intests/rom/test_rom_ports.chas no E9 WRAM entry, so the classification falls back on the PC (E5), which is incidental.Proposed
$0630-$0632, write-only beam meter) to the census sites oftest_rom_ports.c(or declare it don't-care in the comparison).$C2:FF6D/JP via ff6sym, and others to list) to the census and the site table, or compare memories only when both cores are waiting for a frame (same wait PC), not in the middle of a loader.battle/Randon (main), the first divergence is E8 on both versions (sound driver$131E), no finding.