双重比特GB-EMU

问题描述

提前道歉，因为这是一个老话题。我正在阅读以下有关Nintendo徽标数据如何在引导过程中复制到v-ram之前进行解压缩和缩放的文章，有趣的是，写入的数据确实看起来很乱（正如发问者所指出的），我已经尽力了（使用我编写的gb模拟器）产生相同的输出...但是没有成功。

Link to post

有问题的汇编代码是引导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

在上面的回复中，对v-ram的输出显示为：

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寄存器。

从技术上讲，以上输出似乎是正确的。

emulation gameboy