将《极速试驾II》从超级任天堂移植到个人电脑：从反汇编转储到移植工作台

当前的 asmdump 项目源于一个简单的想法：

用 C 语言和 SDL 重新构建《对决：极速试驾II》，打造一个忠实于原作的个人电脑移植版本，但实现方式应基于对游戏行为的测量和资源提取，而非假设反汇编结果已可直接用于逐行翻译。

这一区别塑造了整个项目的走向。

该项目最初并非以游戏玩法移植为目标，而是作为逆向工程的基础起步：包含汇编代码段、只读存储器（ROM）映像、符号覆盖信息，以及一条可行的 ROM 重建路径。这些内容虽具实用性，但尚不足以构成移植平台。当时缺乏确定性的捕获流程、稳定的资源处理管线、验证框架，也未明确界定“原版游戏的行为”与“个人电脑运行时应复现的内容”之间的对应关系。

从项目启动之初，主要开发目标便是改变这一状况。

最初的目标

PORT_PLAN.md 文件中提出的目标至今仍是正确的：

• 使用 C 语言和 SDL 构建一个忠实于原作的个人电脑重制版本
• 将其视为运行时重建，而非直接的汇编到 C 语言的转换
• 基于提取出的内容和已验证的行为驱动实现过程

之所以选择这一方法，是出于实际考量。

反汇编的部分内容已经具备可读性。bank0.asm 中暴露了可识别的重置、非屏蔽中断（NMI）、中断请求（IRQ）以及回调调度逻辑。然而，面向游戏玩法的代码段尚未达到可直接进行反编译并快速产出可发布成果的程度：

• bank10.asm 和 bank11.asm 仍严重混合了代码与数据
• bank30.asm 的行为更类似于结构化的分发机制和内容表，而非一组清晰隔离的函数
• 符号文件仅提供地址覆盖信息，而非架构层面的理解

因此，项目采取了以下工作策略：

1. 使原始 ROM 具备可测量性
2. 从中提取类型化的资源和逐帧状态产物
3. 基于这些产物构建原生的个人电脑运行时环境
4. 仅在必要时进行深度逆向工程，以用原生系统替代采样回放

这便是本代码仓库的核心理念，其余一切均由此衍生而来。

“可测量性”在实践中的含义

首个真正意义上的里程碑并非游戏玩法代码，而是一个参考验证框架。

项目引入了基于 Mesen 模拟器的确定性工作流，用于：

• 逐帧转储
• 输入日志记录
• 视频随机存取存储器（VRAM）、色彩图形随机存取存储器（CGRAM）及对象属性存储器（OAM）的捕获
• 图像处理单元（PPU）状态导出
• 启动过程及回调选择器的追踪

此举使项目从“我能检查 ROM”转变为“我能在受控条件下重现并记录特定的帧窗口”。

这正是移植工作中关键的分界线：

• 一张截图是有用的
• 一张截图加上 VRAM、CGRAM、OAM、PPU 状态、输入时序及追踪数据，则具备可操作性

一旦代码仓库能够生成后一类输出，移植工作便不再依赖记忆或手动模拟器操作。“第 978 帧发生了什么？”或“此演示画面中哪个回调处于激活状态？”之类的问题，均可通过具体产物回答，而非猜测。

此后的首个开发目标

在 ROM 具备可测量性之后，下一个目标便是建立一条稳定的资源提取管线。

该管线现已覆盖诸多方面：

• 调色板提取
• 启动及辅助场景清单
• 部分 VRAM 重建
• 压缩数据块扫描与解压
• 基于 Mesen 的场景提取
• 为瓦片地图、瓦片集及精灵图生成设计包
• 基于范围的序列管理