将《测试驾驶II》从超级任天堂移植到个人电脑，第三部分：以溯源取代截图

一旦 SDL 运行时能够播放真实的开场路径，下一个瓶颈就不再是渲染问题，而是证据问题。

如果某一帧画面看起来接近，这已不再足够。项目需要回答更难的问题：

• 哪一段 ROM 数据生成了当前可见的图块地图？
• 使用该数据段时，激活的是哪条回调路径？
• 这一帧是否来自一个稳定的源窗口，还是仅仅是一张碰巧今天匹配的截图？

这一阶段始于三月五日，并主导了代码仓库直至三月十七日。

代码仓库新增了一个专门的考古工作区

2026年3月5日的提交 6a12991 添加了 rom_analysis/ 工作区，以及大量如今定义项目后半部分的工具：

• build_bank30_chunk_registry.py
• build_mesen_design_pack.py
• build_mesen_design_pack_range.py
• extract_compression_header_manifest.py
• validate_td2_chunks.py
• summarize_l001210_trace.py
• rom_analysis/docs/ 目录下的新路线图和检查点文档

这一结构调整出于两个原因，非常有用。

首先，它将“必须输出画面的运行时代码”与“必须解释画面的分析代码”分离开来。这两者虽有重叠，但并非同一任务。

其次，它明确划出了考古工作通道。代码仓库不再将第10号、第11号和第30号存储区块视为模糊的未来任务，而是开始为它们提供具体的产物、检查点以及通过或失败的判定标准。

L001210 成为主要的溯源钩子

此阶段的核心追踪目标是 L001210，即位于 00:9210 的调度器，它与数据块的使用紧密关联。项目增加了探针侧的追踪功能和汇总工具，从而得以从静态存储区块扫描转向基于运行时的溯源。

该流程如下所示：

make -C tools l001210-probe L001210_PROBE_TOTAL_FRAMES=3600 MESEN_TIMEOUT_SECONDS=90
make -C tools l001210-trace-summary
make -C tools bank30-registry

仅靠存储区块扫描只能告诉你候选压缩数据块的位置，却无法说明哪些数据块在实时画面窗口中真正起作用。L001210 的追踪改变了这一点。

现在，第30号存储区块注册表可以根据解码状态和运行时可见性对候选数据块进行分类。截至当前快照，未解决的队列仍然具体明确：

• 1E:E91F
• 1E:EE7F
• 1E:DA96
• 1E:9681

这比含糊其辞地说“还有一些第30号存储区块的工作尚未完成”要好得多。它提供了一份附带证据的小型未解决数据生产者清单。

设计包使画面数据可在模拟器之外使用

项目也不再将原始的 Mesen 转储视为最终输出格式。

mesen_ppu_extract 工具和设计包构建器将画面窗口转换为可像资源一样检查的数据包，而不再是调试器状态：

• 各图层的可见渲染结果
• 已解码的图块地图
• 图块素材表
• 精灵分析
• 原始 VRAM/CGRAM/OAM 数据
• 单帧或帧范围的稳定清单

这为代码仓库在模拟器内部机制与运行时回放之间建立了一个中间层。移植工作仍可使用原始场景文件，但工程师可以……