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.
