Whoops - that points me to a little flaw in my breadboard design: no pull-ups, just TTL output of '02 into 6509... it seems to work... but maybe that's the reason for some quirks...

Interesting, I didn't think the 4040 was any different from the 8050/8250/1540/1541/1571/etc.

That's an interesting idea. It would work if the input is transparent during the read, but the next thing to find out is whether the VIA will transfer new data to the bus during the read time, ie, data that wasn't there yet at the beginning of the read time.

_________________
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?

Maybe I've misunderstood the context here, but I don't see how this is necessary. After every wait state (caused by RDY being low), another whole new bus cycle occurs (albeit to the same address). Seems to me the VIA should have no trouble delivering new data in the new bus cycle.

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

Hmm, are there reads of status registers which change the state, such that a repeated read isn't what you want?

I suspect the construction of the CS (or maybe the E input) to the VIA will determine whether it sees repeated reads or one looong read.

I also would think so. VIA should sample data in phi1 and put the new data on the bus every phi2. But maybe somebody with a VIA could test it to be sure?

(If it would not work it should not be too difficult to find work around with RDY/CS logic.)



That could be the case, of course - one has to keep that in mind.

On the other hand: in this design VIA's read or write handshake features probably are not too useful here, for it either triggers an IRQ or has to be polled by software - both completely unnecessary when waiting is already performed through RDY. Other accesses than to data Port A/PortB also is not used or necessary.

You could use S.O. pin to do synchronous transfers. Trigger by hardware, use it in software type feature whereas RDY signal can only be used by hardware and you cant use it for synchronous transfers.

I guess the pin used initially for early testing & debugging of the design. And the least used flag is chosen as victim for this late addition to the design. (Just a guess)