That much is not in question, as long as Ø2 is high when *RDY is asserted. The unanswered question is whether A0-A15 are valid at that time.

It'll be very interesting to hear what WDC have to say.

Meantime, Ruud (a user on this site) notes on his website that he found it more practical to pause the clock:


He provides a schematic too - it only takes a pair of 74F00's

In reading Rudd's material I think he may have overlooked an important item in using *RDY to halt the MPU. The bank address (A16-A23) is MUXed on to D0-D7 when Ø2 is low and must be latched—it is not present when Ø2 is high (see page 45 of the '816 data sheet, as well as the timing diagram on page 29). Therefore, if a device is to assert *RDY it must do so when Ø2 is high, at which time the bank address should have already been set. Perusal of the timing diagram strongly suggests that in all cases, the state of *RDY should not be changed when Ø2 is low, as doing so would produce timing and address bus ambiguities. This would particularly be a problem if the operation that was postponed by *RDY is a write.

Halting the MPU by halting Ø2 doesn't make sense unless the goal is to minimize power consumption. Also, how would you relate wait state duration to clock pulses? *RDY was provided precisely to avoid a "stop the clock" kludge, and was a feature of the original 6502.

Incidentally, the 74x245 referred to on page 45 of the data sheet probably should be a 74ABT245 to assure adequate drive to the data bus, especially if there is a lot of hardware hanging off it (e.g., numerous SRAMs). Also, the 573/373 acting as the bank address latch should probably be a 74ABT573, again to assure adequate drive strength.

Hmm, I don't read the WDC datasheet that way. I read it as saying RDY is sampled by the 816 on the falling edge of PHI2, and determines whether the processor will be stopped or will proceed as usual. That is, RDY is a synchronous input to the 816, not an asynchronous one.

But if you're pointing out that external logic needs to be aware of the interaction of RDY and the dual use of the databus, I completely agree.

I'd also agree that it may be convenient to derive RDY externally from a register clocked by the rising edge of PHI2. I see André Fachat has a page on this site about RDY generation (admittedly for 65C02).

In my case, the surrounding logic is already manipulating the 816 clock for other reasons, so Ruud's solution is applicable. In the case of a design with a free-running clock which needs to accept slow peripherals I'd agree that RDY would be the right tool.

(By the way, the GTE datasheet says a little more about RDY than the WDC datasheet does: search for "65816 gte microcircuits datasheet")

Cheers
Ed

You are correct in that regard. However, note that *RDY is sampled before a data bus read operation is actually performed. A write operation will have already placed data on to D0-D7. Therefore, if *RDY is asserted as soon as Ø2 goes high, the MPU should stop with D0-D7 valid if a write operation is pending, defer D0-D7 access if a read operation is pending, and (in theory) A0-A15 reflecting the address generated by the MPU prior to the detection of *RDY. It is the latter that is in question right now.

BTW, the '816 also samples *IRQ and *NMI (and *RESET) on the falling edge of Ø2, which technically makes them synchronous inputs as well.


Unless I'm misreading the WDC 65C02 data sheet, it would respond to *RDY in the same fashion as the '816. André's circuit seems unnecessarily complicated, given that the 'C02 data sheet specifically states that A0-15 and D0-D7 will maintain state if *RDY is asserted when Ø2 is high.

It should be easy, using simple gate circuitry, to arrange so *RDY is asserted and de-asserted only when Ø2 is high. This should assure that an address bus ambiguity won't arise due to asserting *RDY when Ø2 is low. Of course, some sort of pulse counter would be needed to produce a wait state of n Ø2 clocks.


*RDY would be particularly applicable when I/O hardware of varying speeds is involved. Some hardware may get snotty about it if you stall the Ø2 clock trying to generate a wait state. A good example would be the AM53C94 SCSI controller, which requires a stable clock at all times to sequence the SCSI bus protocol and not violate SCSI timing standards.


The search failed in both Alta Vista and Google. Sites that did get returned mostly refer to the WDC data sheet.

OK, I understand. I'm relying on the idea that the processor stops, but I agree that there's nothing explicit in the WDC datasheet.



Interesting - I hadn't taken those other control inputs to be synchronous, but the datasheet says so. A short pulse at the wrong time would be ignored.



