本文共计68020个字，预计阅读时长272.1分钟。

目录

1. 1. 2023年5月24日
2. 2. 2023年5月25日
3. 3. 2023年5月27日
4. 4. 2023年5月28日
5. 5. 2023年5月29日
6. 6. 2023年6月7日
7. 7. 2023年6月8日
8. 8. 2023年6月9日
9. 9. 2023年6月10日
10. 10. 2023年6月11日
11. 11. 2023年6月20日
12. 12. 2023年7月10日
13. 13. 2023年7月12日
14. 14. 2023年7月19日
15. 15. 2023年7月24日
16. 16. 2023年7月29日
17. 17. 2023年8月17日
18. 18. 2023年8月21日
19. 19. 2023年8月22日
20. 20. 2023年10月26日
21. 21. 2023年11月11日

哈哈哈哈哈哈……直接开启无敌底挖坑模式，我前几天才开的《阳极/阴极驯兽师》，这几天因为忙别的去了，所以到现在还没动，这会儿又开了一个……《魔卡少女樱》这个其实应该算计划之外的，至少没有马上开的打算。不过因为一些巧合，所以昨天突然提上日程，并且搞了一个差不多的码表，开头的文本能看了。那既然如此也记录一下吧~

---

2023年5月24日

跟《阳极/阴极》不一样，这游戏一路点进去没碰到起名系统，所以不能用构建存档比较差异的方式先确定几个字符的代码。不过无妨，还是找字库先。由于是WS，没有彩色，所以先从低BPP找起，更严谨的做法是进游戏，用模拟器/调试器查看tile，再决定用多少BPP。不过其实也没多少，直接试也挺快的。字库信息如下。

Software	Address	Format	Pattern
YY-CHR.NET	001F04E0	1BPP 8x8	FC/NES x8

居然跟《阳极/阴极》一样，好，积累经验了。字库还是经典的顺序，按顺序编个码，进游戏找句话，然后就可以用相对搜索搜了。很顺利，最开始的文本也找到了，然后就是一边十六进制编辑器加载码表，一边模拟器走流程，校对完善码表，反正一晚上搞下来的经验就是——确实字符的代码顺序基本遵循字库的字模顺序——以后可以压缩花在码表上的时间。

顺序解决了，现在的问题是，这个游戏有汉字字库，用的还不是标准的字库（啊其实我没去确认，不过扫一遍下来感觉这个结论没有错）。没有现成的轮子可以用，那只能暴力转录了。我一开始是准备OCR的，但是试了两个，效果意外的差，所以只能老老实实手打。倒不是怕累，只是我不会日语，虽然汉字很亲切，但我确实不能保证能做到正确地转录下来。所以我尝试性地搜了下

之类的，没想到还真有，救大命。然后这个过程中我又学会了怎么把一长串字符串一个一个地分配到单元格里。把少说几百个汉字转录完后，继续完善汉字的编码，这个码表也就搞了个七七八八了。然后拿蓝山魔导预览了下，嗯，效果不错，可以安心睡觉了。

2023年5月25日

果然事情不会一直那么顺利，第二晚就碰到问题了。本来是继续完善码表的，汉字部分没问题，问题在于那些不在Shift-JIS内的字符，一开始打算用其他未用到的字符凑活代替一下，后来想到可以去更大的Unicode里面找。在蓝山魔导里编辑完码表后，Translhextion加载不了，原来蓝山魔导支持ANSI和Unicode，但是编辑后会存为后者，看了下，具体是 UTF-16 LE，恰好不被Translhextion所支持。现在有以下几个方案：

• 拥立蓝山魔导的 UTF-16 LE，寻找Translhextion的替代品。
• 拥立Translhextion，寻找蓝山魔导的替代品。
• 我都要，各用各的编码格式。
• 回到最初的美好，不要在蓝山魔导里编辑文件，只用Shift-JIS里有的字符。

