Simple circuits for clock stretching to match a slow clock

[and3rson]

gfoot wrote:

Most likely you'd need A3 to actually be in an external D flipflop rather than in the counter. You could try to do the trickery you mentioned, but you also want A0-A2 to count up at the same time, which is obviously very complicated and the whole point of using the counter is not to have to do that!

I decided to try your idea of using an external D flip-flop and it worked pretty well. It replaces A3, '163 drives A0-A2, and the rest of the circuit is implemented according to my equations.

It fits in 4 chips with no spare gates remaining:
- '163
- '02 quad 2-NOR
- '10 triple 3-NAND
- '74 D flip-flop

[barnacle]

Andrew, isn't that '74's set input tied to the wrong rail? It sets/clears asynchronously on low, I think.

Neil

[BigDumbDinosaur]

barnacle wrote:

Andrew, isn't that '74's set input tied to the wrong rail? It sets/clears asynchronously on low, I think.

Good observation.  /SET, also called /PRE, has to be high in order for the Qs to respond to inputs.  Ditto for /CLR.

[and3rson]

Neil, BDD - thanks for catching that! I was not aware that /PRE & /CLR are low-active in '74, since the software that I'm using ("Digital") has D triggers with active-high inputs. Luckily, seems like the timings in my schematic are OK even with inverted /CLR, as long as /SET is tied high when used with real '74 as you mentioned.

[barnacle]

Logisim Evolution (like its parent) has default d-types which also has active high clear and set inputs. I'm forever having to add inverters so they behave like the real thing. There's a similar issue with the decoders, too; the outputs are active high (238 vs 138) and the enable input is active high instead of low.

The range of TTL parts is increasing but (a) multi-part devices aren't separable as they only appear as the actual chip pinout, so diagrams get very messy and difficult to follow, and (b) they never seem to have quite the part I want (e.g. 165 and 166 are there, but I'd like a 164, and a 393, and... actually, I'd like to see the memory parts expanded to give an SPI flash, too.

When I'm playing around, I tend to start with the default logic blocks, then convert gates to fractions of TTL equivalents, and once that works it's a lot easier to drop it into Kicad.

Unfortunately each level of indirection makes things slower for the simulation, but I do have a couple of designed-from-scratch (i.e. code compatible but with little similarity internally) 8080 designs that actually run Tiny Basic in the simulator.

Neil

[Proxy]

you could try out Digital if you want.
allows you to directly invert inputs of almost any component and even has a lot of built-in 74' logic components.
all of those are just made in Digital, so if any are missing you can add them yourself using one of the existing chips as a base.

plus it overall runs a lot faster than Logisim, with the trade off being that you cannot modify the circuit while it's simulating.

[gfoot]

Andrew another consideration is the reset being asynchronous, does that place some constraints on the timing of /WSE? It may not be a problem but its worth being clear about.

[and3rson]

gfoot wrote:

Andrew another consideration is the reset being asynchronous, does that place some constraints on the timing of /WSE? It may not be a problem but its worth being clear about.

I don't think that's a problem, since the sole purpose of resetting the first D flip-flop is to prevent Q'3 from counting when /WSE is inactive, which only has effect on the rest of the circuit every 8 cycles. The flip-flop is cleared by MPU releasing /WSE or '163 overflowing, so they can safely occur in any order (since they both set it to 0).
I've also noticed that reset input did need inversion to be fully compatible with '74, so here's the updated schematic:

[gfoot]

(Edit - I got the cpu clock speed wrong, corrected now)

A little update on this - I have actually been using the little test system I built (see schematic in my first post in this thread) quite a bit recently, for general 6502 experiments. It is running very well, at 16.384MHz, on solderless breadboard - consistently passing all the Dormann tests running repeatedly in a loop. This is the version that only divides the CPU clock down by 2 for slow device access, so the 65C22 VIA is running at 8.192MHz, and I think the ROM is also accessed at that speed.

