It appears that my other thread, on designing a debug/bootstrap interface for my project, got derailed somewhat by inaccurate observations about some of the support logic I sketched as part of figuring out the details. So since people seem to be ever so interested in the minutiae of the RDY pin, here's a thread for discussing that specifically.

It turns out that the best support logic is different between three general classes of 6502-family CPU and three levels of functionality - which are not identical sets.

Most people will, at best, use RDY only to indicate to the CPU that they have some slow ROM or other device that needs more than one Phi2 cycle to access. This is easy to support on any of the CPUs by simply ANDing the RDY signals from individual devices (if there's more than one) and driving the RDY pin of the CPU through a current-limiting resistor. If the CPU pulls RDY down to indicate that it's executed a WAI instruction, a few milliwatts will be dissipated in that resistor. If you're definitely using a CPU that doesn't have the WAI instruction (meaning NMOS CPUs and some of the older CMOS devices), you can dispense with the resistor and drive the pin directly.

The first two diagrams in the series below show this in practice; the 65C02 circuit can also be used with the 65816 if required. If you don't even need that level of RDY support, just pull RDY up with that same resistor (or bare wire, if appropriate).



But if you're concerned about power consumption, say because you intend to run your homebrew machine off solar power and/or small batteries and you expect only intermittent CPU activity, you might want to detect when WAI happens and eliminate all unnecessary power drains henceforth - starting with that resistor attached to the RDY pin. This is the purpose of the latter three diagrams shown below.

The one for the 65C02, subtitled "WAI detection", uses an XOR gate and JK flipflop to detect when the CPU pulls RDY low, assuming that all RDY-producing devices normally drive their lines high. Upon entering the WAI state, therefore, the RDY driver gate will also go low one cycle later, eliminating the power drain through the resistor. The CPU will subsequently be woken up by one of three signals (/IRQ, /NMI, /RST), and these are combined to the opposite input of the JK, restoring the RDY pull-up on the same cycle as the CPU will detect the need to wake up. As a side-effect, a SLEEP signal is produced from the flipflop, which can be used to trigger further power-saving effects elsewhere, such as switching Phi2 to the very efficient 32kHz clock from an RTC chip and powering down the main, power-hungry 8MHz oscillator; this is left as an exercise for the reader.

A simpler version can be implemented for the 65816, making use of the explicit indication of bus inactivity this CPU produces via the VDA and VPA pins, and this is the subject of the fourth diagram. Although not explicitly stated in the datasheet, I expect cycles in WAI will be treated as an indefinitely-long sequence of "internal cycles" keeping VDA and VPA low, so it's not necessary to wait for the CPU to explicitly pull RDY low; we can pull it low ourselves whenever the bus is supposed to be idle, and there will never be sustained static power dissipation through the resistor. But this version doesn't produce that SLEEP signal, so you'd need to perform any additional power-saving steps explicitly in software.

The final circuit is the moral equivalent of the third, but using the '816 bus status instead of the interrupt signals. Note that leaving WAI state may be signalled by either VDA (if fetching an interrupt vector) or VPA (if interrupts were disabled, and execution resumes at the next instruction), so both must be detected to be sure of correctly reasserting RDY in time.

Thanks for the new thread and the thorough explanation! (And kudos for sharing photos of paper diagrams - surely the most productive way to make a diagram, that or a whiteboard.)

But, are these only paper designs, or are they field tested with real hardware? (I'm only aware of one back-in-the-day volume-produced system which used RDY, but of course there might well be others.)

Only on paper at this point. I think the logic is sound, but I'd accept constructive criticism if there's something wrong after all. One reasonable question might be whether the 65816 still reacts to RDY during internal cycles, which would invalidate the fourth circuit.

The C64 was another machine that used RDY in anger - the logic for it was built into the VIC-II and was the cause of "bad lines" where fewer CPU cycles were available during certain scanlines, and fewer still if hardware sprites were turned on. Because the NMOS 6502 (including the 6510) refused to halt for RDY during write cycles, it had to be negated 3 cycles early to avoid clashing with the VIC-II's extra accesses; a maximum of 3 write cycles are performed in a row on the 6502.

Oh, of course, the C64 is a great example!

The present obstacle I have to physically testing stuff is that all - and I mean *all* - of my electronics gear went missing during a move a couple of years ago. I don't even have a multimeter or a soldering iron to my name any more. Obviously I should fix that at some point, but until I work out the theory of the design, I won't even have a complete shopping list.

Ouch!

(For some situations, simulation is a good answer, but it demands an accurate model, and of course simulating logic is a whole lot easier than simulating circuits.)

And the logic sims I've found don't really simulate timing constraints, never mind mixed-signal analogue effects as are exposed by the circuits above and RC debouncers.

Yes, simulating synchronous designs is well-understood and well-served, but it gets more difficult as you're interested in sub-cycle phenomena, and non-digital. (I did run a few cycles of a resetting 6502 at transistor level with SPICE, but it wasn't quick or convenient, and you'd need more than a few cycles of setup in many cases.)

Look at the bottom of page 44 in the November 11, 2016 revision of the '816 data sheet to see what it does when WAI is executed.

In both the 65C02 and 65C816, executing WAI or negating RDY stops the internal clock in the high phase. In the case of the 'C02, PHI1O and PHI2O are not affected (n.b., PHI1O and PHI2O are not recommended for use in new designs). With the clock stopped, the MPU does absolutely nothing—the 'C02 and '816 are static designs, so no activity whatsoever is required to maintain register state. Hence current consumption while stopped in this fashion drops to nearly zero (6-8 microamps, if I correctly recall).

In the '816, executing WAI will result in VDA and VPA being de-asserted on the second clock cycle (i.e., the cycle after the opcode fetch). That is, the statement VDA || VPA will be false one Ø2 cycle after the opcode has been fetched and continue to be false as long as the '816 remains stopped by WAI.

You should also note that the behavior of the MPU in response to a hardware interrupt following execution of WAI is influenced by the state of the I bit in the status register. If IRQs are enabled and the MPU is WAIting, an IRQ or NMI will end the WAIt and the MPU will take the relevant interrupt vector...in other words, the expected behavior when an IRQ or NMI hits. On the other hand, if IRQs are disabled (I bit = 1) when the interrupt hits, the MPU will execute the instruction following the WAI that stopped it. Latency in this case will be equal to one Ø2 clock period.

Finally, the MPU will not halt on WAI if something prevents RDY from being driven low.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

So it sounds as though the fourth circuit is indeed wrong (since VPA | VDA is also false on internal cycles besides WAI), because negating RDY stops the CPU regardless of its bus activity.

The third and fifth should still be fine though - as long as the CPU can get as far as indicating readiness to fetch something while RDY is still negated. If not, then only the third circuit is both correct and efficient.

It's certainly worth some experimentation, as WDC's documentation leaves so much to be desired.