6502.org

To create a reliable Ø2 for an external 6522 for a C64, Garth used the system Clock delayed 150nS.
http://6502.org/users/garth/projects.php?project=7

This seems pretty drastic to me. Looking at the timing diagrams (always risky to rely on), most VIA internal operations commence on the falling edge of Ø2 but some seem dependent on the rising edge, principally the timers, which are capable counting N+1.5 Cycles. Would delaying the rise of Ø2 affect those functions?

What about an opposite situation, in which VIA Ø2 rises before the processor clock does? As long as the address bits that generate CS and /CS, and the bits that select the VIAs registers are stable and settled, it shouldn't matter if Ø2 is early with respect to the cpu clock, right?

I ask because a design I've been working on (for what seems like forever!) for the VIC-20 has the possibility, under certain conditions, to cause VIA Ø2 to rise before the processor Clk, which will rise about 60nS later than normally. If I arrange for VIA Ø2 to rise slightly after the slightly later and shorter than normal cpu phase, that will create some minor, but not insoluble, difficulties elsewhere in the overall design, but my main concern is that the two shorter than normal Ø2s will have an affect on the serial I/O timings.

Any and all thoughts/opinions appreciated.

Thanks,
Richard

I've given all our C64 hardware and books away to someone who really appreciated them and restores them, so I would have to try to find stuff online, which I won't take time to do right now.  But as I remember, the I/O-area selects from the C64 did not go true until Φ2 went high, which does not work for the VIA.  It requires the chip selects, register selects, and R/W to be valid and stable a setup time before its Φ2 input rises.

Hi, Richard. Yes, this part sounds right to me. You've noted that the VIA's CS, /CS and Register Select bits will be stable when the VIA clock rises (just remember a certain setup time is required), so yes the VIA will successfully input those bits.

Now let's look at the data bus. On a read cycle the rise of the VIA clock causes it, after a delay, to put data on the bus, and the CPU needs this data to be valid a certain setup time before the CPU's clock falls. AIUI, you're not altering the rise of the VIA clock or the fall of the CPU clock, so nothing has changed and you should be alright.

On a write cycle, the peripheral and the CPU trade responsibilities. The rise of the CPU clock causes it, after a delay, to put data on the bus. AIUI, you're delaying the rise of the CPU clock, and this could potentially be cause for concern. But from our PMs I know you've replaced the VIC's NMOS CPU with a WDC 'C02, and therefore the delay from CPU clock rising to it outputting valid data is substantially reduced. You'd wanna do the math to be certain, but I'm guessing you'll be alright. Then of course the VIA needs the data to be valid a certain setup time before the VIA's clock falls, but AIUI you haven't altered when the VIA clock falls, so this part should be alright too.

I'm not sure I understand your concern about serial I/O timings. If the VIA clock stays consistent with itself (ie, it's entirely periodic) then I don't see any problem. But if it jumps back and forth between normal timing and advanced timing (or is it delayed timing?) then maybe you'd see some jitter in the serial I/O. But I might be confused. Wasn't it the CPU, not the VIA, whose clock would get altered? If I'm missing your point then please try rephrasing the question.

-- Jeff

You have laid to rest one of my concerns. Thanks, Jeff.

This might be another instance of me foreseeing a problem where there isn't one. The VIA clock won't change its timing because unlike the original it won't be derived from the cpu clock, which will be changing depending on which region of memory is being addressed. (Internal/external, Fast/Slow.)

It turns out for VIA and indeed all I/O access I can make the cpu clock rise only a few nS after VIA Ø2, not 60nS. I've resolved the difficulties that creates in other areas of the design. (V12b was correct all along.)
Yep. No need to rephrase. We both got that right.

Btw I used a different way to delay the rising edge of the C64 Phi2 signal. The C64 conveniently has the dotclock signal, which, as far as I remember, is in stable phase lock with Phi2 and 8x Phi2. See her http://www.6502.org/users/andre/cbmhw/c64csa/index.html

Note there is some other use of dotclk as the interface this bus provides specifies a 2Phi2 signal. In this case this is 25%/75% duty cycle as it just delays Phi2 by two dotclk cycles.

On C64s with the 8701 chip the dot clock is very irregular, for example the time between falling edge of Phi2 and falling edge of dot clock can vary based on how the 8701/VIC-II were initialized. I suspect this can introduce difficult to reproduce phase-of-the-moon like bugs where something works randomly only half of the time.
The older C64s without the 8701 don't have this problem.

Interesting. I didn't know this. My design is from a long time ago and it "worked for me"

Thanks for pointing it out!

André