运行调试的坑点之类的
本文为了自制程序（或者修改后的某些程序）而撰写，记录一些笔者踩过的或者看别人踩过的坑。
SDK
我相信大多数人都有能力搞定MIPS的交叉编译环境，不过，直接使用PS2SDK是更简单的做法。
无论是找到了索尼泄露的官方PS2SDK还是玩家自制的PS2SDK，选择你喜欢的就好了。
运行与调试
通过PS3
对于持有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的硬盘破解已经非常成熟，我们早已不需要用什么直读芯片改机了。关于PS2的破解不做赘述。
神（昂）奇（贵）的DTL-10000！
当然，如果你有一台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仿真器
通过PCSX2仿真器时，请记得一定要把EE和IOP改成解释器。重编译器会掩盖掉一些编程上的错误，最终可能导致PS2实机运行时崩溃。
要举例子的话，比如PCSX2能够容忍非对齐内存访问，然而在PS2实机上会直接引发异常；更重要的是，PCSX2的重编译器不会报告“发生了非对齐内存访问”这一错误，而这个对于最终的成品来说是很要命的纰漏。
此外PCSX2对于DMA也没有严格的限制，这也可能使得最后的成果出事。
而且由于仿真器的特殊性（翻译的目标代码因机器而异），不同的人可能在不同的地方甚至是随机出事。所以如果要利用PCSX2进行调试，请小心而慎重地进行。
优点嘛……貌似也没有就是，毕竟用PCSX2的前提是已经有了一台PS2，不是么？（笑）当然有的人PS2坏了不舍得花钱买新的也是可能的，嗯。
