When you look at this block diagram you can see a 'Predecode Register'
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?
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 (
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.
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:
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.
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
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.