Should a different instruction type be returned for invalid indexed instruction prefixes?

[rzumer]

Invalid indexed instructions (i.e. instructions that have a 0xDD or 0xFD prefix, but for which no valid instruction can be decoded using the following opcode byte) ignore the index prefix and restart decoding from the next byte. This behavior is correct, but if decoding the prefix and its following instruction requires additional cycles compared to decoding the instruction without the invalid prefix, an implementation using DeZ80 may not be able to accurately calculate the length of such an instruction. If so, we should provide additional data, probably in the form of a new instruction type, such as the recently-removed Noni.

[rzumer]

It turns out double prefixes do need to be exposed. Unsure about instructions that map to no known behavior and whether or not double index prefixes and double bit/extended table prefixes behave differently, so will research before deciding how many invalid instruction types are needed.

[rzumer]

Returning a Nop (or Inva?) for the duplicate prefix might be enough. Since the original instruction bytes are stored in the Instruction structure, processors can identify "true" NOP instructions from these wasted machine cycles.

However, this might require reintroducing the Peekable requirement for the input reader...

[rzumer]

Summarizing MAME behaviour:

• an illegal indexed opcode (i.e. preceding an undocumented instruction with no side effects or another prefix) is a wasted M1 cycle, and decoding "resumes" with the opcode following the prefix. Peekable is needed to avoid skipping over this opcode.
• an illegal extended opcode (with no side effect) wastes two machine cycles (4 T-cycles total for two opcode fetches), as decoding resumes from the third opcode in this sequence.

Inva for both cases seems sane. A processor can simply check the prefix to determine how many cycles were wasted.

[rzumer]

Fixed by https://github.com/rzumer/dez80/commit/d1575846d536d5aea90816aee0ec87eaf3d220a3, but this is subject to change, since it is the only case in DeZ80 where a returned Instruction is "incomplete". The decoding cycle of an instruction with invalid/ignored index prefixes ends only when a "real" instruction is decoded (including an invalid extended instruction or an unofficial instruction). This is a bit unintuitive and incoherent, so a better solution may be to keep track of the number of ignored index prefix opcodes in the Instruction struct.

[rzumer]

Solution modified with https://github.com/rzumer/dez80/commit/14ef182d50bc89f32eb021bc23e9a10165e510f6 to add an ignored_prefixes field and decode all the way to the next instruction in a single call.