When you look at this block diagram you can see a 'Predecode Register'

Block diagram of 6502

I suppose that the Opcode is already a 8-bit Number (D0-D7). So what was the purpose of the Predecode Register. Did it really decode something?

  • My guess: the opcode can't be allowed to change while the command is running, so it's simply buffered in the register. – Zac67 Oct 11 '17 at 20:30
  • 3
    Could you also provide the full diagram (by reference if required)? Otherwise my guess is just that decoding probably takes more than the amount of time that the data is on the bus, which is something like a quarter of a cycle if memory serves. – Tommy Oct 11 '17 at 20:40
  • I have the same instinct as Zac67. It feels like a buffer/latch to lock the value of the opcode before decoding. – Geo... Oct 12 '17 at 2:53
  • But there is also the Instruction Register, which hold the current command. – mondlos Oct 12 '17 at 4:48
  • 2
    The 6502 has a limited form of pipelining where it fetches the next instruction on the last cycle of the current instruction. Thus the PD register would be needed to latch the next instruction while the IR is still holding the previous one and controlling the final cycle of execution. – George Phillips Oct 12 '17 at 17:41

I suppose that the Opcode is already a 8-bit Number (D0-D7).

Yes, like any other data byte.

So what was the purpose of the Predecode Register.

The Predecode register is loaded with each (read) bus cycle. Effectively being a duplicate of the data latch (DL). In a general way it's the much cited 6502 pipeline, as it loads the byte fetched, during the last cycle of an instruction (usually the one doing the work). Here it gets stored for one cycle to be fed into the instruction register at the beginning of the next cycle.

Did it really decode something?

No. That's what the Predecode Logic (to the left) is good for. Also that decoding is limited to detecting single byte instructions with the purpose to stop the PC from incrementing during the first cycle of a one byte instruction (that is why the opcode of the next instruction gets fetched twice). It detects all x8 and xA opcodes plus whatever irregularities exist (RTI, RTS).

So basically PD and Predecode Logic are pipeline and pipeline/fetch control of the 6502.

In addition, the Predecode Logic is where the pseudo BRK gets 'injected' to handle an interrupt. Not a real 'injection' of a full byte, as it's done via the clear input of the IR.

Edit: If I understood it correctly, according to this forum post, the Predecode Register isn't really a register but a latch which stores only 1 Bit at a time and passes it to the Predecode Logic.

Looking at that post, I can't really find any claim about something serial. It basically describes the same as here.

  • Sorry for asking the same question, but that would mean that the Predecode Register is an actual register with a size of 8 Bits and not a latch? – mondlos Oct 12 '17 at 18:29
  • Not sure what your reasoning here is. The value at D0..7 will be latched into PD at the rising edge of PHI2 everything else doesn't make any sense. Does it? – Raffzahn Oct 12 '17 at 19:11
  • 1
    Again: IT IS NOT BIT SERIAL. Why on earth should it? – Raffzahn Oct 12 '17 at 19:15
  • 2
    @mondlos Erm, I'm a bit confused. Your asking about 6502 internals and you're not aware that Phi2 is the basic clock signal used across the CPU (and ints perhipherals)? Further, if you don't understand latching vs. registers, you might want to ask that on electronics.stackexchange - or try some beginners course for digital electronics. – Raffzahn Oct 12 '17 at 19:18
  • 2
    Latches and registers are both made from flipflops. The term Latch or Register doesn't imply any size. A register can be one bit and a latch can be 16. The difference is when they accept input and when this is reflected as output. A latch features an enable input and all data is routed transparent to output until the enable is released. After that the output stays. A register outputs a previous loaded input until the next is loaded at a specific time (clock pulse). The decision of using a latch or register depends what outputbehaviour is wanted. – Raffzahn Oct 12 '17 at 19:23

