本文为了自制程序(或者修改后的某些程序)而撰写,记录一些笔者踩过的或者看别人踩过的坑。
我相信大多数人都有能力搞定MIPS的交叉编译环境,不过,直接使用PS2SDK是更简单的做法。
无论是找到了索尼泄露的官方PS2SDK还是玩家自制的PS2SDK,选择你喜欢的就好了。
对于持有PS3向下兼容型号且软破了的人来说,利用SWAPMAGIC启动OPL,并通过SMB运行是最简单的方法。因为PS3仿真的限制,如果每次修补光盘镜像/程序都要重新传输到硬盘/虚拟记忆卡是非常不明智的做法。
对于非向下兼容型号,还不如用PCSX2呢。
至于调试的话……
对于部分使用了TCP的程序,其仿真在CECHA上工作正常。目前仅确认了TCP的工作正常(包括监听套接字和数据套接字),但是,显然,官方仿真并不提供超越零售机的功能。由于ps2_emu.self的关联复杂,目前不认为有对其BIOS进行修改以提供DECI2环境的可能。
此外,诸如PS2LINK等一类软件,无法启动PS2之网络系统。可能是由于驱动的问题。
但是,OPL(github最新版,debug_deci2构建)和RDB只能在有线连接的环境下成功创建监听套接字,并执行网络处理。包括其他软件皆是如此。
比连接稳定性更重要的、使PS3无法进行PS2调试的决定因素是:RDB提供的IOP侧之DECI2服务之TIF桥无法成功连接EE侧的DECI2主机。如果尝试连接,会收到错误信息NOROUTE(不存在到节点(即EE侧的DECI2主机)的路径)。(然而如果发送EE RESET信息,依然会死机,原理未知)如果有人对此有所研究,希望能够留言以交流……
对ps2emu所带的PS2 BIOS进行检查发现几个显著和DECI2关联的模块确实存在,且运行于PCSX2时,发现EE侧的DECI2有启动。暂时无法推测故障原因。由于ps2emu.self关联过于复杂,难以分析;暂不认为有恢复这部分功能的方法。
利用RDB所提供之内核替换功能时,在替换了开发机内核后导致死机。在替换了零售机内核时系统无有变化。故原因非内核导致。
综上,利用PS3调试PS2程序是几乎不可能的。
笔者已经在CECHA00上,通过Rebug DEX/CEX下进行测试,包括了,EXECFTP,PS2LINK在内,并得出此悲伤的结论。
PS2的硬盘破解已经非常成熟,我们早已不需要用什么直读芯片改机了。关于PS2的破解不做赘述。
当然,如果你有一台DTL-10000开发机的话(就是那个PC-PS2缝合怪;对对对,就是那个把一台完整PC当通讯处理器用的白痴设计),用那个调试必然是最好的方法。然而,它的价格就没有多好看了……(一台过时的只能用IDE硬盘超级古董电子垃圾怎么好意思卖那么贵啦!(╯‵□′)╯︵┻━┻)
注意和PS3的开发机分类一样,PS2开发机中的TEST型只是个不做正版校验的普通机器,只有TOOL(我只知道DTL-T10000)才能做调试用途。
如果你有PS2实机(有网卡的那种)的话,RDB或者使用debug_deci2配方()编译的OPL(make debug_deci2)就是很好的选择(注意OPL会驻留在进程里,分析代码时可能会把OPL和要调试的程序的代码弄混)。它们都能启动DECI2/TCP(索尼官方的PS2调试通讯接口)服务主机,这样你就能通过DECI2进行调试了(别忘了-nr选项,重置EE或IOP都将使RDB或OPL提供的DECI2服务暴毙)。至于PC上的客户端的话,除了RDB帖子里提到的工具(Linux用)外,还可以考虑看看能不能找到泄露的官方工具,比如ProDG、CW什么的,不过不建议这么干啦。
需要注意的是,即使使用ProDG或者CW,也必须首先用dsnetm连接TIF,然后由ProDG TM连接dsnetm。
或者,其他hacker做的远程调试器也能用。
缺点当然就是这么干超级麻烦啊……
通过PCSX2仿真器时,请记得一定要把EE和IOP改成解释器。重编译器会掩盖掉一些编程上的错误,最终可能导致PS2实机运行时崩溃。
要举例子的话,比如PCSX2能够容忍非对齐内存访问,然而在PS2实机上会直接引发异常;更重要的是,PCSX2的重编译器不会报告“发生了非对齐内存访问”这一错误,而这个对于最终的成品来说是很要命的纰漏。
此外PCSX2对于DMA也没有严格的限制,这也可能使得最后的成果出事。
而且由于仿真器的特殊性(翻译的目标代码因机器而异),不同的人可能在不同的地方甚至是随机出事。所以如果要利用PCSX2进行调试,请小心而慎重地进行。
优点嘛……貌似也没有就是,毕竟用PCSX2的前提是已经有了一台PS2,不是么?(笑)当然有的人PS2坏了不舍得花钱买新的也是可能的,嗯。