Hmm, I see what you mean, but I think he has a particular aim to synchronise the trailing (rising) edge of his *NEWSEL signal (and not to introduce extra edges)



Ah yes, I see that. Valuable experience.



Sorry, I should perhaps just give the link I use: http://www.coinop.org/kb_dl.aspx/KB/dat ... 65c816.txt (I've also found http://www.coinop.org/kb_dl.aspx/KB/dat ... ncdesc.txt useful)

Cheers
Ed

Stopping phase 2 would cause timing problems in the case of a peripheral IC's timer that is counting phase-2 pulses; but I expect the greater reason for RDY initially was that the NMOS 6502 would lose register data if you slowed it down too much, and it also didn't have an onboard oscillator. The CMOS versions can be stopped indefinitely with phase 2 high, and WDC's can be stopped indefinitely in either phase. If you use the 65c02's onboard oscillator however, that won't stop by negating RDY (which is what you do when you pull it down, telling it you're not ready yet to move on), so you can't really do clock-stretching there. The RDY input no doubt carried over to the '816.

At least in my design, I'm not interested in clock stretching, but instead a true wait state that is triggered when an I/O device with slow setup and access times is selected. Although, as you pointed out, the current WDC offerings are all static designs, fiddling with the Ø2 clock as a means of wait-stating the system is probably not good design practice with these processors. It made sense with the NMOS units because *RDY was not correctly implemented to deal with writing to slow hardware. A read of the old NMOS literature suggests that the MOS designers were mostly concerned with reliable read ops from slow ROM.

The Commodore 128 uses clock stretching when an I/O access is required and the MPU is running at 2 MHz, again due to the defective implementation of *RDY in the HMOS 8502, as well as timing issues involving the serial bus and fake RS-232 routines. Any access to the $D000-$DFFF range while I/O is mapped in results in an effective 1 MHz Ø2 clock.

Assuming the '816 (and 'C02) holds a valid address on A0-A15 following assertion of *RDY while Ø2 is high, you could stall the MPU indefinitely with no change to the state of either bus, giving real slow hardware more than enough time to respond when selected. I see no reason why it wouldn't be possible to interface the MOS 6526 CIA from a Commodore 64 with an 'C02 or '816 running at 20 MHz. It would simply mean holding *RDY down for a lot of Ø2 clocks to give the CIA time to do its thing.

In a practical system, any assertion of *IRQ or *NMI would last for more than a single Ø2 pulse, unless noise somehow gets into the picture. Every piece of I/O hardware with I've worked latches its IRQ output, guaranteeing that *IRQ or *NMI will stay down long enough to get the MPU's attention (actually, *NMI is edge-sensitive and if continuously held down, prevents another NMI from being detected). A properly designed reset circuit would also assure that *RESET is kept low well beyond the six Ø2 clocks required by the MPU. If you use a part like Dallas Semi's DS-1813 Econo-Reset, you can't go wrong in that department. Even a basic R-C circuit will work.


I don't think he'd be introducing extra edges if it's all synched to Ø2.


I had a look at that. The section on *RDY appears to be based upon a much older description I recall from the 1990s.

Thanks, at last that spec decision makes sense!

I'll react to some statements here in a different order.

No, a device can activate or deactivate RDY at any time. The 65xxx will only have a look at it at the end of Ø2 and then act according its state.

That's correct. And that's where I went wrong. I equiped a Commodore VIC-20 with a 65816 and a 16-bits ISA bus. I only used 8 bits, I took the 16-bits bus for its address range. I updated the bank address by using a 74ALS573 as latch and Ø1 to latch it. The moment I activated RDY, things went wrong. So I inserted my debugger for the PC and found out that at the moment I activated RDY, the bank address became the same as the DATA that was on the bus.
That's why I decided to find a circuit that stops updating the bank address when RDY is asserted. And such a circuit MAY ONLY ACT on RDY when Ø2 is High. And then lazy me found out that I could save some soldering by using the same circuit for the 65816.

They way I understand this statement is that you miss the fact that the bank address is not updated anymore during the time the 65816 is halted by keeping Ø2 High. Then my question is, why should it be updated, what is wrong with its contents after xxx cycles?

_________________