The Predecode register just holds the opcode which was fetched, as you have seen. The opcode which is about to be executed has already been loaded into the predecode buffer during the execution of the previous instruction. It does not decode anything just of itself; registers don't do anything like that. It just buffers the opcode until the time when it might be needed. The reason this value must be buffered in this way, and not sent straight into the decoding ROM is because:

  • an interrupt might get serviced at this point.
  • the previous instruction may not be done executing yet.

So what the predecode logic does is either load the opcode from the predecode register if no interrupt happened, or the byte $00 if an interrupt did happen. That byte is the BRK opcode, which invokes the interrupt handler. (This is incidentally the reason behind the bug where a hardware interrupt "swallows up" a software interrupt.)

That hopefully explains why the opcode has to be buffered in that predecode register before it may be executed.

  • So you think the Predecode Register has a capacity of 8 Bit? – mondlos Oct 12 '17 at 16:22
  • 2
    It's 8 bit wide and basicly a duplicate or the input data latch. Each byte loaded, no matter if it's an opcode, parameter or data, is moved into PD. – Raffzahn Oct 12 '17 at 17:44
  • @Raffzahn so then whenever the previous instruction finishes, it raises the signal to load PD into the predecode logic? How does this arrangement work with RESET? – Wilson Oct 13 '17 at 5:34
  • @Wilson No, the PD is loaded with each Phi2. It's just the last byte read, which happenes to be the next instruction during the last cycle of the previous. It gets copied into the IR one cycle later. Reset is an interrupt and gets handled by the predecode logic by inserting a BRK into the IR. except it's one the CPU usually never returns from :)) – Raffzahn Oct 13 '17 at 7:06
  • @Raffzahn so why not just copy from the input data latch into IR when an instruction ends, and just dispense with the PD? – Wilson Oct 13 '17 at 7:55

Registers by themselves don't decode anything. Instruction decoding, as is apparent from the full diagram, happens in two stages: Predecode logic; then the Decode ROM. There must be a register before each stage to ensure that the inputs to the circuit it feeds is stable while the signals are propagated through the logic. The Instruction Register between the Predecode logic and Decode ROM is likely wider than 8 bit.

The Decode ROM is marked 21x130, and 130 is written on the outgoing arrow, so it is apparently 130 bit wide, but it is unclear how deep it is.

Decoding directly from 8 bit to (alleged) 130 would take either too many levels of logic, requiring to lower the clock frequency, or too large a ROM to fit on the chip. Hence the decision to split the decoding scheme into two clock cycles.


If you look at the Visual6502 simulation in advanced mode, you can see the predecoder latch and predecoder logic on the very right side near the top, diagonally below the decoder ROM that stands out with its regular pattern at the top. The Visual6502 signal names contain the lines pd0 to pd7, associated pd*.clearIR clear lines, and also the predecoder output lines

// internal signals: predecode latch partial decodes
"PD-xxxx10x0": 1019,
"PD-1xx000x0": 1294,
"PD-0xx0xx0x": 365,
"PD-xxx010x1": 302,
"PD-n-0xx0xx0x": 125,

So the predecoder does really decode something. I haven't looked at where those lines go, and why they are needed (possibly because otherwise timing wouldn't work, as getting those signals from the final decoding ROM would be too late in the cycle), but with a bit of time investment into the netlist and the Visual6502 representation it should be possible to find that out.

  • I've not fired up the simulator on a large enough screen to let my feeble eyes watch all the details, but I think there are a number of places where, instead of using passive pull-ups, the 6502 drives a signal unconditionally high on one clock phase and then conditionally drives it low on the other. I don't know if the "pre-decode" does that, but if a one-phase switched pull-up is smaller than a passive weak pull-up I would think such an approach could be helpful with the decide ROM (which would otherwise need a lot of passive pull-ups). – supercat Oct 14 '17 at 15:29
  • Now the predecoder does decode something. It works out if the instruction is a single byte or not (this information is somehow fed to the PC, to keep it from incrementing too many times or something). But the predecode register does not decode anything. – Wilson Oct 16 '17 at 9:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.