东方PC-98复原项目（"ReC98"）

已逆向工程:
已完成:
位置无关:

查看主页以获取更详细的进度数据和众筹信息！

概述

本项目旨在完美重建ZUN Soft（现为上海爱丽丝幻乐团）最初五款东方Project游戏的源代码。这些游戏最初仅在NEC PC-9801系统上发行。

涉及的原始游戏包括：

TH01: 东方灵异传　～ The Highly Responsive to Prayers (1997)
TH02: 东方封魔录　～ the Story of Eastern Wonderland (1997)
TH03: 东方梦时空　～ Phantasmagoria of Dim.Dream (1997)
TH04: 东方幻想乡　～ Lotus Land Story (1998)
TH05: 东方怪绮谈　～ Mystic Square (1998)

由于我们只有二进制文件，显然无法知道ZUN如何命名变量和函数，以及原始代码周围有哪些注释。因此，"完美"意味着从ReC98仓库中的代码编译出的二进制文件与ZUN的原始构建无法区分，这使得无法证伪原始代码不可能是这样的。这一特性在整个Git提交过程中得以保持。

除了保存的角度和由此带来的对游戏机制的深入了解外，这些代码还可以作为社区开发任何类型的模组或移植到非PC-98平台的基础。这也是为什么ReC98更重视可读性和可理解性，而不是纯粹的反编译。

为什么？

与PyTouhou式的黑盒重新实现相比，通过完全反编译来实现可修改性对PC-98游戏来说似乎更有价值，原因如下：

虽然TH04和TH05的.STD文件中的关卡敌人及其弹幕模式由字节码控制，可以通过替代虚拟机解释，但中Boss和Boss战完全硬编码在可执行文件中。
尽管完整反编译需要很长时间，但部分逆向工程结果对于只想在原始PC-98版本上进行修改的modder来说非常有用。
PC-98模拟复杂且混乱。虽然自2018年以来，由于DOSBox-X增加了对该平台的支持，情况有所改善，但即使在最佳状态下，它也会消耗远超这些游戏所需的系统资源。
在PC-98上进行thcrap式的多语言翻译对非ASCII脚本的语言来说会很痛苦。显而易见的方法是为每种语言专门修改字体ROM，但这种方法不仅不美观，而且无法在真实硬件上运行，因此需要自定义渲染器。这本身就需要大量的逆向工程，最好是可编译的源代码，以避免十六进制编辑的限制。或者更好的是，完全在更现代的系统上实现这一点的前景。
这些游戏自2002年起停止销售，ZUN多次确认已经丢失了"早期游戏"的所有数据<sup>[需要引用]</sup>，而且PC-98硬件早已过时。简而言之，这些游戏已经被彻底遗弃，不太可能再创造利润。

这真的可行吗？

自从众筹带来持续的支持以来，进展一直稳定。TH01的反编译在2022年8月完全完成，剩余游戏的完成只是时间问题。

多年来，这个项目深入了解了原始编译器和PC-98硬件，以至于反编译本身变得相当机械化。为了确保这个项目仍然值得支持且有趣，其重点已转向对ZUN原始代码的细致文档编写和审查。项目博客以更易读的方式详细介绍了所有发现，可以说已成为主要吸引点，而源代码重建本身几乎变成了对这些游戏深入研究的副产品。

这个项目一开始就相当可行。在开发这些游戏的静态英语补丁过程中，我们确定了所有5个游戏中使用的两个主要库，甚至找到了它们的源代码。这些是：

master.lib，一个16位x86汇编库，为PC-98 DOS系统的所有组件提供抽象层
以及Borland C/C++运行时库，版本4.0。
此外，TH01还包括电脑科学研究所/BERO的Pi加载器库
TH03的ZUNSP.COM（可通过ZUN.COM -4访问）是Promisence Soft的SPRITE16.COM的重新品牌版本，这是一个16色PC-98 EGC显示驱动程序，版本0.04，与示例游戏StormySpace一起捆绑。

master.lib和C/C++运行时库单独就构成了所有可执行文件中相当大一部分的代码。例如在TH05中，它们在OP.EXE中占所有代码的74%，在MAIN.EXE中占40%。这已经是相当多我们不需要处理的代码了。识别出游戏间共享的其余代码将进一步将工作量减少到更可接受的程度。

