Z80 DAA 实施和 Blargg 的测试 rom 问题

Question

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

为了提高对硬件操作和操作系统主题的理解，我决定编写一个简单的 Gameboy 模拟器。在短短几天内编写了核心功能后，我测试了模拟器，却发现屏幕上没有任何内容。在我的模拟器中一次通过数百个操作码并将其与 BGB 模拟器中的值进行比较后，我意识到有问题的图块和精灵正在加载到内存中，只是没有绘制。由此我认为问题一定出在我的一个或多个操作码实现中，这会导致程序在某些时候表现出错误的行为。因此，我决定使用 Blargg 的 cpu test roms (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 那样设置这些位的仿真器失败，这实际上是可以预测的，只是没有记录任何你可以依赖的东西。我不知道夏普 LR35902 是否有类似的问题，但如果是这样，MAME 完全有可能没有实现这一点。这些位永远不可能对“真正的”程序产生影响。