Is there an illegal opcodes list with lengths and cycles?

Is there an undocumented opcodes list with byte lengths and cycle count?
I don't need to know how the actual instructions work or what status flags it affects, as I don't plan to implement any undocumented opcodes, but In the case that an undocumented opcode is found I want my emulator be able to just skip it correctly and hope it won't disrupt (much) the game execution. (instead of just halting)

http://www.oxyron.de/html/opcodes02.html

Byte length is determined solely by addressing mode, so...

This rule of thumb works well for most things, but BRK and maybe some multi-byte NOP instructions are a little bit unintuitive this way.

To expand on rainwarrior's comment a little more: unofficial opcodes that are "effectively" the same as NOP, but usually do not take 2 cycles like the real NOP -- instead, they tends to vary given what the CPU is actually doing under the hood.

There is also no official notation for illegal opcode mnemonics. People will tell you "ca65 has them as blah blah blah", but that isn't official (don't let them convince you otherwise). So if you're going to print them/show them in a debugger or something like that, I tend to recommend you just display them as "???" or things like ".db $xx" statements, since there's no standard.

P.S. -- In your emulator, you should implement this as a toggleable feature to stop/halt the emulator if an invalid opcode is encountered, or to skip them. Skipping may be tricky given the aforementioned cycle concerns (I'm not sure if any of the games which use illegal opcodes are "timing-sensitive" or not).

BRK I'll grant, even though it's not an undocumented opcode, but the NOP(/IGN/SKB/SKW)s are still determined by addressing mode. It's just that it feels odd to have a do-nothing that takes an argument; hence the alternate mnemonic "IGNore".

What use would anyone have for skipping illegal opcodes? There'd be zero expectation that the code would run correctly after the skip (timing isn't even remotely a concern at this point). It also wouldn't match the behaviour of any 6502-compatible hardware... What would this be for?

(i.e. if you want to leave them unimplemented, the method you do it is pretty much irrelevant. There's no "correct" way to skip an instruction.)

Right, thanks!

Good idea.

Well the expectation that the code would run correctly is certainly not 100% but it's not 0% either. Interpreting illegal opcodes wrongly or not at all could have, in some occasions, no adverse effect on the flow of the program or may have a recoverable effect, like say, drawing some garbage to the screen but still not disrupting the flow. I mean, I know it's not ideal, but any glitch, even the most awful ones are not worse than just halting the emulation.

You're right, what I meant by correct is at least knowing how many bytes to skip in order to interpret the following instruction correctly and not landing on a 2nd or 3rd byte of the next instruction which would really break many following instructions.

Sure, keeping the instruction lengths correct would be more likely to keep you in a recoverable state, though just treating every unknown instruction as a 1-byte NOP is somewhat effective toward the same goal. If the instructions aren't implemented, a warning to the user when the first bad opcode is hit at least would let them know that behaviour past this point is not expected to be correct.

I suppose implementing just the lengths is a mostly correct implementation of all the NOP instructions, at least. The Wiki has a very short list of some games using illegal opcodes, and a lot of them are just using nonstandard NOPs.

Oh yes, totally.