There’s something oddly fascinating about a microprocessor doing more than it was officially supposed to—like a magician who pulls a rabbit out of the hat even when nobody asked for one. The MOS 6502, a CPU that powered machines like the Commodore 64, Apple II, and NES, has a collection of instructions that don’t appear in any datasheet. These are the so-called illegal opcodes, and they weren’t added as Easter eggs or developer jokes—they’re side effects of how the processor was built. And surprisingly, some of them are… actually useful.
Michael Steil’s 2008 technical write-up broke new ground not by just cataloging what these instructions do, but by showing why they exist. He went deeper than most had dared to dig, and in the process, pulled back the curtain on how the 6502 really operates.
Instruction Decoding: Forget the Glossy Brochure
If you’ve ever looked at the official MOS 6502 block diagrams, you’ve seen a prettied-up version of reality. According to Steil, those diagrams are more marketing material than a technical blueprint. He replaces them with a more accurate picture, where decoding is handled not by microcode but by a matrix of hardwired logic called the Decode PLA.
This is essentially a lookup system: a 130-row by 21-column logic array that matches incoming opcodes and timing signals. When a match is found, a specific line gets triggered. That line activates parts of the processor to perform an operation—like loading data, changing registers, or branching. Legal instructions are grouped logically so that similar instructions share decoding lines and behaviors.
When the Weird Stuff Happens
Illegal opcodes don’t have their own designated decoding lines. Instead, they trigger a strange blend of logic lines intended for other instructions. They’re like uninvited guests who happen to press all the right buttons anyway.
Take opcode $AF. It’s not on any official list, yet it performs a very specific task: it loads a memory value into both the accumulator (A) and the X register. How? Because $AF shares bits with both $AD (LDA) and $AE (LDX). When it’s executed, it accidentally triggers the PLA lines for both of those instructions. The processor just goes with it.
This kind of opcode mashup is possible because of how compactly the legal instructions are encoded. The decoding system wasn’t built to reject every unrecognized pattern. It just reacts to whatever lines light up, meaning certain “illegal” instructions can sneak through and do real work.
The Lock-Up Codes: KIL
Not all illegal opcodes are helpful. Some are like dead-end roads with no escape—better known as the KIL (kill) opcodes. These halt the processor in its tracks, and not in a polite, press-any-key-to-continue kind of way. Once triggered, the CPU freezes. No interrupts. No progress. The only way out is a full hardware reset.
What’s going on here? Steil explains that these opcodes leave the processor stuck mid-instruction. Normally, the T cycle bit tracks which part of the instruction is being executed. KIL prevents it from resetting, so the processor can’t move forward or respond to anything.
So, Are They Useful?
Some of the illegal opcodes, like LAX and SAX, became favorites among game developers and demo coders for their quirky but practical effects. Others are just landmines. What Steil’s article proves is that these opcodes weren’t planned—they’re logical leftovers. The processor wasn’t filtering for validity. It was built to interpret whatever it got, based on electrical patterns alone.
