On the 6502, the READY signal may be used to extend read cycles indefinitely, but will have no effect if asserted during write cycles. As a result, many devices that need to steal cycles from the CPU will assert READY three cycles early so that if they assert it during a BRK instruction or interrupt sequence, that sequence will run to completion and leave the bus available by the fourth instruction, though a more common scenario would be that asserting READY early would simply waste two or three cycles needlessly.

Were there any 6502-based systems that would, instead of doing that, start trying to grab the bus ahead of when they needed the data, but then use the bus as soon as it became available? A video display system that used this approach would need to be able to buffer up to three bytes that were read early, but in systems that used cycle stealing to fetch audio data, perform DMA refreshes, or perform other such one-off memory fetches that could tolerate a three-cycle delay I would think that letting the fetches happen at the first available opportunity would have reduced the number of cycles lost to such fetches.

Were there any systems that actually did that, or did all 6502-based systems that performed cycle stealing do so by either pre-asserting READY and ignoring whether the bus actually became available early, or else (Atari 400/800 series) gating the CPU clock for brief periods? It seems a waste to assert READY for four cycles to perform one memory operation, when the 6502 provides an output indicating when an instruction fetch is being performed, and the cycle after that is guaranteed to be a read.

1 Answer 1


The 6502 only uses one phase of the clock for memory accesses. The other phase can be used for access to memory for other purposes.

The Apple II used this technique. It did not use READY (although that was available on the peripheral bus).

This idle phase of the clock was used for providing the data for the the display at the required refresh rate. By careful arrangement of the addresses performed the dynamic memory refresh as well.

  • 3
    I was referring to systems which selectively stole entire cycles from the 6502, as was done for sprites and badlines on the Commodore 64, audio fetches on the NES, or from what I understand DRAM refreshes on the Apple I. The interleaved memory accesses don't require that the 6502 even be aware of their existence.
    – supercat
    Commented Dec 26, 2021 at 0:44
  • 2
    You may want to edit your question. The last statement can be read as implying that all 6502 systems use cycle stealing. Commented Dec 26, 2021 at 1:30
  • 1
    Does the update make it clearer? Systems like the Apple II don't steal cycles, since the CPU runs at essentially constant speed (every 65th cycle is 14% longer than usual for technical reasons that have nothing to do with memory access), but on the Atari the main bus runs at a constant cycle rate of chroma/2 even though some clock pulses are blanked going to the CPU.
    – supercat
    Commented Dec 26, 2021 at 19:19

You must log in to answer this question.

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