将《测试驾驶II》从超级任天堂移植到个人电脑，第一部分：从第0天到可测量的ROM

在2026年2月26日至3月19日期间，asmdump代码仓库经历了45次提交。它最初只是一个原始的逆向工程转储，到这一阶段结束时，已具备C/SDL运行时、确定性模拟器探针、图块地图溯源工具和回归测试关卡。

本篇第一部分涵盖前两天的内容：第0天仓库中有什么、项目为何没有从游戏逻辑代码开始，以及初始的提取与验证工具链如何改变了问题的形态。

第0天：仓库是一个逆向工程基础

2026年2月26日的提交a683c61是真正的起点。它导入了以下内容：

• bank0.asm至bank31.asm
• game.smc和game.sym
• ROM构建文件，如Makefile、linkfile、main.s、snes.asm和spc700.asm

这些内容足以重新构建并检查ROM，但还不足以进行移植。

当时没有资产提取流水线，没有确定性捕获框架，也没有PC运行时可以加载的稳定资产格式。该仓库对内存地址了解很多，但对模块间的契约知之甚少。

缺乏直接的反编译路径在这里至关重要。bank0.asm已经暴露了可识别的复位、垂直消隐中断（NMI）、中断请求（IRQ）和回调调度逻辑，但面向游戏玩法的代码段尚未达到适合直接进行汇编到C语言转换的状态，原因如下：

• bank10.asm和bank11.asm仍然严重混合了代码与数据
• bank30.asm看起来更像是结构化的表格和分发器数据，而非清晰的可调用函数列表
• game.sym仅暴露了标签和覆盖范围，而非行为逻辑

因此，早期计划并非“先翻译bank 0，再bank 1，然后bank 10”。早期计划是：

1. 使原始ROM变得可测量。
2. 从中提取类型化的数据。
3. 在PC端根据这些测量输出重建系统。

这一决策至今仍是正确的。一个可靠的移植项目，在拥有更多C文件之前，首先需要一个参考框架。

首批工具的爆发式开发

2月27日共有九次提交。这一天实际上就是真正的“第1天”移植工作。

其中重要的提交包括：

• c867efd - 超级任天堂资产提取工具链的脚手架
• fcc30b5 - 场景、精灵和道路可视化工具
• f8785b9 - 完全集成的Qt资产查看器用户界面
• 2bc9dc2 - 初始脚本、精灵转换、捕获数据以及首个运行时骨架

仓库不再将ROM视为一个整体，而是开始将其转化为可检查的输出：

• 调色板转储为JSON格式
• 显存（VRAM）重建与启动画面清单
• 解压缩后的数据块输出
• 图块表渲染为中立图像格式
• 基于Mesen的截图与状态捕获
• 可在模拟器外部驱动的场景可视化工具

该阶段的代表性命令至今仍很好地描述了这一方法：

./validation/run_mesen_capture.sh

python3 tools/extract_bank3_palettes.py game.smc tools/out/bank3_palettes.json
python3 tools/extract_boot_screen_manifest.py game.smc tools/out/bank1_boot_screen.json
python3 tools/build_boot_vram.py game.smc tools/out/bank1_boot_screen.json tools/out/bank1_boot_vram_variant0.bin --json-out tools/out/bank1_boot_vram_variant0.json
python3 tools/decompress_td2_chunk.py gam