别的工具软件还好说，蓝山魔导这种支持中文的文本工具，可能在国外那个圈子里不太好找替代品，而在国内，蓝山魔导似乎是最用户友好的（功能也不少），第二点pass。两种编码格式同时用，对于一个文本量大的项目，不算一个好主意，第三点pass。第一点，我从当晚到现在一直在找，很遗憾，没找到，pass。所以目前来看就保持ANSI，只不过是不要在蓝山魔导里编辑，以及字符的选择不多。身体不舒服，写完这些，今晚不搞了。

2023年5月27日

做好了选择，接下来就是好好捣鼓码表了。我还去查了下ANSI是啥：简而言之，它不是某种确定的编码，而是根据你的系统而定，我用的中文体统，那就是中文编码（应该是GB？）。藉此我才发现简中字符集里包含平假名片假名，也不奇怪为啥有些Shift-JIS的字符会乱码了。所以，本来有编码的那就校对好，没有编码的就要想办法找替代。

另外一个发现，不是有所谓的全角半角之分吗？我以为这个游戏里也是这样的，结果发现没那么简单的。一开始在YY-CHR里看到的是，字库里每个编码对应着一块1616的点阵，但对于一些标点符号和小写假名，其所属点阵的右半边是涂“黑”的，游戏里肯定不会这么显示，所以我想当然地认为这些字符会是以816显示在游戏内，直到我开始研究一行最多能放多少字符。我尝试将一些符号与汉字进行对比，结果发现这些符号虽然都比汉字窄，但也是窄得不尽相同的。然后我又试着用汉字比汉字，结果我崩溃了——汉字也不都是一样宽的——难道游戏程序为每个字符指定了显示宽度？这样会大大增加汉化难度（如果要求比较好的显示效果的话）。最后，我开始修改字库的字模，结果发现，字模的显示是限定范围内的自适应的——对于1616的点阵，其左边的916是一定会被显示的，如果字模更大，则会显示到字模最右的像素点，而上限当然是16。从实际层面来考虑，为了不让字符紧贴，要留出1个像素的间隔，所以实际显示的字符宽度就在8-15，可以说非常够用且灵活了，字塞不下我还可以减小字模宽度（当然代码也需要足够的空间）。

2023年5月28日

知道了这些，又有好多东西想去确认了。首先，在保证显示“正常”的情况下（即字符不会覆盖对话框等其他元素），一行允许的显示宽度到底是多少像素？为此，我把某页字符（包括换行控制符）全改成同一字符，且把该字符字模改为最大的1616，结果是821=168个像素。更有趣的是，这么长一行确实是溢出了对话框，但是它居然换行了！准确地说是换“半”行（下移了8个像素）。为了搞清楚换行的情况，我要去替换临界的字符代码。结果发现这换“半”行的中间是有损失的，从上行的屏幕右边界到下行的屏幕左边界大概差了3个汉字不到（30个像素左右），好像不是啥有用的信息。其次，刚才都是拿汉字试验，对于那些所谓的“半角”字符呢？同样还是改代码和字模，结果发现它们就是上面那些汉字的右半边的性质——至少显示最左1个像素宽度，最右可灵活自适应——不过也不意外，因为对于目前已知的字模显示方式，就可以定义两种，一是固定显示816，二是自适应的816，后者就是半角字符，两者组合就是全角字符。

那么，所有半角字符点阵右半边的大黑块有什么意义吗？于是我随便修改之后进游戏看——还是一样——结论是的确没意义，这些大黑块所在的区域像是被注释了一样（也就是说我可以在这里藏私货了哈哈），所以说这也许是开发人员注释半角字符的区域？

现在遇到一个很奇怪的问题，FBB3这个代码会让蓝山魔导卡住然后闪退，而这只是个汉字的编码啊，我很费解。也许，重启电脑就好了？经过进一步的排查，好像问题是出在换页控制符上了，为啥我记得前一阵子还没问题的？难道是完善后的码表和这个换页控制符冲突了？尝试重新定义了换页控制符，这次好像暂时没出什么问题了。没想到搞个码表也费了挺大劲。