有了DOSBox-X和Neko Project II的调试版本，我们现在有了两个能运行这些游戏的开源PC-9821模拟器。这些模拟器加上关于PC-98开发的旧书籍以及偶尔在真机上的测试，已经帮助解答了大多数与硬件相关的问题。

已转储的可执行文件

TH01: zunsoft.com, op.exe, reiiden.exe, fuuin.exe
TH02: zun.com (<s>ongchk.com</s>, zuninit.com, zun_res.com, <s>zunsoft.com</s>), op.exe, main.exe, maine.exe
TH03: zun.com (<s>ongchk.com</s> [-1], <s>zuninit.com</s> [-2], <s>zunsoft.com</s> [-3], zunsp.com [-4], res_yume.com [-5]), op.exe, main.exe, mainl.exe
TH04: zun.com (<s>ongchk.com</s> [-O], zuninit.com [-I], res_huma.com [-S], memchk.com [-M]), op.exe, main.exe, maine.exe
TH05: zun.com (<s>ongchk.com</s> [-O], zuninit.com [-I], res_kso.com [-S], gjinit.com [-G], memchk.com [-M]), op.exe, main.exe, maine.exe

划掉的文件与前一个游戏中的版本相同。ONGCHK.COM是KAJA的PMD声音驱动程序的一部分，因此也不需要反汇编；我们只需保留二进制文件以允许对ZUN.COM进行完全相同的重建。

本项目不包含原始PC-98版本的任何资源数据。运行编译后的可执行文件仍然需要原始游戏的副本。

分支

▶ master: ZUN的原始代码，不含修改或bug修复 (你现在在这里!)
BossRush
th03_no_gdc_frequency_check: 允许TH03在GDC时钟设置为5 MHz时运行。原游戏强制要求2.5 MHz，但即使在真实硬件上也不需要这个要求。
- 在游戏调试模式下，当HP条仍在填充时按住回车键减少Boss HP可能导致堆损坏。
- 当击败Boss时屏幕上有对角移动的射击激光时可能发生通用保护故障。这些问题最常见于对抗Elis或Mima时，以及在真实硬件或Anex86上玩游戏时。
th01_end_pic_optimize: 将TH01过场动画中的图像绘制速度提高到原来的50%。主要作为一个示例，展示如何在不编写任何汇编指令的情况下，从Turbo C++ 4.0J中获得接近最优的EGC驱动绘图代码；EGC显然不是这项工作的最佳工具。
- 在游戏区域底部中央显示阴阳玉的物理值
- 在每个舞台对象图块的左上角显示自上次与每个碰撞条碰撞以来的帧数
th01_sariel_fixes: 修复了[TH01 Sariel战斗]中由原始代码中明显的逻辑错误导致的三个精灵图形故障。
针对[TH04第5关幽香无EMS崩溃]的修复:
针对[TH04 Kurumi除零错误崩溃]的解决方案:
针对[TH04第4关魔理沙除零错误崩溃]的解决方案:
加上以下通过社区投票选择的TH04 除零错误 bug的解决方案:
- th04_0_ring_as_single_bullet (投票结果)
- th04_marisa4_crash_still (投票结果)

构建

所需工具

Borland Turbo C++ 4.0J 这是ZUN最初使用的编译器，因此它是唯一一个能够确定性地将此代码编译成与ZUN原始可执行文件完全一致的编译器。Borland从未制作过在32位Windows上运行的、针对16位DOS的跨平台编译器，所以C++部分必须使用16位DOS程序进行编译。

ReC98还使用Turbo C++ 4.0J来构建其构建流程中的自定义工具，例如硬编码精灵的转换器。这些工具只需要作为构建过程的一部分原生运行，所以将它们编译成16位DOS程序然后在64位操作系统上模拟运行可能看起来适得其反。但是，这样做仍然有几个原因：

在64位操作系统上构建已经需要DOS模拟来编译游戏本身。
与C++编译相比，即使在模拟环境中，管道工具占用的构建时间也可以忽略不计。
这些工具由相对较少的代码组成，所以用标准C或类C的C++编写它们并不太麻烦。这使得Turbo C++ 4.0J的老旧和缺乏C++标准合规性不成问题。

因此，添加通常相当重的原生C++编译器依赖没有太大意义。

