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.

  • I'm not a 6502 guru, but I would read it as meaning the 65CE02 releases the SYNC signal faster than the original 6502, and therefore avoids waiting for a clock cycle before reading the next opcode, which reduces the minimum execution time to 1 clock cycle. If propagation delays in the logic meant that SYNC was originally asserted for 1.01 cycles, that would prevent instruction fetches on successive clock cycles, but reducing that to 0.99 cycles would make all the difference.
    – alephzero
    Jul 15 '19 at 14:53

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.

  • "And yes, this probably could have happened in earlier generations; it's basically improved pipelining." - and by that I assume this is a design-time issue in the decoder (etc), not something that would be physically difficult due to timing considerations or process? Jul 15 '19 at 20:08
  • @MauryMarkowitz It's hard to say; I don't know chip design at that low a level. I don't see anything obviously difficult about this, however; it seems mainly a matter of adding extra signals, logic and latches (such as the PRESYNC signal and predecode latch shown in the patent) to allow this extra pipelining.
    – cjs
    Jul 16 '19 at 3:44
  • 1
    @MauryMarkowitz No, it wasn't difficult at all and could have been done already with the first 6502. Except, they tried to minimize the transistor count as that was at the core of their strategy, making the chip as cheap as possible. The issue was, BTW, already solved with the 65C02 (see the 1 cycle 'NOPs'). Just here all timing was kept compatible, as the CPU was meant as a drop in replacement and for low power applications. As drop in, it had to keep the timing exact as the NMOS to avoid screwing up timing dependant code.
    – Raffzahn
    Jul 16 '19 at 7:20
  • Facinating @Raffzahn. It is then somewhat ironic that the issue was finally addressed by CBM, who one might argue had the most to lose by changing the timing. Jul 16 '19 at 13:14
  • @MauryMarkowitz That was quite visible with the C128. Then again the CE02 was made for the C65 supposed to run not only at way higher speeds but as well offering additional video modes. It was rather expected to run new, more up to date software than wasting time with compatibility. Weras the C02 was really just to enable a 1:1 transition. It's important that several magnitude more 6502 (cores) have been used in controlling/communication/consumer devices than there ever been 6502 based home computers (like 10^10 vs 10^7). Here compatibility is everything.
    – Raffzahn
    Jul 16 '19 at 13:37

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.