2023年5月29日

本来今天的打算是试作个小的汉化试试效果，吭哧吭哧把开头的文本稍微机翻了下，丢到蓝山魔导里生成了个码表，一下子陷入沉思了：这才第一章，新出来的字符就有大概两百个了，注定大部分文本都要用双字节编码，那你本来以单字节编码为主的文本代码空间就被压了将近一半，如果只是单纯地替换，就要求译文做到原文一半的字符数，这应该算比较大的影响了吧？看来应该必须要了解一下指针这些了。又是头疼的一晚，主要是太菜了。然后就是字模那边了，照这么看，得搞成百上千个新字模了，而这游戏的排列方式又对CT不友善，否则可以直接在CT里加字模了。唉，真是给自己挖了个不小的坑。

2023年6月7日

中间又去研究别的了，比如任系平台的扩字库、汇编、WonderSwan调试器等等，其实也没什么特别大的收获。不过今天找到个更好的十六进制编辑器——ImHex——当然，我是从自己的需求角度来评价的。这个软件好像是近年来热度有点突出的，它自称是专注于逆向工程的，我不懂这些啦，不过逆向工程跟我想做的汉化应该还是有些关联的。我觉得它好，有以下几点：

• 支持自定义的码表（.tbl）：其实十六进制编辑器能做到这点的就不是很多，因为这大概是搞汉化的人才用得多的特性。
• 体验流畅：不知道为啥，支持自定义码表的Translhextion和WindHex在选择和滚动页面这两个操作上，给我一种不流畅感。
• 支持主题：这对十六进制编辑器可是相当少见呐，虽然总共没多少，但是很多都是dark主题，对夜晚工作的人特别友好。其实WindHex背景也是黑的，但是是那种简单粗暴的纯黑背景，跟dark主题的体验差距有点大。
• UI：我不知道怎么形容这个，常规的软件或者说十六进制编辑器，功能都放在菜单中，对于不熟悉的人来说，要先在菜单里翻找，然后通过文字想象，点击后才能看到相关界面，而ImHex的多数功能都是以面板/标签页的形式分散在工作区里，很直观，反之，菜单很简洁。 当然也有别扭的地方：
• 默认字体太小且不支持调节，得自己再找，也不能选装到系统的字体，得单独指定一个位置的字体。
• 应用码表后，如果碰到多字节编码被分到两行，那么正确的编码字符会显示在上一行末尾，而下一行又重新编码，仿佛之前的和它没关系。

好，回归正题，继续研究rom。因为目前的到的文本基本上是夹杂着换行符和换页符，我在想这两个控制符是不是能自行调整？所以我选定前两页为测试范围，本来是①{换页}②{换行}③{换页}，我想试试改成①{换行}②{换页}③{换页}会是什么效果，结果第一页的确如①{换行}②所示，但是接下来第二页居然是直接②开头，这就说明我以为的换页符其实并不是执行我以为的换页操作，很有可能是结束当前指针，开始下一指针的操作——简而言之，换指针。于是，我又稍微改动了一下，在②的中间插入一个换行符，即①{换行}④{换行}⑤{换页}③{换页}，同样第一页仍然没问题——④换行后，⑤覆盖了边框——第二页则是显示了④{换行}⑤，说明指针已经固定了第二页的开始位置。于是，我又换了个改法，这次在①中间插一个换页符，即⑥{换页}⑦{换行}④{换行}⑤{换页}③{换页}，这次第一页还是正常只显示⑥，第二页依然从④开始，基本确定了每页都是固定的指针，不存在换页符，而是换指针符。

