The predecessor 6502 did not use microcode, but a PLA. But what about the 6510 and 8502?

  • 4
    I think you might need to define what you mean by microcode. I think I could build a case to suggest that the 6502 did use microcode of a sort.
    – JeremyP
    Commented Jul 18, 2023 at 8:05
  • 1
    As far as my understanding is correct, microcode comes from a storage like ROM or Flash and has to be loaded in order for the CPU to be usable. On the other hand, if the decoding unit is hard-wired as a PLA, then the CPU works right away.
    – Coder
    Commented Jul 18, 2023 at 8:19
  • 3
    I don't understand how we can say the 6502 did not use microcode, but I have heard that before. From what I understand, the 6510 and 8502 use the same die as a 6502, just a little extra support circuitry in the same package. That would mean they are the same in every respect, even down to illegal instructions. Commented Jul 18, 2023 at 8:19
  • 7
    If you follow the Wikipedia definition of microcode ("hardware-level instructions that implement higher-level machine code instructions or control internal finite-state machine sequencing"), then the 6502 very much uses microcode. That the microcode is generated by a PLA and not a ROM doesn't matter. So you really need to define what you mean by "microcode" in the context of your question. And no, microcode doesn't has "to be loaded" - there are lots of CPUs which uses microcode right from the ROM.
    – dirkt
    Commented Jul 18, 2023 at 9:33
  • 5
    Whether or not microcode needs to be 'loaded' is an implementation decision that does not affect whether it can be called 'microcode'. The sole determinant is whether the microcode operation is set by 'programming' a more general-purpose device,or set by explicit wiring.
    – dave
    Commented Jul 18, 2023 at 11:44

2 Answers 2



The 6510/8502 are the very same CPU (*1) as the 6502. No difference in implementation.


The predecessor 6502 did not use microcode, but a PLA. But what about the 6510 and 8502?

The 6510/8502 are the very same CPU (*1) than the 6502. The changed pinout and additional peripherals doesn't change that in any way.

As far as my understanding is correct, microcode comes from a storage like ROM or Flash and has to be loaded in order for the CPU to be usable.

Same here, as a PLA is a ROM (*2). Every PLA can be replaced by a classic ROM and vice versa (*3). The main, but not principal difference is that a PLA's decoding is the primary mean of configuration, while regular ROMs configure the output. Doing the programming on decoding side allows to 'compress' redundant content by encoding duplicate entries only once and encoding multiple output bits by multiple entries (when needed).

That topic was already covered in part in this question.

On the other hand, if the decoding unit is hard-wired as a PLA,

A micro program ROM 'hard wired' the very same way as a PLA.

then the CPU works right away.

Which is as well true for a micro coded CPU - as long as the microcode is present at startup, which is true for all micro processors (*4).

Here might lay some confusion due modern CPU which allow to load additional/modified micro code at startup. Those CPUs do quite well start up and work right away (*5) as their micro code is already contained in ROM. That is best shown by the fact that loading additional micro code is done by a regular program in the main instruction set.

The ability to load additional microcode adds flexibility but doesn't change the instant on ability.

The ability to load additional microcode is intended to patch bugs an add new features after the CPU was delivered.

Is the 6502 Microcoded?

Yes, as it follows the very primal requirement of micro code of being executed by stepping thru a stored program (*6). It doesn't matter how that program is stored, as long as it's stored. The fact that the ROM content is a single bit and that multiple entries can fire in the same step is purely representational and doesn't change this.

The space saving beauty of the 6502 is that it combines the high density of ROM structures with low requirement of routing - back then routing space was way more expensive than transistors (*7).

In the end it's another embodiment of why the 6502 was such a great advancement in CPU design over more school book inspred CPUs.

*1 - I guess in today's ligo MOS would talk about them using the same core.

*2 - In some way one may see a PLA as an inverted ROM and working as assoziative memory (contend addressable memory).

*3 - Just note the various times ROMs are used, especially in the Commodore world, to replace no longer available PLA.

*4 - Well, almost, as there were a few designs, usually bit slice, which did load micro code first using some external CPU.

*5 - Unlike some /360 models, which not only pioneered loadable micro code but that code had also be loaded first from a service unit before the CPU could start.

*6 - In the 6502 the clock logic generates up to 8 steps (T0..T6) per instruction which in turn are used to sequence the PLA entries during execution. Although, the sequence isn't as simple as some states are inserted depending on instruction process. Another ingenuity saving entries and circuitry, but also making interpretation harder. One has to really follow it thru :))

