java - Z80 DAA 实现和 Blargg 的测试 rom 问题

Question

我想首先说明我是一位经验丰富的程序员，尤其是 Java 已经使用了 8 年。

为了加深对硬件操作和操作系统主题的理解，我决定编写一个简单的 Gameboy 模拟器。在短短几天内编写了核心功能后，我测试了模拟器，结果发现屏幕上没有绘制任何东西。在我的模拟器中一次一个地执行数百个操作码并将其与 BGB 模拟器中找到的值进行比较后，我意识到有问题的图 block 和 Sprite 正在加载到内存中，只是没有绘制。由此我认为问题一定出在我的一个或多个操作码实现中，这导致程序在某些时候表现出错误的行为。因此，我决定使用 Blargg 的 cpu 测试 rom ( http://gbdev.gg8.se/files/roms/blargg-gb-tests/ ) 来帮助我确定问题。但是，运行第一个测试 rom 会出现以下错误消息:

01-special

36E1FE30 
DAA

Failed #6

我已经多次检查 DAA 操作，它似乎在我看来是正确实现的。给出的错误代码(“36E1FE30”)完全没有帮助，因为我似乎无法找到它的含义。对我来说，这意味着要么 DAA 实现不正确，我只是看不到我的错误，要么用于验证 DAA 正确性的操作之一不正确。如果我运行任何其他测试，它们似乎会无限循环

03-op sp,hl

03-op sp,hl

03-op sp,hl

03-op sp,hl

作为引用，我的 DAA 实现在 github ( https://github.com/qkmaxware/GBemu/blob/master/src/gameboy/cpu/Opcodes.java) 上，或者可以在下面看到，如下所示:

Op DAA = new Op(0x27, "DAA", map, () -> {
    int a = reg.a();

    if(!reg.subtract()){
        if(reg.halfcarry() || (a & 0xF) > 9)
            a += 0x06;

        if(reg.carry() || a > 0x9F)
            a += 0x60;
    }else{
        if(reg.halfcarry())
            a = (a - 0x6) & 0xFF;

        if(reg.carry())
            a = (a - 0x60) & 0xFF;
    }

    reg.a(a);

    reg.zero(isZero(a));
    reg.carry((a & 0x100) == 0x100);
    reg.halfcarry(false);

    clock.m(1);
    clock.t(4);
});

其中诸如 reg.a() 的调用表示从寄存器 a 读取，reg.a(value) 表示写入寄存器 a(屏蔽为 8 位或 16 位，具体取决于寄存器)。类似地，标志 Z、N、H、C 可以通过“reg”对象的零、减、半进位、进位函数获取或设置/重置。

所以我的问题有三个，我是否错误地实现了 DAA 操作以致它无法通过 Blargg 的测试，有没有人知道我的错误代码是什么意思，或者有没有人知道我如何集中搜索不正确的操作.

Answer 1

看起来 Blargg 的测试借鉴了一个名为 zexlax 的旧 Z-80 测试程序，该程序采用实用的方法将指令测试视为简单的数据比较。对于 DAA，它运行所有可能的输入组合，并根据预期答案有效地检查它。但是保留所有答案会使测试代码变得不切实际。相反，它比较数据的 CRC。如您所见，这对于验证模拟器的正确操作非常有效，但对于指出如何修复它毫无用处。

虽然如果有人保存了正确的输出以便您可以根据您的实现检查它是理想的，但您仍然可以通过在已知良好的模拟器上运行测试来这样做。或者只是将您的实现与已知的优秀模拟器进行比较。

这是 MAME 的做法:

case 0x27: /*      DAA */
    {
        int tmp = m_A;

        if ( ! ( m_F & FLAG_N ) ) {
            if ( ( m_F & FLAG_H ) || ( tmp & 0x0F ) > 9 )
                tmp += 6;
            if ( ( m_F & FLAG_C ) || tmp > 0x9F )
                tmp += 0x60;
        } else {
            if ( m_F & FLAG_H ) {
                tmp -= 6;
                if ( ! ( m_F & FLAG_C ) )
                    tmp &= 0xFF;
            }
            if ( m_F & FLAG_C )
                    tmp -= 0x60;
        }
        m_F &= ~ ( FLAG_H | FLAG_Z );
        if ( tmp & 0x100 )
            m_F |= FLAG_C;
        m_A = tmp & 0xFF;
        if ( ! m_A )
            m_F |= FLAG_Z;
    }
    break;

有关更多上下文，这里是整个来源的链接:

https://github.com/mamedev/mame/blob/master/src/devices/cpu/lr35902/opc_main.hxx#L354

看起来您的代码可能有些不同，但我没有仔细查看。

我注意到 Blargg 的测试包括未记录的标志位 3 和 5。如果这是一个 Z-80 处理器，它会使一个模拟器失败，因为它没有像 Z-80 那样设置这些位，这实际上是可以预测的，只是没有记录作为您可以依赖的任何东西。我不知道 Sharp LR35902 是否有类似的问题，但如果有的话，MAME 完全有可能没有实现它。这些位永远不可能对“真实”程序产生影响。