Reading the NESdev wiki page on CPU unofficial opcodes, I see a few games use an undocumented 2-byte NOP instuction in production: Puzznic, F-117A Stealth Fighter, and Infiltrator use $89 #i. Beauty and the Beast uses $80 #i. Additionally, Dynowarz uses the 1-byte NOPs $DA and $FA.
Why would the devs do this? What benefit do these instructions provide when developing for the 6502?
One use is as a copyright mechanism. Many distributors would steal/copy programs and sell pirate or derivative copies, by changing the text strings inside the code and reordering the blocks, it was hard to prove the code had been stolen.
Placing noops of different types you could put a signature sequence which was much easier to detect and hard to hide. A particular piece of working code could be argued as an "accidental" match, but the same argument was not possible for a sequence of noops. 32 noops spread through 4096 bytes of code makes the accidental argument, 4 billion times weaker using less than 1% of extra memory.
The NES was also from the era where some sound and graphics resources were also executable code. (Typically, this worked the other way around. Identify a needed sound and listen to chunks of the binary to find a reasonable candidate.) Injecting NOPs can improve the look or sound derived from a section of executable.
Example: "One of the more-challenging aspects of the development was searching the code for byte sequences that could also be reused as sound effects data."
This causes no end of difficulties for recompiling these executables to target modern CPUs since you can either have the original instructions (with correct sounds and graphics) or you can have working instructions (with garbled sound and graphics).
I'm just speculating here, but one possible reason for using a 2-byte NOP would be if you wanted to change an existing 2-byte instruction into a NOP (to fix a bug, for instance), without changing the byte count for the instruction. (An undocumented 2-byte NOP might execute more quickly than two standard 1-byte NOPs in succession.)
You might do this to avoid changing the addresses of other instructions (maybe there's an already-prepared table with those addresses, or there's a JMP or a JSR that you can't change, or an indirect JMP where you compute an address and you don't want to have to change the computation, or there's some relative addressing that would be messed up by the change, etc.). You might also want to just patch existing machine-language code without going through the assembler (or compiler) again.
The instruction $89 on the 6502 is a two-byte NOP. Based on adjacent instructions in the opcode matrix, especially LDA #ii ($A9 ii), it would have been STA #ii, a store to an immediate value, which makes no sense. On the 65C02, this instruction is changed to BIT #ii, which almost behaves as a two-byte NOP. One hypothesis is that a programmer working on both NES projects and projects for some 65C02-based system forgot that the original 6502 lacked BIT #ii, but because the instruction does so little anyway, the programmer didn't notice any difference.
A clockslide is a is a sequence of instructions that wastes a small constant amount of cycles plus one cycle per executed byte, no matter whether it's entered on an odd or even address.
With official instructions, one can construct a clockslide from CMP instructions: ... C9 C9 C9 C9 C5 EA:
CMP #$C9 CMP #$C9 CMP $00EA (6 bytes, 7 cycles).CMP #$C9 CMP #$C5 NOP (5 bytes, 6 cycles).A calculated start address into a clockslide can be used with indirect jumps (JMP (aaaa) or LDA highbyte PHA LDA lowbyte PHA RTS) to precisely control timing, such as when playing PCM audio or sending video register changes to the PPU in a raster effect.
It's even more important on the Atari 2600, where the whole screen is a raster effect.
CMP has a side effect of destroying most of the processor status flags, but unofficial instructions that skip one byte can be used to preserve them.
For example, replace $C9 (CMP) with $89 or $80, which skips one immediate byte, and replace $C5 with $04, $44, or $64, which reads a byte from zero page and ignores it.
As LOIS 16192 mentioned, the official NOP instruction ($EA) can be inserted at random places in a particular subroutine that isn't an inner loop. This can identify authorship of a piece of code in a way similar to trap streets. But it adds even more entropy to use unofficial NOPs ($1A, $3A, $5A, $7A, $DA, or $FA), two-byte NOPs ($80 ii, $82 ii, $89 ii, $C2 ii, $E2 ii), or two-byte NOPs that read the zero page ($04 dd, $44 dd, or $64 dd). And now that NES games are manufactured with flash memory instead of mask ROM, each cartridge can have a slightly different pattern of NOPs. This can help identify exactly which copy of a game was leaked to the warez scene.
As with clockslide, watermarking can also be done without unofficial instructions. But because of the cost of copying a mask ROM, this sort of watermarking wasn't actually used in games during the original commercial era of the Famicom and NES (1983 to 1996). It may be in use in homebrew-era games (2010 and later).
On the 6502, it's pretty common for code to use the BIT instruction to skip over bits of code; the most common usage pattern is skipping over a 2-byte instruction using a 3-byte BIT, but the approach could also work skipping over a one-byte instruction with a 2-byte BIT. For example:
EnterWithCarrySet:
sec
db $24 ; Bit ZP
EnterWithCarryClear:
clc
MainEntry:
The only effects of the BIT instruction are to perform a read of the indicated address and update the Z and V flags. In most cases, setting the flags will be harmless even if it's not particularly desirable. The ABS and ZP forms of "NOP" are similar, except they can be used in cases where it's desirable to leave the flags alone. Additionally, there is "NOP immediate" instruction which fetches the byte following the opcode but does not perform a subsequent access to the location indicated thereby, thus saving a cycle.
It's more than 30 years since I don't develop anything for a 8 bit computer, and specifically for a 6502 processor, but recompiling as we understand it nowadays it was not possible. You had to code right on the memory addresses, and moving blocks of code was a feature that only advanced tools had.
Sometimes I left 'gaps' between pieces of code filled with NOPs just in case you need to code something in the middle. The problem was when you did not have enough 'gaps' or because of performance restrictions several NOPs could impact in the overall performance of your game. Then I started to play with non documented instructions until I was able to adjust performance and 'gaps' for example.
Maybe those guys had the same problem I had when I developed for Oric computers...
NOPs are used for synchronization of IO in many 8-bit architectures that lack more sophisticated instructions and a capability to control the bus effectively.
Examples include a lack of wait states for memory or IO, serial communications, lack of direct memory transfer, etc.
Cartridge based systems are rife with NOPs, as are devices that have need of user input devices, such as a controller.
In x86 serial communications, a popular macro that included NOPs was called "punt".