That is true. However, the '816's *RDY should not be asserted when Ø2 is low, as depending on timing, *RDY might go low during the high to low transition of Ø2, which is when *RDY is being sampled. It is also at the start of Ø2 low that the MPU places the bank address on D0-D7. According to tech support at WDC, asserting *RDY at that point will result in an invalid bank address being latched.

If the bank address is latched when Ø2 is low, it should hold as long as you assert *RDY when Ø2 is high. I've simmed the bank address latch circuit depicted on page 45 of the data sheet and it appears to work as advertised as long as *RDY is not asserted when Ø2 is low. The timing diagram unambiguously shows that the bank address is present only when Ø2 is low. It could be Tpd is messing with you, although 74LS logic should be plenty fast.


Assuming the MPU's internal *RDY logic is correct, asserting *RDY when Ø2 is high should maintain the state of both D0-D7 and A0-15 (it's the latter that is in question). Asserting *RDY defers a read operation until released -- that is, the state of D0-D7 reflects what the previous operation did, not the current one that has been stalled by asserting *RDY. If the stalled operation is a write, D0-D7 will hold valid data. In both cases, the MPU resumes on the next falling edge of Ø2 after *RDY is released.

As I said, it's all unambiguous except the behavior of A0-A15 when *RDY is asserted. I hope to soon have an answer on that.

Hi BDD
This forum is a useful searchable resource for users of 6502 and 65816, so I'd like to take time out to summarize a few points on this topic as I see them, from my reading of the WDC datasheet and GTE datasheet and posts in this forum.

First off, at lower speeds, the 65816 is really easy to use. In my case, it was easy to get something working at 4MHz and took a little more care and attention to operate at 8MHz. To run any faster is going to require study of the timing diagram in the data sheet and the timings in the preceding table.

The Bank Address latching circuit in the WDC datasheet should be taken as an illustration, not as part of the spec. At modest clock speed in a design which doesn't use RDY this is an easy design problem. Many designs won't even need to latch all 8 bits.

In a design which does use RDY to stall the 65816, there are several things to note. The Bank Address can only be captured in non-wait cycles, so the illustrative latching circuit probably won't do. The need for a more complex external circuit leads to combinations of RDY and PHI2 which have timing constraints of their own. That's why we see talk about RDY changing while PHI2 is high: not because of the 65816 spec, but because of the different solutions to latching the Bank Address.

The timing constraints on the clocking of the latch are tough: most designs will need to decode from the Bank Address to decide whether or not to take a wait state. If that can be done before the rising edge of PHI2 it'll be easier to conditionally clock the latch. It'll also be possible to retime the RDY signal from the rising edge of PHI2. (As noted elsewhere, bus capacitance and intentional clock skew can help.)

Note that paragraph 2.24 of the datasheet says "A low input logic level [on RDY] will halt the microprocessor in its current state." I'm not left with any doubt about the behaviour of the address bus in a wait cycle.

I'm confident that a wait state caused by taking RDY low in time for the falling edge of PHI2 will work the way I need it to. If a design correctly arranges to capture the Bank Address in the previous non-wait cycle, all the address, data and control signals will allow interfacing to a slow peripheral.

Cheers
Ed

PS: I found it useful to search this forum for posts with all the words: bank address latch

That, and careful PCB layout to avoid unintentional clock and signal skews. Since the '816 can be run as fast as 20 MHz, propagation times will be influenced by external design factors. A big one would be unintentional clock skew due to significantly different amounts of reactance introduced by traces of differing lengths.


No argument there, although there's no reason why is shouldn't work at elevated clock rates. However, running at 20 MHz would give you only about 15 ns to latch the bank address. That would be difficult using 74x logic.


In all likelihood, a design meant to run at 20 MHz would be better served by using some sort of PLD to generate the required logic. Prop delay in a PLD is extremely low and generally consistent across all paths. I can see where the 74x logic that would be needed to do all this would develop cumulative prop delays that would exceed one half a '816 bus cycle. In fact, at 20 MHz, bank address latching would have to be performed by 74F573 to meet timing requirements.


I am, because the discussion dwells on the state of D0-D7 but doesn't explicitly describe the state of A0-A15 while *RDY is asserted. More likely than not, it was merely a documentation oversight. However, I'm hesitant to proceed on a design without knowing for sure.


Have you worked out how to actually generate the wait state for n Ø2 cycles?