`in (c)` is documented

[fghsgh]

I quote um0080 page 296 (310 of 332) (it is not listed however on page 62 (76 of 332)):

| Flag | 110 | Undefined op code; set the flag

as well as ps0178 page 20 (16 of 36):

if r = 110 only the flags will be affected

as well as this original-seeming 1977 "technical manual" page 54 (60 of 83):

if r = 110 only the flags will be affected

Therefore, Zilog has acknowledged and documented that this instruction exists, and it should probably be marked as documented on the opcode sheet? I.e not with red background.

However, they have not specified the mnemonic for this instruction. Maybe that is what "undefined op code" is supposed to mean? In any case, they did not mention anything about it being undefined in the older documents, so clearly it must be guaranteed this is its actual function.

[deeptoaster]

I'm reading from um0080 that it's "undefined" in the sense that some C++ behaviors are "undefined," where the behavior isn't necessarily intentional or guaranteed but more the acknowledged result of an implementation detail (the easiest way to wire up the other opcodes as intended led to 110 affecting only flags). I feel like it's fair to call it "undocumented" in that sense, even though it's not like Zilog is going to ever change it at this point.

[fghsgh]

Why does um0080 have priority over ps0178 here? ps0178 is the official Zilog datasheet, and it simply says what the instruction does without saying anything about it being undefined.

I think ps0178 says it is very clearly guaranteed to always be the case (and not just incidentally due to an implementation detail), and um0080 is vague and up-to-interpretation about it. This is unlike actual undocumented opcodes like SLL, which aren't listed at all in either of them.

And, of course, the Z180 manual lists it too.

That being said, it is a special case, as Zilog doesn't specify a mnemonic for it. So that part of it is still unofficial. It's a weird case. Leaving it with red background makes some sense.