我还是不放心，追加了最后一个趣味小试验，把每页的第二个字符改成换指针符，跑了下，确实是每页就一个字了。这下确认了，在不改动指针的情况下，每页的代码是有上限的，而换指针符就是{FF}。这下难办了哟，如果想要比较好的汉化效果，估计得搞明白脚本指针表了，要不然受限有点大。这也意味着我要去了解一下汇编追踪以及硬件架构等等……

2023年6月8日

首先，我知道怎样在CT里正确查看这个游戏的字库了，在8×8看到个大概后，换成16×16，并切换为OBJ(H)，实在是太不直观了，还是我在一篇GB的教程里看到的。

其次，今晚一直在找字库地址的记录，可惜不管怎么看GBA的教程，还是没办法套用在WSC上，我对十六进制值和架构还是没有什么概念。

2023年6月9日

忽然想起来口袋妖怪改版资源吧有一些教程，去看了下，没什么用，还是用别人现成的工具，没有根本的方法。

有一件很欣慰的事，我可能找到脚本指针相关的代码了，其实很简单，在最开始找的脚本往上翻，会有一块格式非常工整、变化趋势一致的连续字符串，通过不断地修改、观察，确定了正常游戏流程第一句话对应的代码大致所在——我没有直接称呼为指针，是因为我发现它的运作方式似乎和我预期的不同，我本来想继续研究的，奈何有只小蛾子在我眼前飞来飞去，所以我决定立马休息。这几天一直在研究的汇编、硬件架构、跟踪等等从上而下的门路，终究是败给了简单粗暴的看，嘛，还是因为我啥都不懂，所以简单粗暴有时候更好用。所以要记住这点：指针一般在它所指向的脚本的附近（网友说的）。另外我不大确定在哪看到过，说是脚本和它所指向的脚本在同一个bank里，从实践角度来看，好像前面一句就够用了。这算是稍微有一点进展了，虽然不是我优先级最高的那个，但有进展已经很开心了！

2023年6月10日

我要哭了，果然昨天找到的那个不是我预想的目标本身。补充一下昨天的内容，当时找到了一大块字符串块，很明显是以四个字节为一组的，通过不停地修改、观察，确定了只有位于0x1100A8的字符串被修改后，才会导致游戏内的第一句话改变。我当时以为这就是第一句话的指针了，所以将它和第一句话脚本的地址对比，结果没看出什么。

今天开工后，我打算用同样的方法排查出第二句话的指针，结果全改了都没发生变化，这说明昨天找到的字符串不仅控制着第一句话，还包括第二句话。但这和我预期的不同，因为根据2023年6月7日的结论，存在指向每页的指针，所以第二句话一定有指向它的指针。不过昨晚的发现还是有意义的，因为它确实能影响脚本文本。根据我的猜想，既然昨晚找到的那个指向的范围更大，那么它一定是层级更高的指针，我姑且先把我本来要找的称为“页指针”。要说比页指针层级更高，因为这个游戏是按天推进的，譬如固定第一天都是4/4，所以可能存在“日指针”，这个日指针指向另一个页指针块，是该日所有脚本的页指针。注意，这只是猜想！需要验证！

不过当务之急还是找到页指针。既然昨晚找到的那一大块字符串不是，那么我就往下找，同样有以每四个字节为一组的字符串块，还是如法炮制，很快就找到了。而且这次相邻的字符串对应游戏内的相邻页，更改字符串，游戏内也变成相应脚本。所以我把每页脚本的地址和指针列在表格里对比了下，不多说，你们自己看一下：

地址	指针
0x00111178	08 00 17 31
0x00111182	02 00 18 31
0x0011119A	0A 00 19 31
0x001111AC	0C 00 1A 31
0x001111CE	0E 00 1C 31
0x001111DE	0E 00 1D 31
0x001111F6	06 00 1F 31
0x00111200	00 00 20 31
0x0011121A	0A 00 21 31
0x00111228	08 00 22 31

所以你应该能体会到我有多开心了吧。

