[/quote]
Are you reading too much into section 7.6, which only aims to clarify the dual-use of the databus? 2.24 has already done the job of specifying what happens. If 7.6 were missing, you might be better off because you wouldn't be hunting for an explicit statement about the address bus.


Maybe you need a prototype. Or maybe you can get more reassurance from WDC than they've given you so far. I'm sure the part works the way you want it to. How else could it work? It was designed for ease of use and compatibility with the 65C02, by very capable people, and it's had a long and successful life.


Not in detail, but the shift register design noted earlier would be the way I'd go. If n is small that's just one or two flops, of course. See also http://tinyurl.com/o49kkf

Cheers
Ed

Noted earlier where?


I'm familiar with the above circuit. However, it has the limitation of generating a wait-state of a fixed duration. A better design would be one where n would be determined according to the device being accessed. For example, if a slow EPROM is being accessed, a longer wait state would be required than when accessing an I/O device. Some means of changing n based upon the address of the accessed device would be ideal.

I gave this link to André's design.

Hmm...I don't recall seeing your reference to it. Guess I must be too bleary-eyed when I read these posts.

I have looked at that one in the past. It too produces a fixed length wait-state.

I think what I'd do is use a variable delay device like you can get from Dallas Semiconductor or Data Delay Devices, Inc., with perhaps 256 steps of 1/4ns each (not that you would need that many steps), put it in parallel with a fixed-delay buffer so one feeds phase 2 to the system and the other feeds the address high byte latch, and find out what value lets the whole thing operate at the highest possible frequency. When I was looking at the timing charts years ago regarding the '573 latch timing, there were conflicts, but there was a 20MHz '816 design in production and being sold; so I knew it was possible. I wrote to WDC about it; but although they acknowledged what I was saying, they weren't able to give a good answer other than recommend experimenting.

The F Max vs. VDD curve (fig. 4-2 on page 27 of the data sheet) suggests the current production MPUs can still run at 20 MHz. Given today's wafer production capabilities, a relatively uncomplicated design like the '816 (as compared to, say, an Athlon 64) should produce high yields capable of running at the top end of the curve. After all, as we all know, there is no such thing as a computer that is too fast.

It has been determined that the '816 will maintain the state of A0-A15 when *RDY is asserted. If *RDY is asserted when Ø2 is high and if the MPU is stalled by *RDY while executing a write operation, the state of D0-D7 will also be valid. Therefore, it should be possible to reliably execute wait states of any duration, as long as the assertion of *RDY occurs when Ø2 goes high.

It is clear that a practical system utilizing wait states should qualify all addresses relative to Ø2. If a wait state is to be generated, *RDY should not be asserted while Ø2 is low, as doing so would prevent the bank address from being latched.

Once the wait state period has expired, *RDY can be de-asserted without regard to the state of Ø2, as the MPU will not resume until Ø2 goes high again following the release of *RDY.

I will put a note on the page - this special case is where the actual slow chip is clocked with the select line, as it does not have an own Phi2 input. Otherwise the circuit could really be simpler.

André

Does that actually mean I should have to release *RDY during Phi2 low to have the actual transfer following in the next Phi2 high phase?

Your statement implies that if I release *RDY during Phi2 high, the CPU will wait for Phi2 low, and then Phi2 high again to actually do the memory transfer?

This could - not necessarily but probably - explain some weird issues I have with my 65816 prototype board where I release *RDY during Phi2 high - expecting that the actual data transfer happens during that Phi2 high where I released *RDY.

Can you clarify this?

Many thanks
André

My understanding is that the 816 samples RDY on the falling edge of PHI2 - right at the end of the clock cycle - and uses that value to decide whether the next cycle is a wait state. Internally, it is exactly as if the sampled RDY input can hold the internal version of PHI2 high. In a wait state, the core of the chip does not see a falling PHI2 (or indeed the next rising PHI2)

Therefore, it doesn't matter whether RDY changes early in the cycle - during PHI2 low - or late - so long as it is stable by the falling edge less a setup time. RDY is a clocked input.

In the case of a read with wait states, the CPU will effectively sample and capture the databus when there's a PHI2 falling with RDY high.

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

Interesting if the behaviour is indeed undefined, and perhaps a little inconvenient.


Your rule is stricter than mine, and if we've reason to doubt then following that rule would be safe. Someday I might be a position to investigate the behaviour of parts I have, and I could prove myself wrong. I couldn't show I was right, if the behaviour is not defined.

The thing is, I haven't seen the ambiguity in the datasheet which you saw.

It's certainly true that if RDY is not sampled, but just modifies the internal clocking combinatorially, modifying it during PHI1 might cause the role of the databus to switch between data and address. And it's true that if it is sampled, its value outside the setup+hold window can't change the behaviour of the device.

I think neither of us have experimental evidence either way - just possibly André has seen something, except he describes modifying RDY during PHI2, which both of us think should be fine.

BDD, looking again at the timing diagram, and re-reading your description above, I wonder: are you reading tMDS differently from the way I am? For me, the text is vertically mis-aligned. It describes the distance from PHI2 rising to the earliest time that the databus will hold valid data. It isn't saying anything about the timing of data relative to the processor control signals. It's a description, not a constraint.

Now that you mention it, could be. It appears at first blush that tMDS extends from the time that D0-D7 become valid until the MPU samples RDY. The data sheet description of tMDS isn't particularly illuminating:

tMDS -- Write Data Delay Time

A second look suggests that tMDS actually starts at the rise of Ø2, which means data (write operation) becomes valid about midway through the Ø2 high cycle. Be that as it may, it still appears the best time to change the state of RDY is on the rise of Ø2.

Perhaps WDC needs to hire a new artist to draw the timing diagrams, or I need to have my glasses prescription re-evaluated.

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

The way I see it, if you started the cycle with RDY low, it's a wait state. Which is to say, the function of the previous cycle is extended into this cycle. If during PHI2 you bring RDY high again, the next cycle will be the normal next cycle (perhaps an instruction fetch) and the memory access you're performing will finish at the end of this cycle: the falling edge of PHI2. For a write, that simply means the databus and address bus will change shortly after the fall of PHI2. For a read, it means the processor samples the databus on the fall of PHI2, and that's the value seen by the read.