Some tests shouldn't pass on a well behaved emulator

[guigzzz]

This test for example:

{
    "name": "00 1d 8f",
    "initial": {
      "cpu": {
        "a": "0xa6",
        "b": "0x12",
        "c": "0xcd",
        "d": "0x94",
        "e": "0x75",
        "f": "0x50",
        "h": "0x43",
        "l": "0x3e",
        "pc": "0xff1d",
        "sp": "0x8fc0"
      },
      "ram": [
        [
          "0xff1d",
          "0x0"
        ]
      ]
    },
    "final": {
      "cpu": {
        "a": "0xa6",
        "b": "0x12",
        "c": "0xcd",
        "d": "0x94",
        "e": "0x75",
        "f": "0x50",
        "h": "0x43",
        "l": "0x3e",
        "pc": "0xff1e",
        "sp": "0x8fc0"
      },
      "ram": [
        [
          "0xff1d",
          "0x0"
        ]
      ]
    },
    "cycles": [
      [
        "0xff1d",
        "0x0",
        "read"
      ]
    ]
  }

reads at PC == 0xFF1D. This is in audio register land, and reading from that location should always return 0xFF (so we'll execute a RST instead of NOP)

Perhaps the tests should always execute in 0x0000-0xC000 address space ?

[samjkennedy]

Agreed, I'm getting a lot of false positives where I'm not executing because I block writes to registers that can't be accessed by the CPU

[raddad772]

So technically an SM83 would pass this. Those registers are GBC custom processor specific, right

[adtennant]

The README now documents this behaviour. These tests are intended to test the CPU as if it were an isolated component in the same spirit as https://github.com/TomHarte/ProcessorTests.