2023年6月11日

没干活，就请教了大佬关于WonderSwan指针的问题，现记录原话：

Get familiar with how WonderSwan banking works
http://perfectkiosk.net/stsws.html -> Memory Map
My guess is that 08 00 17 31 is little endian for a 3117:0008 segment:offset address
this thus points to byte (0x3117 * 16) + 0x0008 -> 0x31178 in the 20-bit memory map
which is 0x1178 in some bank, as 0x30000-0x3FFFF is a 64KB bank
It is a little unusual compared to other 8-bit systems, because you have *both* banking *and* segmentation

2023年6月20日

前段时间去看了一些外国教程，熟悉了几个外国工具的最最最基础的用法（至少是重复教程成功了），但是好像对我这个项目没什么太大的帮助。想了下，以我目前的知识水平，以及WonderSwan这个平台的现存资料，最妥善的思路还是：绝对不碰程序代码相关，只做替换。但是隐患就是，字库不够用，你一旦要扩字库，就不得不伤筋动骨。现在就怕开工汉化大半被字库卡住，那多难受。

去看了下字库，FBXX没用完，我尝试直接顺着往后加字模，进游戏测试，发现是一个都加不了，必乱码。还好一测就测出来了，否则如果这样就开工了，到后面才出问题也同样难受。难哦……

2023年7月10日

好久没记录了，一筹莫展就没什么动力了。这段时间去学了点Python，还摸索了下WonderSwan的调试和汇编该怎么入门：因为CPU是魔改8086，所以应该还是要看x86的汇编，才反应过来这可是最最经典的架构了吧？有口皆碑的入门教材——王爽的《汇编语言》——就是以x86来讲的，这本书还能找到较新的PDF。其次就是终于大概知道Mednafen的断点怎么设置了，其实出乎意料的简单，直接Shift + R/W就好，还有别的读写断点不知道有什么不同，但我想要用的已经找到了。

因为想研究字库，所以游戏运行到对话界面，Alt + D进入调试界面，Alt + 2切换至图像查看页面，一边推进对话一边观察，发现说话人头像和字模在内存里也在同步替换，但是起始位置是不变的，记录如下：

		头像	字模
Tile	0	195	1AE	1FF
Address	0x2000	0x3950	0x3AE0	0x3FFF

而所有tile的区间是0x2000 - 0x3FFF,这似乎意味着单页脚本长度受到RAM的限制？

2023年7月12日

再记录一个小小的进展吧。我实现了

上记录的进入Scene Viewer的操作。而且我小小地简化了下：我是用的Mednafen，进入游戏后按一下START跳过片头直接到标题页面，然后直接把0x1090E处的数值改成0x20就行。

2023年7月19日

想了想又打算研究一下内存的情况，就是WonderSwan上那个1MB的memory，看了下，就Mednafen和ares可以dump memory。其中ares不能Dump整个1MB memory，而是CPU RAM、Cartridge ROM、Cartridge RAM、System EEPROM这几个，而且还有不太好的地方，比如说CPU RAM，对应着技术文档里前64KB的Working RAM，而按照技术文档所言，黑白monochrome只会用到前¼，ares就不会把后面¾也一起dump出来，我感觉不太好，虽然后面理论上没用，而Mednafen就会全部dump出来，我看了下，说是没用的后¾居然有非零的数据，虽然也就几个，但这更让我坚定了要完整dump的理念。回到Mednafen这边，首先，整个1MB的memory能以CPU Physical的名义dump，其次RAM对应着memory前64KB的Working RAM，后面就是CPU四个段寄存器对应的部分了。

先说清楚，这些.bin文件，都是在游戏标题画面时dump的，只是初步研究一下memory的映射情况，并不能作为普遍规律。

