6502.org

For the '02, true, as long at writes never start before Φ2 goes high; but I was responding to what AndrewP said about the '816, "It's only the Bank-Address-is-disappearing restriction in my head that made me think I should only start doing address decoding after PHI2 has gone high and after the '573** has stopped latching," because in the '816 situation, the rise of Φ2 is the "city limit sign" telling where the function of the data bus suddenly changes.

Hmm, I don't quite understand you - with a latch in place, the circuit has access to the high byte of the address almost as soon as it's output by the 816, and that access continues until the end of the cycle. There's no remnant of the effect of phi2 rising, as seen at the output of that latch.

It's true that any logic on the input side of the latch needs to resolve before the rise of phi2. But now I think about it, I'm less sure of the advantages of putting logic on the input side.

You shouldn't actually wait for PHI2 high to begin address decoding, that's why there is a transparent latch! With it, the decoding begins as soon as the bank address bits have propagated through the latch, not when PHI2 rises.

Using a D flip-flop makes you loose time because your /BankIsZero signal only becomes valid after PHI2. If you replace it with a transparent latch (not sure if single-gate transparent latches exist), the signal becomes valid at 13+5+latch_pd. Assuming your latch is faster than 7ns+1.6ns, it will be faster overall, and the time at which PHI2 rises becomes irrelevant (except for setup/hold time requirements on the latch).

Also, because propagation is commutative, it does not matter in this case if the transparent latch is before or after the OR gates, meaning you can use the same latch you use for the bank address bits (assuming the latch opening propagates faster than the bank address bits, and assuming setup/hold time requirements on the latch are satisfied in both OR->latch and latch->OR cases)

I'll just jump in for a moment here to mention that even a single gate isn't the fastest solution. A FET switch has a sub-nanosecond prop delay. See the discussion of FET switches about halfway through my first post in When is a Latch not a Latch? (Capturing the '816 Bank Addr)

-- Jeff

Thanks for the replies! Sadly we've been kicked to really bad loadshedding so time with electricity has to be rationed but I still wanted to reply to your posts.

I lost the plot when I thought I couldn't begin address decoding until after PHI2 is brought high. Fortunately, looking at my address decode circuitry I wasn't confused when I designed it and it is correct.

There is a single gate LVC latch that can be run at 5V for 1.5ns propagation time. The 74LVC1G373. I've updated and fixed the OR gate diagram to include it instead:(Looks like I forgot to invert PHI2).

If I've understood Dr Jefyll correctly then the absolute fastest way to being address decoding without incurring the propagation delay of a 74LVC573 would be something like this:which would claw back 3 to 4 nanoseconds.

I hope I never find myself in a situation where I need those nanoseconds but that's a pretty nifty thought!

Cheers,
Andrew

You've gotten the "fast propagation" part of the idea, Andrew, but overlooked the following portion of the linked post. "As drawn, the circuit relies on the capacitance of the attached devices to maintain the Bank Address bits during the clock-high period -- presumably just a fraction of a microsecond." "But if clock stopping is a requirement then you can consider attaching a 74ACT1071 or other bus-hold device to indefinitely maintain the bits."
If you crave high clock speeds then nanoseconds matter! And there's nothing complicated about the FET Switch approach. Just remember that capacitance and/or bus-hold devices have limitations in regard to excessive DC loading on the BA lines. Luckily, however, if those lines drive only MOS/CMOS inputs then the DC loading will be essentially zero.

-- Jeff