Which is why I earlier mentioned driving it through an RC parallel filter, so that the CPU can independently pull it low without conflict, but the response to driving it low externally is still sufficiently fast. However, WDC themselves say that if RDY is actively driven high, WAI simply won't halt the CPU as it's supposed to.

More sophisticated solutions are possible, but for your first build it probably doesn't really matter what you do here.

Right, I got myself confused for a minute thinking that RDY was active high, and that WAI would pull it high and cause that circuit to start spewing random OE and WE.

Knowing this, I suppose that what I have is fine (I routed what I was showing earlier, with a few changes to other parts of the schematic)

It is active-high. High means "Ready." "Go." "No need to pause any longer." What Chromatix was saying is don't pull it up actively externally (except as we talked about earlier with the resistor and a 22pF or 47pF capacitor across that resistor, going to the gate that is pulling it up). You want to allow the processor to be able to pull it down.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Sorry, that's what I meant, low meaning "not ready", which is the only useful state to pull it to externally.

So the CPU should be able to pull it low if the gate is still holding it high?

It would try; and with the resistor in series, it would succeed and not experience undue current and heating.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

RDY is internally driven low by the MPU on cycle 3 of a WAI instruction. Also, VDA and VPA are both de-asserted during cycles 2 and 3 of WAI. If your chip select logic is fully qualified by those two signals nothing will be selected during a WAIt and hence contention will not occur.

The problem with using RDY to indicate to the read/write logic that a wait-state is in progress is that it might not be a wait-state that has negated RDY.

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

This seems like a blessing. It sounds like we can pretty much ignore the WAI instruction and ignore the bidirectional nature of the RDY pin, perhaps with the safeguard of the RC circuit as described.

Worrying about the effect of unwanted WAI instructions is another thing which is just a distraction for a first build. All you need to be sure of is that a WAI won't damage your CPU. It's almost worth someone doing a soak test with RDY tied high and then using WAI and seeing if anything untoward happens. And perhaps measuring the current into RDY.

A beginner project should not need RDY and should not use WAI, which then keeps things simple.

But none of this is about a continuously variable clock...

I agree there's a challenge to be addressed regarding subjects like RDY, and part of it is to restrain the over-eagerness some novices possess.

The other part of the challenge is providing coherent information, because lack of same can (and I'm not exaggerating or being funny) be more of a problem than the problem itself! In a recently created thread I took a stab at organizing a collection of info, and if anyone has anything to add, please let me know or simply make a post in the thread: RDY vs CLOCK STRETCHING. Includes 2 very simple circuits

Just tonight I made some changes myself.... including, you'll be glad to hear, Ed, a tempering comment for novices and a bypass strategy which, during troubleshooting, can rule out Clock Stretching as a point of failure.

OK, thanks -- that makes sense. Even so, it's questionable whether any gate -- even an AC series device -- could successfully overcome RDY if the latter is as strong as other outputs on WDC devices. But we can at least be assured that tying WAI directly to VCC will prevent the CPU from halting, for whatever that may be worth. (Even though the CPU doesn't halt, I'm guessing RDY will keep futilely trying to pull low until an interrupt arrives.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The text seems to suggest that it'll simply continue execution after the WAI instruction, as if an interrupt arrived with interrupts masked, with RDY only pulled low for about one cycle. So effectively WAI becomes a relatively slow NOP (but STP is still effective).

Other notes from WDC indicate that the core logic actually has separate RDY input and output lines, but these are effectively shorted together in their 6502 and 65816 products, in such a way that the RDY output only pulls low, not high. WAI is implemented entirely through pulling the RDY output low in the third cycle, unless and until an interrupt arrives. Once that third cycle completes, RDY is released and the CPU will naturally either take an interrupt or continue execution - but the cycle could be of arbitrary length in terms of Phi2 clock edges.

Thanks for this, I gave it a cursory glance and will do a full read in a bit, I've not got any replies back on my other post yet about the final design, I'm hoping I can stick with it and not have to go back and remove stuff

Interesting. But part of me wishes you would include or link to the actual references. All too often WDC doc is ambiguous, demanding the ability to read between the lines, or even outright telepathy/clairvoyance!

( The other part of me is so mistrustful of WDC doc that I hardly care what they say! -- I'd rather reason things out for myself, or, if necessary, do an experiment! )

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

(This does feel like one for an experiment, and then documenting in an appropriate thread. Edit to note: it mightn't be clear to relative newcomers, but some of the relative old-timers here do like to conserve and enhance the status of these forums as reference material: web searches are pretty good at finding relevant threads, if we create them. It's fine to have threads which are conversational or by way of a development log, but there's also a place for threads which answer one specific technical question, or lay out some understanding of a technical topic. It's always good to take the extra minute and linkify a post with references to documents, web pages elsewhere, or threads here. And don't forget, there's heaps more to 6502.org than these forums - there's a wealth of technical material too.)