无知的我

今天我主要做了两个方面的事情，一是仔细看了一下GBA是否具备写Debugger的条件，二是看了一下关于识别和擦写flash的问题。

首 先说debugger，在debugger中，最重要的一部分就是如何为程序加断点，因为调试一般都是要让程序单步执行。在什么位置加断点的问题是由 GDB来负责的，但具体把断点设置好以及在后面恢复则是stub必须做的。通常情况下，加断点最简单的方式就是使用无效指令来替换需要中断的程序，当 CPU执行到无效指令的时候，会进入一种特殊的状态，从而中断程序并进入stub。要使用这种方式，首先就要知道什么是无效指令，接着就要看当前的硬件是 如何处理无效指令的。在ARM7芯片上，所有的指令的长度都是4个字节或者2个字节，这对替换很方便，而无效指令则可以用0c100000h或者 4400h。在GBA上，其无效指令的处理首先是由ROM进行的，因此就必须要知道ROM中的程序如何执行。关于如何获得GBA的ROM，我稍后介绍。在 ROM中，遇到无效指令时，它首先会保存4个寄存器的状态，接着会根据卡带的两个位置的数值来判断卡带中是否有无效指令的处理程序以及无效指令处理程序的 位置。当卡带拥有无效指令处理程序时，它被放在第一个32Mbit的末尾，因此，stub程序也必须在相应的位置存在一些处理命令。到此为止，我可以肯定 地认为要在GBA上不借助额外的硬件实现GDB的stub是没有问题的，下一步就是做了。

再次，说一下关于flash的擦写。以前我有个 错误的观点认为D卡中用的是SRAM，其实多数D卡使用的都是flash芯片。因此，当程序运行在卡带上时，我们是不能随意修改flash的内容的，即便 是当程序运行在内存中，要修改flash的内容也是比较麻烦的。我看了不少关于擦写flash的资料，基本上大家针对的都是目前比较流行的芯片，基本上没 有介绍经常用在D卡中的三菱芯片的擦写方法的。相信还是有不少人掌握了这个方法了，但由于我还是这个方面的新手，也不太知道应该去什么地方搜索资料，也没 有经验，因此基本上没搞清楚该如何擦写flash。好在这不是一个严重的问题，反正最核心的代码在RAM中调好了就好了，一些不太重要的东西也完全可以在 模拟器上进行调试。

第三，今天我第一次把flash的ROM dump出来了，用的是DumpRom.zip， 它的程序可以把ROM中的内容写到卡带的用于记录游戏备份的sram中，因此只要找一盘普通的卡带，用火线把dumprom.mb.gba程序上传到 GBA上，再用火线备份游戏进度，就可以得到实际的GBA ROM了。拿到这个ROM，可以参考其中的中断以及未定义指令的处理方法，以便自己对其进行处理。