其实我昨天就研究了CPU Physical与游戏ROM的关系，发现前者的0x40000—0xFFFFF对应着后者的0x140000—0x1FFFFF，而这就包含着我最关心的字库数据。查技术文档发现正好对应memory的Cartridge ROM bank EX/Cartridge ROM bank 2（以最新文档中的前者为准吧）。

然后今晚我先研究Code Segment，程序代码很重要，事关汉化能否有突破。我将其与CPU Physical进行比对，发现正好对应0xD0000—0xDFFFF，即游戏ROM的0x1D0000—0x1DFFFF（姑且称为BANK 1D），所以可以说BANK 1D是代码吗？先记下这个，后续留意。

其次就是Data Segment了，这样我在debug的时候就知道怎么设置断点了。比对发现就对应着CPU physical的开头，即WRAM？这个稍微有点出乎我的意料…可能还需要进一步研究。

Stack Segment按照我的猜想是在CPU计算的时候中转数据用的，所以我先来看看Extra Segment。比对下来是CPU Physical的0xA0000—0xAFFFF，即游戏ROM的0x1A0000—0x1AFFFF（姑且称为BANK 1A），我记得之前看技术文档里没有Extra Segment而是2个Data Segment，所以BANK 1A可能是放数据的。

最后的Stack Segment，这个我说不好，因为有太多的空值，拿仅有的一些非零值搜索了下，发现大概率对应着CPU Physical的0x10000—0x1FFFF，即Cartridge SRAM，搞不太懂…

由于除了Data Segment，其他都有了比较明确的对应，所以再将其与游戏ROM比对了一下，没找到能对上的BANK。再仔细想想，Data Segment如果说是CPU的直接数据来源，那对应WRAM不是很自然的事吗？

然后我又打开Mednafen，调到Graphics Viewer，看了下范围在0x02000 - 0x03FFF，是文档里WRAM的Characters部分。这个时候把memory dump一下，用CT2打开，跳转到相关地址，调了下，能看到之前在ROM找到的字库，但不太一样，当然还是16*16，但是此时不用像查看ROM里字库那样去调OBJ什么的。另外我在Graphics Viewer里看到的与在CT里看的.bin不一样，Graphics Viewer更接近实际游戏画面，而CT里每个tile右半边是空白的，按照数据量来说，CT里才是完整的，啊，搞不懂。

继续正经的，接着把Code Segment dump出来，还是同样的对应关系，那说明BANK 1D是需要研究一下了。

我把BANK 1D丢到010里尝试反汇编了一下，居然对上了…然后我又把它丢到ImHex里反汇编了一下，也是一样的结果。啊~~~~我吼开心啊~~~~今晚就到这里，拜拜！

2023年7月24日

这几天又有点摸了，讲下我今晚在干嘛。问题不还是想扩字库吗？现在我就想知道，游戏是怎么把字符代码转化为字模指针的（即字符的tile在memory里的地址）。通过手动控制可以观察到，图像先是在WRAM里按照经典的逐行扫描的方式生成一个一个tile，然后屏幕上会有所滞后跟随显示出图像。猜想是游戏拿到一个字符的代码，然后在WRAM生成相应图像，然后读到下一个字符的代码，接着生成相应图像……我分别给脚本中某相邻两字符的代码所在的地址设置读断点，那游戏去找前一个字符对应字模的程序就在这俩断点之间。断点断下来发现都断在D60D:07C6，很显然就是用相同的子程序读取了字符代码去生成相应图形，在这子程序中很大概率有怎么找字模的代码，而且这程序可以说应该就在D60D这个代码段中。所以我现在就是在第一个断点开始，不断步进到第二个断点，其中每一步的指令和寄存器参数都要记录下来，这样我才能去看程序到底是怎么写的。可以说是非常粗暴了（未必简单）。如果我会反汇编，也许直接就能搞成汇编代码了吧……

2023年7月29日

想想还是来记录一下吧。聊一下今天的发现。

