Unexpected Q values

[samplx]

I have been working on an emulator and have been using the previous version of these processor test files that were part of the earlier JSMoo repository. When I switched to this more recent version, I had over 50% of my opcodes fail the tests.

While performing an investigation I saw that the "q" register was different. In the previous versions of the JSON files,
and in the ares sources and in the jsmoo sources, the Q register is a flag, a single-bit value of either zero or one.
In the latest versions, the value appears to be a byte, not a bit. For example, from v1/04.json,

...

  {
    "name": "04 0001",
    "initial": {
      "pc": 59711,
      "sp": 28986,
      "a": 50,
      "b": 242,
      "c": 132,
      "d": 238,
      "e": 176,
      "f": 142,
      "h": 107,
      "l": 248,
      "i": 153,
      "r": 59,
      "ei": 0,
      "wz": 14358,
      "ix": 13969,
      "iy": 48843,
      "af_": 54814,
      "bc_": 10826,
      "de_": 57474,
      "hl_": 23694,
      "im": 1,
      "p": 1,
      "q": 142,
      "iff1": 0,
      "iff2": 1,
      "ram": [
        [
          59711,
          4
        ]
      ]
    },
    "final": {
      "a": 50,
      "b": 243,
      "c": 132,
      "d": 238,
      "e": 176,
      "f": 160,
      "h": 107,
      "l": 248,
      "i": 153,
      "r": 60,
      "af_": 54814,
      "bc_": 10826,
      "de_": 57474,
      "hl_": 23694,
      "ix": 13969,
      "iy": 48843,
      "pc": 59712,
      "sp": 28986,
      "wz": 14358,
      "iff1": 0,
      "iff2": 1,
      "im": 1,
      "ei": 0,
      "p": 0,
      "q": 160,
      "ram": [
        [
          59711,
          4
        ]
      ]
    },
    "cycles": [
      [
        59711,
        null,
        "----"
      ],
      [
        59711,
        null,
        "r-m-"
      ],
      [
        39227,
        4,
        "----"
      ],
      [
        39227,
        null,
        "----"
      ]
    ]
  },
...

Why did the definition change? Which of the 8 bits is the real Q? Is a Q of 142 set or clear? what about 160?

[redcode]

This new version implements Q as described by Patrik Rak: Q is a copy of the final value of F if the instruction modifies the flags; otherwise, Q is 0.

However, we will add a new "qff" flip-flop field with the old behavior for those implementing Q as a boolean flag.

Stay tuned.

[samplx]

@redcode thank you for the additional information.

I plan on updating my code, so you don't need to add the "qff" flag for my benefit.

As far as I am concerned, we can close this issue. I didn't know if you wanted to keep it open to track changes.

[redcode]

Thanks. I promised a friend I would add "qff", so I will keep the issue open until I do so.

[Binarynova]

The README and the above linked conversation don't really clarify how Q is to be handled to pass tests.

I first I thought it was just "Q = F if F was modified by the opcode".

My implementation:
if (afterOpcodeF != beforeOpcodeF) then Reg.Q = Reg.F;
but this fails four tests for opcode 0x04 (INC B).

Reading the above conversation, and referencing the wiki here it's really unclear to me how any of this affects a single-step test of one opcode. How were Q "Initial" and "Final" states determined?

[redcode]

My implementation: if (afterOpcodeF != beforeOpcodeF) then Reg.Q = Reg.F; but this fails four tests for opcode 0x04 (INC B).

• Instructions that affect the flags copy the final value of F to Q, regardless of whether the final value of F is equal to or different from the initial value of F.
• Instructions that do not affect the flags, including ex af,af', pop af, internal NOPs and interrupt responses, set Q to 0.

Reading the above conversation, and referencing the wiki here it's really unclear to me how any of this affects a single-step test of one opcode. How were Q "Initial" and "Final" states determined?

By taking Q before and after the test is run on the generator.

[samplx]

I think the confusion is about does versus can.

An Increment instruction can affect the flags, so Q gets set, for all increment instructions.

Your implementation checks if the increment instruction actually does change the flags for a given instruction's execution.