NOP taking many addressing modes, is that so?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
NOP taking many addressing modes, is that so?
by on (#58601)
Hi, this doc: http://nesdev.com/6502_cpu.txt cites NOP as having many addressing modes, thus taking different byte lengths and cycles.
Is that so?

In the other hand, this doc: http://www.obelisk.demon.co.uk/6502/reference.html#NOP cites NOP as having only one opcode ($EA, challenge everything, that's why I'm asking) being 1 byte long and consuming 2 cycles.

So, what's the deal?

by on (#58604)
AFAIK there is only one official NOP, the others are illegal opcodes, like LAX and many others.

by on (#58609)
The other NOPs also do memory accesses and then discard the result. Not a problem unless it happens to access an I/O register with a side-effect.

by on (#58610)
Puzznic has a two-byte nop. If you don't emulate it as a two byte nop (for instance, you treat all illegal instructions as a one byte nop), then the second byte is a BRK instruction, and that messes things up.

Is Puzznic a bad dump?

by on (#58613)
If the problem with Puzznic is not a bad dump but an actual programming error in the cartridge, it might explain why Nintendo was forced to drop NES compatibility in the Super NES chipset. It's too bad the Retrode doesn't have an NES adapter and a CopyNES needs soldering; otherwise, anybody with a cartridge could verify this.

by on (#58620)
Not many NES games used illegal opcodes, right?

by on (#58622)
Puzznic is the only NES game I've ever heard of that executes an 'invalid' opcode. I'm sure it's been redumped and verified. I don't think that single (and unpopular) game would cause Nintendo to change any plans.

by on (#58624)
Ok thanks, I will just add a Debug alarm for when an illegal opcode is executed and if that happens, then we'll see.

by on (#58625)
I thought Lolo 3 also used one of the unofficial NOPs.

by on (#58627)
Petruza wrote:
Ok thanks, I will just add a Debug alarm for when an illegal opcode is executed

And make it play this sound?

by on (#58630)
tepples wrote:
And make it play this sound?

Maybe the whole video

by on (#58633)
Remember, there are no illegal opcodes, only unofficial ones. When the NES encounters one, it doesn't stop or turn off; it does something. Put another way, if a Martian recovered a NES without any software and reverse-engineered it in its entirety, he'd make no distinction between the official and unofficial instructions. They'd all simply be things the CPU did in response to a particular pattern in the opcode.

by on (#58634)
Sure, I just call them "illegal" opcodes because that's what they are traditionally called.

by on (#58635)
blargg wrote:
Remember, there are no illegal opcodes

Only opcodes that will make your game fail Lot Check, and given Puzznic it appears even that wasn't enforced well.

Quote:
When the NES encounters one, it doesn't stop

Even for opcode $02 (KIL), $12 (JAM), $22 (HLT), $32 (STP), etc.?

by on (#58636)
They also like to call them undocumented opcodes which is probably a more accurate term.

by on (#58637)
The word "undocumented" suggests that the opcodes were intentionally implemented, and just not documented, but I don't think this is the case. They are just leftovers from the implemented instructions, and some of them happen to be useful, isn't that correct?

by on (#58638)
The terms "illegal" and "undocumented" are bad, because neither is true. You can execute them on a NES and they have well-defined effects (in most cases), and they are well-documented. That's why I recommend the term unofficial. They exist, but weren't officially documented.

tepples, KIL, JAM, etc. merely do what STOP does on other CPUs: it stops there and doesn't execute any further. Only on processors with illegal instruction exceptions, like the 68K, x86, PowerPC, etc. are there illegal instructions, because only there do such instructions yield a single well-defined action. Another fitting name on these CPUs is unimplemented instruction, or user-defined instruction, since the user can give them meaning in his exception handler, as OSes often do (for example, implementing floating-point instructions on hardware lacking an FPU).