Closed omarandlorraine closed 1 year ago
The same issue affects ED C5
and others.
Also, ED 29
, ED A4
, ED 8A
, do not get disassembled correctly. So far as I can tell
Hi @omarandlorraine, sorry for the very late response, somehow I did not receive a notification for this issue.
This encoding is invalid and is semantically equivalent to
NOP NOP
. According to this resource there is no such instruction if I'm reading this right.
Instructions that are not defined in the Z80 specification are known as illegal or undocumented instructions/opcodes. Some of them do execute undocumented functions. Others, like many undocumented extended opcodes (ED prefix), don't do anything until the next decode cycle, so they behave like NOPs.
I decided to decode invalid extended opcodes as Inva
when they behave like NOPs as you described, instead of returning an error, because for some use cases (emulation etc.) there is no need to abort execution when encountering invalid opcodes; the CPU still processes them, whether it does something with them or not. You can check for the instruction type variant when you receive the decoded Instruction
to determine whether you should error out or not, if you don't want to handle illegal opcodes in your application. I could see there being a need for labeling undocumented instructions as such though, considering many of them don't get decoded as Inva
.
Also,
ED 29
,ED A4
,ED 8A
, do not get disassembled correctly. So far as I can tell
It does look like that instruction table has changed since the last time I looked at it, and some extended instructions that were previously thought to do nothing actually have some associated behaviour now. I'll look into it and add any missing undocumented instructions when I have some free time. I don't see anything under ED A4
and ED 8A
, though, so those should be decoded correctly as Inva
. If you expect something else, let me know what seems wrong.
Sorry it took me forever to get back to this, I double-checked my main reference for opcodes (https://clrhome.org/table/) and initially I thought you were right about ED 29 being incorrect, but it turns out it's unique to the Z180. Other opcodes as far as I can tell from both your reference and this grid should be correct. I'll close this but let me know if I missed something.
This encoding is invalid and is semantically equivalent to
NOP NOP
. According to this resource there is no such instruction if I'm reading this right.Still the function returns
Ok(some_instruction)
.Is it possible I've found a bug?