如何解决双重比特GB-EMU
提前道歉,因为这是一个老话题。我正在阅读以下有关Nintendo徽标数据如何在引导过程中复制到v-ram之前进行解压缩和缩放的文章,有趣的是,写入的数据确实看起来很乱(正如发问者所指出的),我已经尽力了(使用我编写的gb模拟器)产生相同的输出...但是没有成功。
有问题的汇编代码是引导rom的这一部分:
LD C,A ; $0095 "Double up" all the bits of the graphics data
LD B,$04 ; $0096 and store in Video RAM
Addr_0098:
PUSH BC ; $0098
RL C ; $0099
RLA ; $009b
POP BC ; $009c
RL C ; $009d
RLA ; $009f
DEC B ; $00a0
JR NZ,Addr_0098 ; $00a1
LD (HL+),A ; $00a3
INC HL ; $00a4
LD (HL+),A ; $00a5
INC HL ; $00a6
RET
8000: 00000000000000000000000000000000
8010: F000F000FC00FC00FC00FC00F300F300
8020: 3C003C003C003C003C003C003C003C00
8030: F000F000F000F00000000000F300F300
8040: 000000000000000000000000CF00CF00
... and so on
非常感谢。
P.S。假设在引导过程中将Nintendo徽标(在某些C / Java代码中)显式复制到了地址为0104h
的v-ram上,以测试引导程序。
.DB $CE,$ED,$66,$CC,$0D,$00,$0B,$03,$73,$83,$0C,$0D
.DB $00,$08,$11,$1F,$88,$89,$0E,$DC,$6E,$E6,$DD,$D9,$99
.DB $BB,$BB,$67,$63,$EC,$99,$9F,$B9,$33,$3E
解决方法
浏览完代码并看到一个潜在的愚蠢的错误(也许是两三个)之后,我终于能够获得与上述相同的结果。请考虑解决此问题。
基本上,我忘了在更改INC n,Add n和Sub n的设置之后更新F寄存器。
从技术上讲,以上输出似乎是正确的。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。