Borland Turbo汇编器(TASM)，5.0版或更高版本，适用于32位Windows（TASM32.EXE）

ReC98不仅需要汇编器来处理尚未反编译的游戏代码，还需要处理PC-98东方系列的第三方库和ZUN自己手写的、无法反编译的汇编代码。幸运的是，Borland的32位汇编器可以用于16位代码，并且在64位和32位Windows上都能原生运行，性能优于16位的TASM.EXE和TASMX.EXE工具。作为附加好处，使用原生32位Windows工具还允许ASM部分自由使用不需要遵循DOS 8.3约定的长文件名。

MS-DOS Player（已捆绑）

这是一个轻量级模拟器，用于在Windows控制台子系统上运行DOS命令行工具，在64位操作系统上构建代码库时自动使用。尽管它的性质很精简，但由于使用了Neko Project 21/W的解释型x86核心而不是动态重编译器，它的运行速度明显慢于DOSBox，但其无缝的控制台集成足以弥补这一点。

捆绑的构建版本专门针对构建ReC98进行了性能优化，运行一个精简的x86核心，只模拟没有FPU、分页或周期计数的386。与[Takeda Toshiya的上游构建]相比，这个构建版本将ReC98的完整重建过程加速了约60%，编译和链接最大的翻译单元和最大的二进制文件加速了约80%，中等大小的翻译单元和二进制文件加速了约70%。它还包含了运行Turbo C++ 4.0J所需的一个bug修复，这在2024年6月的上游构建中还不可用。有关许可证和构建信息，请参阅bin/README.md。

Tup，Windows版（已捆绑）

这是一个合理的并行构建系统，用于确保最小化重建。通过代码注入和钩住编译器的文件打开系统调用，它提供了完美的依赖项跟踪，允许自动将所有#include的文件添加到构建依赖图中。这使它远优于大多数make实现，后者缺乏这一关键功能，因此本质上不适合几乎任何可以想象的编程语言。由于没有特定编译器的抽象，Tup也完全适合这个项目所需的古老Borland工具。

捆绑的64位Windows构建版本包含了一个[重要的bug修复]，用于通过MS-DOS Player运行基于DOS的构建工具，截至2024年6月，这个修复尚未合并到上游仓库中。有关许可证和构建信息，请参阅bin/README.md。

如何构建

只需在任何支持的构建平台上运行build.bat；无论你在运行哪种操作系统，它都会做正确的事情。如果在Windows的PATH中找不到任何必要的工具，该过程将中止并报错。

最终的可执行文件将被放入bin\th0?目录，使用与原始文件相同的名称。运行它们需要在同一目录下有每个游戏的原始资源文件。

支持的构建平台

在64位x86上，构建过程使用Tup进行最小化并行重建，但所有基于DOS的构建工具都会被模拟。在32位x86上，构建过程回退到一个顺序批处理文件，总是构建整个代码库，但所有构建工具都能以原生性能运行。

第一级：定期测试，保证最佳支持。
- Windows 11（64位x86）
- Windows XP（32位x86）
第二级：应该可以工作，可以支持，但不定期测试。构建过程中的关键bug将免费修复。
- Windows 10（64位x86）
- 在64位x86 *nix上运行的当前版本Wine
第三级：应该可以工作，但维护负担重。构建相关bug的修复需要资金支持，但bug修复PR可能会被接受。
- 64位x86 Windows Vista、7、8和8.1
- 32位x86 Windows ≠XP
第四级：明确不支持，没有严肃调整就不可行。需要专门的资金支持或分叉，PR不太可能被接受。
- 64位x86 Windows XP
- 32位x86 *nix
- Windows <95
- 任何非32位或64位x86的平台
- 没有Windows和DOS模拟器的平台

故障排除

TLINK在32位Windows ≥Vista上失败，报错Loader error (0000): Unrecognized Error

有两个已知原因：
- 尝试配置NTVDM DPMI驱动程序加载到常规内存而不是上层内存，方法是编辑%WINDIR%\System32\autoexec.nt：
```
REM 安装DPMI支持
-LH %SystemRoot%\system32\dosx
+%SystemRoot%\system32\dosx
```
  编辑后需要重启才能生效。
  
  （来源）
- 尝试在普通的cmd.exeshell中构建，而不是PowerShell或Bash。