Ttdfjt

From the Wikipedia's 65CE02 page:

Internally, the pipeline of the 65CE02 was redesigned to reduce the
number of cycles required to execute an instruction. The 65CE02 can
recover faster from engagement of the SYNC signal, which reduces the
minimum instruction execution time from 2 cycles to 1 cycle.[3] These
improvements allow the 65CE02 to execute code up to 25% faster than
previous 65xx models.[2]

Are the two points, "internally... redesign" and "recover faster" one and the same, or two different things?

IIRC, SYNC is the result of an opcode fetch, not the cause of it. But the way this is worded suggests the CPU was waiting on SYNC to stabilize or something?

Can someone clarify what the original issue is and what they did to address it? This seems pretty major and I'm curious if this was something that could have happened in earlier generations.

The two points are the same. The signal on the SYNC pin is neither the result nor the cause of an opcode fetch; it's internal signals in the chip that cause both the SYNC pin to go high and the data from the next memory fetch to be treated as the next opcode to execute. The Wikipedia article and the referenced patent are both talking about this separate internal "SYNC" signal, similar to but not the same thing as what appears on the SYNC pin.

The original 6502 always did a memory access (read or write) with every clock cycle, and always took at least two clock cycles to execute an instruction. For multibyte instructions it would normally set up things internally so that as it was reading the last byte, the next memory access would read the next instruction and load it into the appropriate internal CPU latches, where it would be ready to execute as soon as the current instruction had completed executing.

Single-byte instructions, however, still took two cycles so the second cycle would read the next byte but, since that wasn't further data for the current instruction, what was read would just be ignored. On the subsequent clock cycle (the third since the instruction had been read), the same memory location that had just been read would be read again, and this would load the internal latches with the next instruction to be executed.

A good example of this can be seen in the first example in jsbeeb Part Three - 6502 CPU timings.

1. Cycle 2 reads a TAY (transfer A to Y) instruction from $0002 that takes no arguments.


2. Cycle 3 reads the subsequent instruction, CLC (clear carry), from $0003 but the read data are ignored by the CPU during this cycle as it executes the TAY.


3. Cycle 4 re-reads the CLC from $0003, loading the internal chip latches to execute it on the next cycle.

Clearly this could be done a bit more efficiently by changing the internal signalling to understand that, when cycle 4 comes around, the CLC has been loaded already (and presumbably the data read has been stored in some appropriate internal latches) and so that can be executed now, without re-reading it, and the memory controller can continue on reading the next byte from memory. That's what the patent describes.

And yes, this probably could have happened in earlier generations; it's basically just improved pipelining. However, it does seem to add not-insignificant extra logic, where part of the point of the 6502 was its very low transistor count for its relatively good feature set.* Adding such a feature later (when it's cheaper to do so) introduces the usual problem where changing timings breaks some existing software (games, drivers, copy protection—anything relying on tricks using timing) thus making it less useful as a substitute in existing microcomputer systems.

*For example, the 6502 had significantly more indexed addressing modes than the Intel 8080/8085, despite having not much more than half the transistor count.