Hi all:

I'm in the early stages of developing a 65C816 design in which I may need to generate wait states when accessing one of the I/O devices. It seems the key to doing so is judicious use of the MPU's *RDY line.

Upon reading the WDC data sheet and studying the somewhat stilted timing diagram, my understanding of how the MPU behaves when *RDY is asserted is that if the assertion occurs when Ø2 goes high, the MPU will halt and maintain the state of the address and data lines. If this is true, it seems any address the MPU placed on A0-A15 would remain valid and the slow device would have adequate setup time to respond to R/W.

Can anyone here confirm this? Am I misinterpreting this?

I want to do the same thing, but like you I haven't yet tried it.

This message from last year indicates that RDY is simply used to gate the clock internally - the CPU won't see the rising edge of the input clock until RDY is taken high again:

I believe what he(?) was referring to was the 6502, not the 65C816. The latter doesn't have a Ø1 clock. All timing is referenced to Ø2.

This is my first crack at designing a 65xx-based system and I'm finding that the hardware aspect of the data sheet published for the '816 leaves something to be desired. The behavior of the MPU when *RDY is asserted by external hardware is poorly explained.

BTW, in perusing the 65C816 data sheet I found several errors that I referred to WDC for correction. They have updated the on-line copy as of April 30, 2009.

Hmm, I've looked at the datasheet and I think I see what you mean. I had in mind that RDY was simply ANDed with PHI2 internally, in which case it would have to be setup before the rising edge of PHI2. That was wrong of me.

Page 29 of the data sheet shows RDY being subject to setup and hold constraints on the falling edge of PHI2 - more like it's being captured and used to hold the internal version of PHI2 high. So the effective falling edge of PHI2 (for a read of a slow peripheral) would be the next falling edge that samples RDY as high. And we'd get the extra cycles to drive the data bus.

And page 52 seems to confirm that the processor acts as if it is held with PHI2 high:


(By the way, I think *RDY is the wrong notation: the external device is Ready when RDY is high)

It's good that you got WDC to correct their datasheet, and unfortunate that it was wrong. I wonder if I can find a way to highlight the differences...

Cheers
Ed

*RDY or /RDY (take your pick) is the correct notation. From the MPU's perspective, *RDY, like *IRQ, *NMI, etc., is active low. BTW, in a system where *RDY is not going to be used it should be pulled up to VCC. A 3.3k or 4.7k resistor should suffice. *RDY should never be tied directly to VCC, as the WAI instruction causes the MPU to sink *RDY and by extension, would cause the MPU to attempt to sink VCC.

*RDY, /RDY, or RDY\ would imply that you ground it when you're ready to have the processor move on. It's not that way though. You ground it when you're not ready yet and need for it to wait.

If only they'd called it *WAIT.

That snippet I pasted about the data bus being held in the data state is awkward. I think it means that the bank byte could be mis-decoded in the first phase of the second and subsequent cycles, unless RDY is brought into the clocking of the external latch. That is, the external latch has to act as if it sees the internal version of PHI2.

In addition to the point about the pullup, I think this means an external driver of RDY should be open collector, if there's any chance of the WAI instruction being used.

In our application, the CPLD which implements all the glue logic will, hopefully, allow boot from a serial EEPROM. That's probably going to be slow enough to need RDY.

cheers
Ed

I'm still mildly confused about this.

I made a mistake in taking latch to mean a transparent, level-sensitive part (I'd say flop or register for an edge-sensitive part.) What WDC have in mind is edge-triggered. But it's still true that an edge-triggered capture of the bank byte will re-capture half way through the second cycle (the wait cycle) - and won't it capture the data, causing the address decode to go wrong, potentially deselecting the slow peripheral just before the access finishes?

In our case, we're using a level-sensitive latch because the bank byte becomes valid a little earlier that way - we have more than half a cycle to do address decode even in the normal case. And I think I'm right in needing to bring RDY into the enabling of that latch - which puts stronger constraints on the timing of RDY.

Ed

Absolutely. The 65c22 VIA needs at least the CS & CS\ bits to be valid and stable before phase 2 rises. (I found that out the hard way, over 20 years ago.)

Aha! There's no substitute for experience.

(Now I see that the snippet I pasted does explicitly say transparent latch, which makes me double extra wrong. Although it also mentions the rising edge, which is what stuck in my mind.)

Of course, we're now well off-topic.

My original question was (still is) does the address bus continue to reflect a valid address, assuming *RDY is asserted to generate a wait state? There's no question that the data bus remains valid if *RDY is asserted when Ø2 is high. However, a careful read of the '816 data sheet doesn't clarify what happens to the address lines under the same conditions.

Now, if the address lines AND data lines stay valid following the assertion of *RDY, then nothing special needs to be done. Once the Ø2 clocks needed for the wait state have passed, it should be possible to de-assert *RDY and, assuming the documentation in the WDC data sheet is correct, the MPU will resume on the next Ø2 high pulse.

I put a query into WDC about this a number of days ago but haven't received a reply. Perhaps another hardware type who frequents this forum might know.

I've never used RDY, but I think the address lines would have to remain valid. The data sheet says, "A low input logic level will halt the microprocessor in its current state."

Again though, it's positive logic, not negative. Pulling it down means you're not ready for the processor to proceed, because something needs more time. Going high means, "Ready, sir!"

That is the way I'm interpreting the data sheet as well. It seems one of us will probably have to experiment to see exactly what happens when Ø2 is high and *RDY is asserted. I *suspect* A0-A15 will stay valid along with D0-D7 but I'd hate to base an entire design on a hunch. It's not as though I have B.H. Obama funding my electronics business.



Have to disagree on that one.

According to the people who introduced me to digital electronics 45 years ago, a signal is considered "active low" if it causes an activity or effect that is contrary to the normal state of the device being affected. The normal state of the '816, if *RDY is allowed to float, is to execute instructions, as *RDY is attached to an internal pullup. The "abnormal" state would be to suspend execution. Hence *RDY must be high in order for the MPU to act in the normal or usual fashion—that is, process instructions. Negating *RDY causes an "abnormal" state in the MPU, in which it halts.

Also note how executing a WAI instruction causes *RDY to negate. Therefore, based on the engineering logic that was developed relatively early in the digital age, *RDY is an active low input—and output if WAI is executed.

Then you'd have to rename it, "not-ready-bar", "*not-ready", or something similar, so pulling it low is true, meaning not ready. But as it is, high = ready. Low = not ready. The normal state is "ready". It doesn't matter which way it floats when not pulled. The active state is high, telling it you're ready to move on. Pulling it low stops the activity, by ceasing to tell it you're ready to end the bus cycle on schedule.

IIRC the data lines stay valid. I built an auxiliary processor that stops
the main 6502 using RDY when a bus error is detected (like write on
read-only pages, execute on no-execute pages, access to non-mapped
pages). Need to check the schematics again tho

http://www.6502.org/users/andre/csa/auxcpu/index.html

André