How MOS 6502 Illegal Opcodes Work (2008) | Hacker News Reader

How MOS 6502 Illegal Opcodes Work (2008)

pagetable.com

82 pointsingve17 comments

My understanding is that in the 6502 (NMOS) chip, those other opcodes had undefined behavior, and you might crash if you executed one. So you'd need to know who was the manufacturer to be certain that opcode X was available.

In the CMOS version (65C02), illegal opcodes are treated similarly to NOPs--they don't crash, and don't do anything other than spend cycles--with the caveat that certain of these "illegal" opcodes have specific numbers of cycles and bytes that they consume which are different from other illegal opcodes. More confusingly, there is an actual proper NOP instruction (0xEA), which consumes the one opcode byte and two cycles, which exists in both the CMOS and NMOS version of the chip.

So some of the illegal opcodes are just like NOP, and eat one byte and two cycles; some eat two bytes, and 3 or more cycles; and there's at least one which not only eats 3 bytes, but eight (GASP!) cycles.

Source: if it's possible for one to consider MOS emulation a hobby, then let's say it's a hobby of mine.

I copied the 6510 illegal opcode behaviour for the SY6502A emulator for my BBC Micro, and I've yet to see a problem from it. If they didn't all have the same PLA, then perhaps the differences didn't cause any useful effects...

(Some BBC Micro games definitely do use illegal opcodes, but I didn't take very careful notes when I was writing ver 1, rather a long time ago. For the current version, I just made sure the Lorenz 6502 test suite ran to completion.)

Yep. And some implementations -- like the Rockwell 65C02, or the later WDC 65C816 -- added new instructions using the previously undefined opcodes, so it wasn't even safe to assume they were all no-ops.

Can that be true? (I'm channelling 1985 here, so I could be well off, but...)

IIRC, some of the janky stuff I did on the Apple //e 6502 did run on the Apple IIc 65C02. I'm pretty sure they didn't fall of into NOP-land. (Again, I could be mis-representing this, but I was taking some shortcuts at one point to accelerate some graphics that ended up in a Broderbund game, so I don't think I am? (Time wastes all memories - I could well be wrong))

Ah-ha, well! There are actually two Apple IIe models. (Well, there was a third "platinum" one too, but let's not talk about that.) One would have shown "Apple ][" at boot time, and this was the original model with a 6502 NMOS-based chip. But they later released an "enhanced" model, which had a 65C02 CMOS chip. You could tell the difference because the later model would have instead shown "Apple //e" when booting.

It's quite possible (perhaps because you typed it as Apple //e!) that you were actually working with that 65C02 variant, and thus, your janky stuff was forgiven by the Gods of Early Personal Computing (blessed be).

(See: https://en.wikipedia.org/wiki/Apple_IIe)

I did not know that! I think it said //e on the case and ][ when booting, but I'll have go dig it out of storage. (You'd think that after spending thousands of hours in front of the dang thing, that I'd remember...)

This article reminded me how long it's been since I saw the word 'disassembler' anywhere. (IIRC, it started disappearing from common use at about the time the 16-bitters became popular.)

I guess you're referring to the word's replacement with "debugger" or "ICE" in parts of the microcontroller world? In the desktop/mobile x86/ARM world both the word and the tools are still in quite common use in fields that rely on it like malware analysis and general RE - IDA and Radare both have "disassembler" front and center in their naming and UIs.

Barely an hour goes without me looking at a disassembler output, usually while debugging something (using gdb), or else checking what the compiler has done to my code (often on Compiler Explorer)

I still use a disassembler daily to figure out how things work, so it's not completely gone…

The article says, "While other CPUs from the same era used microcode to interpret the instruction, the 6502 had this 130×21 bit PLA."

The 8080 and Z80 did not use microcode; it was all ad-hoc random logic.

I found the rearranged table of opcodes here [1] to help understand how instructions get decoded without getting in depth with the PLA dumps.

[1] https://wiki.nesdev.com/w/index.php/CPU_unofficial_opcodes

Somewhat similarly the various "chairs" generated by 7447 for 0xA-0xE are simply the outputs that lead to simplest random logic that implements the defined function.

I don't understand how the PLA can be 21 bits wide. The diagram seems to show 8 ON bits, 8 OFF bits, and 6 timing bits, which adds up to 22 bits. Any clarification?

It's a simplified explanation.

http://visual6502.org/wiki/index.php?title=6507_Decode_ROM

> Note that the lower two bits are always XX - the decode ROM doesn't actually check these, but check a cooked version of these bits instead.

Comments below the article are priceless (not the HN ones)

Was this the same concept used against Pay-tv pirates that were running smart card emulators?

Reply on news.ycombinator.com