我们一般把早年间卡带载体dunp出来的游戏文件叫ROM，没记错的话其实是read-only memory，其实是一种很宽泛的概念，只不过在模拟器游戏这个圈子里有了比较特定的理解。模拟器模拟器，就是模拟主机/掌机硬件，用模拟器加载ROM，大致相当于游戏机读取卡带。在实际原生的运行过程中，游戏机的处理单元并不是直接与游戏卡带里的只读数据进行交互的，一般都会有一个暂时放置数据的地方，好像一直是叫RAM？不过我在游戏机领域，有各种乱七八糟的RAM，我自己也不能完全搞清楚，所以我暂且用模拟器Mednafen的debugger里用的术语——memory。

今天本来是要找memory里储存的字库。字库在ROM的储存位置和方式已经在这个项目的一开始就搞清楚了，位置是BANK_1F（0x1F0000 - 0x1FFFFF），格式是单色 1bpp / 16*16 / OBJ(H)。memory里有两个与字库有关的位置：①memory的0xF0000 - 0xFFFFF直接映射自ROM的BANK_1F，这就是一直说的“ROM的数据不会直接被处理，而是被传送到memory里”。②memory里还有另一块区域，某最新的硬件文档称之为“WRAM”，即Working RAM。对于实际运行过程中显示的文本图像，其对应着WRAM里的数据。也就是说①里的字库数据在处理过后被传送到WRAM。

所以问题就在于WRAM里的字库数据是什么样的。我原来以为，游戏程序只是从①里的大字库中挑选出当前需要的文本的字符tile，然后传送至WRAM。所以我之前在Mednafen的debugger里，把memory dump出来，用CT打开，去看WRAM的文本字符，却并不如实际运行所显示的那样，而是有规律地，每隔一段插入一块空白的图像。今天再次用CT打开这份memory dump，才发现WRAM里的图像（至少是文本用到的字模部分）应该要用GB 2bpp / 16*16 / OBJ(V)来察看。

2023年8月17日

我又回来了，这段时间并不是完全忘了这茬哦。因为我决定要稍微正式地学习一下x86汇编，要不然感觉实在不好下手。但是今晚，有些意外收获。其实本来我是打算再追踪一下游戏的代码，奈何Mednafen的debugger实在有点不友好，效率上不去，但通过设置断点得到了几行比较关键的代码和数据。一筹莫展之际，我又鬼使神差地打开了StoicGoose的debugger，试了一下，结果发现成功触发断点了，然后顺着下去找到了字库的某个基地址，改了一下，确认确实是，不过显示效果有点问题，还需要继续研究。

2023年8月21日

今晚的心得很简单：Mednafen可以dump反汇编代码。

别问我为什么就这一点。

2023年8月22日

前几天：我好牛，我联用两个debugger找出了字库段地址。

今天：怎么回事？为什么debugger没按照我想的那样工作？

2023年10月26日

好久没更了，简要说说自上次记录以来的概况吧。

我在长假前尝试了一次改代码，结果以失败告终。然后长假头一天就感冒了，挺严重的那种，大半个假期都栽进去了，加上之前的失败，心里自我暗示估计没那个能力搞，就没怎么去动那坨东西。

假期回来后赶着搬宿舍，损失惨重，搞得我也是有点郁闷。终于在上周，决定坐下来，好好再梳理下，没想到当晚就实现了自己预期的效果，想着第二天开始好好干。没想到第二天回来发现电脑开不了了，跑了趟售后，说要返厂，结果今晚才拿回来电脑，而且今晚也有点累，不太想弄，于是就先来更新下。

但愿一切顺利吧！

2023年11月11日

又过了挺久了，不天天记录还真记不清具体过程了，目前感觉是改代码成功了，所以试着让人翻译开头的一段流程，到时候整个预览先，这个游戏的破解工作似乎是到一个节点了。这几天在给别人看另外的游戏，又有新的挑战。

本帖最后由 PECO 于 2023-11-11 14:59 编辑