Hi George,

In the simpler one (two counters + NAND network), Ø2 is a modified TC of the second stage counter. TC is always a very short pulse, which means that Ø2-low is the same width as the fast clock, regardless of the WSE\ value. Maybe that's what you had in mind, since it does give one such pulse per slow clock cycle, so tCYC is right, from the 6502's perspective. But it's not any help in terms of address decoding to have such a short Ø2 low time. Possibly I just didn't understand the design, and it turns out to be unsuitable for what I'm trying to do.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

That is intentional - the PHI2 seen by the CPU always has a short low period, it needs to be this way in case it is a fast cycle. Address decoding for fast cycles ought to take place in time for this, though there is some room for it to take longer if you're careful. In my example schematic this address decoding was just "is A15 low?" So if that is fast enough to harken before PHI2 rises, it ensures the RAM only gets written for low addresses, which is ideal. I can explain more about how we can accommodate slower decoding there especially if you have a small window of slow addresses, but it will muddy the waters a bit, maybe I can make a demo circuit of that sometime though. It is simpler if at least the "slow or not" decision can be quick, even if further decoding of exactly which device is being accessed still takes a bit longer.

If the cycle is slow, then we are going to have at least one low period of the slow clock before the high period we are targeting, and this should be plenty of time for that second round of complex address decoding to take place. PHI2 will be high throughout, and the slow clock may also be high for some time before the target cycle begins. So this address decoding needs to also include SLOWCS so that it waits until the right low-then-high cycle of the slow clock before activating the device. See my example full computer schematic for how that can work - it decides between ROM and VIA in this way.

I actually want to reduce the amount of lead-in we guarantee here as it feels excessive at the moment, but right now this should provide plenty of time for even very slow address decoding - so long as the decision that the cycle is slow can be made fairly quickly (at the very least, before PHI2 falls prematurely).

Hi George,

OK, I think I see what you're saying. To confirm, PHI2 and SLOWCLK will never have synchronized low periods. PHI2 will always have a short low period, and the high period will be a variable length, adjusted so that the falling edge coincides with the appropriate falling edge of SLOWCLK.

If that's so, then the first build did work as it should, and my expectation was wrong. The second build was dividing the oscillator frequency by 4 and 16, rather than by 2 and 8, however.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Yes that's exactly right, the CPU has PHI2 held high until the appropriate falling edge of SLOWCLK. Thanks for confirming regarding your results, I'll take another look at the one that wasn't working.

I can't see anything wrong with that three-counter circuit at the moment, but I'll build it out when I have time, it'll be relatively easy to change my current one over.

For reference, here are some waveforms from my current build (the two-counter divide-by-4 circuit):

In these captures the bottom yellow line is PHI2, next up in blue is the slow clock (5 MHz), then in red the /WSE signal, then at the top in green is the ROM's /CS signal. The input clock (not shown) is 40 MHz.
The above shows a mixture of ROM and RAM operations - the code is in ROM here. In the normal case of running from RAM almost all the cycles would be fast and the red line would be mostly high all the time.

From the left there's a ROM cycle in progress which ends when PHI2 dips low, in sync with the slow clock falling. Next is another ROM cycle - note that it waits for a fresh falling edge on the slow clock (second trace up) before activating the ROM (top trace going low). Then there are two fast RAM cycles in a row, then another two ROM cycles. The first of these didn't need to wait as long as the second one. Then there are three fast cycles, etc.

In this second capture we see only slow operations. Note that overall they only run at half of the slow clock rate, i.e. 2.5 MHz - I don't know why the oscilloscope reported it as 5 MHz. This hslving is because the requirement to wait for a falling edge of the 5 MHz slow clock is rather wasteful, we lose up to a whole cycle every time. Some additional logic could allow us to not wait for quite as long, and would then allow code in ROM to run twice as quickly, and generally almost halve cost of slow cycles. It is not a big deal though as they should be rare in practice.

The code running here was polling for I/O, so there are some slow cycles where the ROM's /CS wasn't asserted - in these, the VIA's CS would have been asserted instead, but I didn't think to capture that.