When I first built the system it had some problems, but it was once again due to poor signal integrity. Some operations on certain addresses would occasionally corrupt other addresses - the specific case I found was repeated operations on $00FF sometimes causing $01FF to get set to $FF. It is odd how rare yet specific these failure cases can be - in a loop cycling through different values, it seemed to only ever fail when the value being written to $00FF was $80 or $40, and regardless, the value written to $01FF in error was always $FF. The same test applied to $00FE and $01FE didn't fail. I remember a similar case occuring with my "Fast PDIP" system a few months ago, which in that case also only happened for certain CPU instructions.

The cause, this time, was that the ground pin of the 65C02 had to take a really long route around the breadboard to get to the ground pin of the RAM. It just goes to show how important signal return paths are, even in the relatively uncontrollable environment of a solderless breadboard.

I've now used this system for various experiments - PS/2 keyboard interfacing to the 65C22, experimental new SD card routines for NormalLuser, and a few other things. It was only meant to be test circuit, but it looks like it will be a more permanent fixture now, and perhaps deserves a bit of tidying up.

Here it is with a serial board and SD card module attached. The blue LED lights when RDY is high, which is a nice way to show activity; if the program uses WAI in a loop to wait for interrupt-driven I/O, or STP when it's finished, then the light goes out.

[BigEd]

That's both amazing and great!

[gfoot]

I misremembered how the circuit works, and got the CPU clock speed wrong earlier - it's actually half of what I originally said, so I've edited the past. Not as amazing, but still nice and stable!

[BigEd]

Ah those pesky factors of two!

[gfoot]

Yes, I'd overlooked the fact that the crystal frequency was divided by two to form PHI2, as my other system didn't do it that way.

I tried some other crystals and it worked well up to about 20MHz CPU clock speed, 10MHz ROM/VIA/Serial clock speed. Above that I suspected the slow clock was too fast for the ROM, so I upgraded the circuit to the one from my second post, where the slow clock is a quarter of PHI2. This worked well and seems stable up to 28MHz CPU speed, judging by memory test and Dormann test results - so I think this divide-by-4 clock stretch design is fine too. The tests failed quickly at 30MHz, so overall this is comparable to what my "Fast PDIP" system managed on a breadboard.

[Paganini]

Hi George,

gfoot wrote:

It's possible that you may want or need the slow clock to be slower than half the speed of PHI2. For example, in my Fast PDIP computer I typically run the CPU at about 32MHz, and the I/O module at 8MHz. If I were to use the circuit above, the I/O clock would be 16MHz, which is technically too fast for most EEPROMs. So I really want to divide the clock by more than 2 - perhaps 4, or even 8, to get an I/O speed of 8MHz or 4MHz.

I've been super busy, so I haven't been able to work on Blue August much for the last few weeks. Today I finally had time to build the /4 version of your slow-downer:

It doesn't work quite as expected. Possibly there's something wrong with my expectations but I don't think it's correct to drive the NAND network with the TC of the second-stage counter.

Rather than think too hard about this, I went ahead and built the other /4 version, with 3 counters. It also doesn't work as expected, in the same way as the simpler one. In addition, it actually seems to work less well than the simpler one, in that PHI2 is 10/2.5 MHz, rather than 20/5 MHz.

I think next I will build the original /2 version to make sure I really understand how it works, and then try modifying it to make a /4 version.

[gfoot]

Hmm OK, thanks for trying it. What exactly was the problem you saw, apart from what you said about the clock speed? The CPU's PHI2 should end up being the input clock speed divided by 2 for fast cycles, and the slow clock should be the input clock divided by 8.

A few days ago I modified my build of the /2 circuit to match the /4 design (with two counters) and it worked very well, though I didn't test the circuit in isolation like I did with the /2 circuit - this was just running some code, with ROM, VIA and a custom serial circuit using the slow clock. The VIA timers seemed to count at the right rate, baud rates were correct (derived from the slow clock) and CPU cycle counts seemed correct too, between the fast and slow rates.

The only change I remember making knowingly was using an inverter on the TC output instead of a NAND, because I had used all four NAND units and needed to add an extra IC either way. As i was adapting the /2 circuit rather than building from scratch, it's possible I had some other changes without realising it.

I settled on using a 48MHz oscillator for that.