6502.org

In the RDY vs CLOCK STRETCHING thread viewtopic.php?f=4&t=5504 This is precisely the dilemma I'm facing in trying to design a *2MHz mod for the VIC20.

For the VIAs' timers and other operations that must occur at the established 1MHz rate I'll have to recreate, duplicate... emulate the 1MHz Ph2 the VIAs would normally get. (VIC schema calls it SØ2) That's relatively simple. I just have to invert the signal from the 6560 Vid controller that becomes the cpu's normal 1MHz and delay its falling edge.

My problem is conditions will be such that the Emulated SØ2 will rise around 50nS before the cpu clock that gets stretched will rise. Currently, the difference is unavoidable because signals from the mapping/banking circuitry that will substitute RAM for the slow system ROMs won't be valid until 40nS after ESØ2 rises and I'm allowing 10nS of setup time to detect that condition.

So my question is will the 50nS difference between VIAs' (or any other 65xx I/O) 1MHz ESØ2 and stretched Ø0 have any deleterious affects on the VIA's normal internal workings when the cpu tries to access its registers? I'd like to think the answer is no but I don't want to take that for granted.

So far, my design amounts to 5-6 chips and seems a bit much for a measly 2X speed up. I've been trying to adapt Jeff's 74_163 solution to my plans but so far I've not had even a glimmer of inspiration. Bear in mind that if an I/O access occurs after a "2MHz" T1 the T2 that would normally follow would be suppressed and access would be deferred until the next cycle. So what I'd ideally have would be a Stretch or Wait hybrid. Ugh.

I am open to suggestions. Thanks.

I think there may be problems. The VIA requires that the address lines are stable at the rising edge of the clock phi2.

That is why it cannot be used in a C64 without delaying the leading edge of phi2.

Not sure here - the 2MHz CPU may already have the lines ready and stable. You may have to need the 2MHz variant of the VIA due to the shortened phi1

Edit: I think the 6522 is the only one where that A lines ready at rising phi2 applies, not sure about the riot 6532 and rriot 6530 though

Maybe if you can use a PAL/GAL you can use something like the 8296 timing generator http://www.zimmers.net/anonftp/pub/cbm/ ... 4-6of9.gif

The addresses would become valid 30nS after the 65C02's previous Ø0 In went low (tADS) , whether that clock had been a Long or Short T1 or a T2, so I don't see any problem in that respect. I guess my question needs clarification: Would the difference between ESØ2 and µC clock (when the latter is stretched) affect the 6522s' timer, counter or shifting operations? Would it matter to the 6522s, as long as my ESØ2 closely mimics the original SØ2 in frequency and durations? My optimistic self says no, all will be copacetic. My more dominant personality trait says, not so fast, Sparky.

Did you ever end up making more progress on this? I started a similar project but my knowledge is way too limited so abandoned it. I'd love for it to be a thing someday. And I think 5-6 chips for a double speedup is pretty good. Even if you have to replace fthe VIAs with the modern WDC version.

Yeah, 2MHz would be a decent speed up, but considering the advice in this thread viewtopic.php?f=4&t=8336 regarding minimum propagation delays I've concluded 4MHz might be doable. (Actually four ticks of 14MHz/2=7MHz.) But whether 2MHz (Two ticks of 3.5MHz), or a portion of 7MHz, five chips only accounts for the speedup logic: there needs to be a banking system that will provide RAM shadowing the System ROMs, as well as filling other segments of VIC's address space. The foregoing builds on my earlier modifications to VIC's innards, so at this stage there's no telling what the total chip count of this pipe dream of mine will amount to.
That won't be necessary. The existing VIAs would always get an artificial, emulated 1MHz SØ2 to maintain their counting/timing functions at the original rate. R/W for them would always occur at 1MHz. Note the asymmetry of the original 1.022MHz, which stalled my thought processes longer than it should have.

Ah that makes sense. I wonder if Kernal modifications can be done to make the project less complex while retaining at least some compatibility.

Also wonder if anything can be gleaned from the old C64 2mhz project. That used SRAMs shadowing the system DRAM, a clock doubler to make 2 CPU clock cycles per VIC cycle so it can still interleave RAM access with correct timing, which apparently didn't upset things, emulated DRAM CAS/RAS signals(unneeded on the VIC-20), and 6502->6510 glue logic(also unneeded on the VIC-20).

Wish I could be of more help, my background is in analog audio. Thinking of doing the Ben Eater 6502 tutorials.

Thanks I'll definitely be looking into that. I'm not a fan of learning by video so that looks perfect.

I have basically solved the problem with accessing a fixed 1MHz clock device with a faster CPU. Albeit in an FPGA and with up to 17MHz CPU ... but maybe something can be learned from that.

Basically you divide the 1MHz clock into as many (integer number) of phases, one phase per fast CPU clock cycle. For each phase you need to decide if you can do the slow access in the current cycle, or if you have to wait for the next cycle. How many cycles you use depends on the setup times etc of the used chips.

For a 2 MHz fast clock that is easy. There are two fast clock phases in the slow clock. If the cycle in the first phase, you can stretch the CPU's phi2 to the end of the slow clock and be done with it. If the cycle is in the second phase, you have to stretch phi2 for the rest of the slow cycle, AND the following slow cycle.

For a say 10MHz fast clock, you can e.g. use the same slow cycle for the first 5 phases, und for the rest use the following slow cycle. That gives you worst case 50ns (100ns per fast clock but address lines are stable only in the second half when fast phi2 is high) address setup time in the 5th phase. If you need more, depending on the address decoding logic only use the slow cycle for the first 4 phases, that gives you worst case 150ns setup time.

How to do this in hardware is another matter.

Sorry I'm not at home so can't scribble timing diagram right now