*7 - Not saying they were plenty :))

  • 2
    I think this discussion news.ycombinator.com/item?id=23554713 is useful, noting the supporting photo link. Also comp.sys.cbm.narkive.com/yXTim3UH/6502-microcode-pla-equations particularly the contribution of "Allan" half way down. The bottom line is that the PLA- visible at the top of the cited photo- is "horizontal microcode" by normal industry standards. "horizontal microcode" also, of course, includes the sort of stuff you'd put in a microcode ROM for a bitslice CPU, as IIRC discussed in "Soul of a New Machine". Commented Jul 18, 2023 at 17:28
  • 1
    If I understand Wikipedia's (both the German and the English one!) definition of the word microcode correctly, it is not sufficient that the logic table of a gate is stored in a ROM (similar to an FPGA where the logic tables are stored in SRAM). If I understand correctly, the word "microcode" implies that one assembly instruction triggers (or can at least trigger) a sequence (this means: two or more) of microcode-level instructions which are executed sequentially. Commented Jul 19, 2023 at 17:02
  • 1
    @MarkMorganLloyd: I don't think the fact that some of the 6502's logic is laid out in PLA format really makes it microcode. If one looks at e.g. Atari's STELLA chip, the address decoding is all done with a PLA-style layout, but one would hardly call that microcode.
    – supercat
    Commented Jul 20, 2023 at 16:21
  • 1
    @Raffzahn: The 8086 microcode engine can branch among 512 states. If the 6502 had e.g. processed all of the addressing modes abs,x, abs,y, (ind),y by branching to a common state after the MSB of the address was fetched, so as to use common logic for an "add an index register chosen by a particular opcode bit to the effective address" cycle, then I would view it as a microcoded architecture, but from what I can tell the operations for cycle 4 of abs,y versus cycle 5 of (ind),y are handled independently, Very different from the way the 8086 branches through states during EA calculations.
    – supercat
    Commented Jul 20, 2023 at 19:38
  • 1
    @Raffzahn: If the 6502 was "microcoded", do you think any meaningful amount of "microcode" was written after the surrounding circuitry design was complete, or was each column of the PLA added with the particular intention of it testing for a particular combination of high, low, and don't care bits?
    – supercat
    Commented Jul 21, 2023 at 15:34

No, the 65xx and 85xx chips did not use microcode.

Microcode is the term used to describe an internal CPU programming paradigm in which the low-level microprocessor 'machine-code' instructions are themselves comprised of even lower-level 'private' instruction primitives. These primitives are almost RISC-like, generalised (to an extent) and permit the manufacturer to construct the 'public' instructions which represent, for one example, the x86 instruction set. When asked to execute an x86 instruction, the chip actually executes the set of primitives that comprise that instruction.

This has great advantages over static PLA-based microprocessors, since the internal instruction execution pipeline circuitry design can more generalised - instead of hard-wired instruction-specific decode/execute circuitry, the chip can be built with non-specific circuitry intended to execute primitives which can be put together in myriad permutations. This makes debugging much easier, and of course (given mutable microcode storage) allows changes to be made to the microprocessor instruction set long after the microprocessor is made available for commercial use.

The MOS 65xx and 85xx family of 8-bit microprocessors used hardware circuitry to decode and execute their instructions. Some very clever design facilitated a degree of circuitry re-use between instructions, and even a rudimentary pipelining effect where the next instruction could be in the fetch register before the previous one had completely finished execution. However, there was no microcode involved - this was all hardware, driven by the physical bit-pattern of the 8-bit instruction opcode. An internal T-state counter progresses the instruction fetch/decode/execute pipeline, but is not a program and does not constitute microcode.

The so-called 'illegal' or 'undocumented' opcodes are a direct manifestation of the hardware-dictated operation of the 65xx/85xx instruction set, since they are instances of bit-patterns which engender unsupported circuitry behavior. Unsupported in this context means 'the manufacturer did not explicitly design this instruction and therefore the bit-pattern is not guaranteed to produce meaningful or useful results'. However it is interesting to note (well, for us 65xx/85xx greybeards) that a number are genuinely useful, though some are pretty obscure in real-world use and a few are actually electronically unstable and do not produce deterministic results from one execution to the next.

  • 2
    Erm, "execute primitives which can be put together in myriad permutations." Isn't that the very definition of microcode? Also "The so-called 'illegal' or 'undocumented' opcodes are a direct manifestation [thereof]" Same is true for the 8086 (see for example 6x vs. 7x), which everyone will agree is a prime example for microcoded.
    – Raffzahn
    Commented Jul 18, 2023 at 9:21
  • 2
    @Raffzahn Re. your first point, erm yes that's exactly what the paragraph is saying - that microcoded architectures benefit from generalised circuitry which enables primitives to be assembled in lots of different ways to create higher-level instructions. Re. your second point, I did not say that microcoded architectures did/do not experience anomalous hardware crosstalk or misfiring decodes, only that the 65xx/85xx architecture illegal opcodes are explicitly a result of that. Commented Jul 18, 2023 at 10:44
  • 3
  • 2
    The 6502 has lower level generalised hardware e.g. an ALU, some registers, some buses. The PLA takes an input which is the instruction and certain parts of the CPU state and produces outputs which would control the various components. It was definitely programmable (the P doesn't stand for "pizza"). Therefore we have microcode of sorts. As is often the case, the boundary is quite fuzzy.
    – JeremyP
    Commented Jul 18, 2023 at 14:13
  • 2
    People may draw boundaries between "array logic" versus "microcode" in different ways, but I think I'd draw it based upon whether a control logic supports branching between sequenced steps. From what I understand, the only form of "branching" within the 6502's sequencing logic is "go back to start".
    – supercat
    Commented Jul 18, 2023 at 16:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .