Close

Clock stretching

A project log for STEbus 65C02

65C02, 32K Flash ROM, 64K fast RAM, USB link to PC. Runs BBC BASIC, at up to 14MHz.

keithKeith 05/27/2022 at 22:294 Comments

There were no STEbus 6502 designs to reverse engineer so I've had to tackle this one from scratch.

Essentially we need to make the synchronous 6502 look more like an asynchronous 68008.

The STEbus data strobe signal (DATSTB*) is asserted (low) when all the address and data lines are valid. There is a 40 ns setup time requirement.

The 6502 clock out signal (E) is asserted (high) when all the address and data lines are valid.

So E can drive DATSTB* through a 40 ns delay and an inverting gate. However, E must not go low until the STEbus slave returns a DATACK* signal. 

Let us begin by considering an oscillator running at twice the 6502 clock rate, driving a simple 74LS74 D-type latch with the D input fed by the /Q output. The Q output will toggle at the 6502 clock rate.

Now we can stretch the clock by adding a delay between the /Q and D pins. A shift register will do the job. With the proviso that it will need clearing to all zeros (or all ones) regularly to avoid invalid states.  The STEbus prototyping board uses an 8-bit shift register with clear, the 74LS164, for cycle stretching. Read the timing explanation to see how it works.

The shift register outputs look like this:

abcdefgh
00000000 when E is low, all cleared.
10000000 when E is high, starts entering shift register
11000000
11100000
11110000
11111000
11111100
11111110
11111111

You can feed any shifted signal, a to d, inverted back to the D input of the 74LS74 flip flop, and stretch the E high time.

The E low time is not stretched. Yes, that does mean the high and low times are going to be different. That is going to look weird to people used to conventional 6502 designs. But it is completely legitimate. They can't touch you for it! You can have any duty cycle you want, though of course it has to be 50:50 at the maximum clock rate.

The E low time will be the minimum for all access cycles. There is no reason why it should not, because the 6502 bus lines are invalid and no other device can do anything. All the 6502 is doing is internal stuff, and it can do that at top speed.

In a realistic system you will have various devices of various speeds. The devices are memory mapped, so the delay has to be selected by the address lines.

As a simple example demonstration of how to do this, consider a 1-of-8 multiplexer between the shift register taps and the inverter feeding the D input of the 74LS74 flip flop. Address lines A15-13 select the shift register output for each of eight 8K spaces. Each 8K space can have a different E high time, or the same, depending on how you wire it.

In practice, memory maps are not so simple and my prototype design uses GAL chips to select the delay. It makes sense to have the delay-selection in the same logic chip as the device-selection.

In my design, there are different fixed delays for ROM (fairly fast), RAM (very fast) and I/O (USB module). For STEbus access, the DATACK* signal is sensed, allowing for a variable delay. 

I have also compromised on the clock speed. The STEbus requires a 16 MHz timing clock, while the 65C02 is rated at 14 MHz. I am running my 65C02 at 8 MHz because this is easily derived from the 16 MHz oscillator and 16 MHz would be overclocking the 65C02. That is something I would try when I have  a printed circuit board but not with vero-wire on protoboard.

Discussions

Samuel A. Falvo II wrote 01/19/2024 at 01:44 point

For my project, I was planning on using RDY to insert wait-states with a bus protocol that *almost* exactly matches the 68000's.  I documented my thoughts here: https://falvotech.com/tmp-blog/20230608.html .  I used *1 to represent an AND-gate, and +1 to represent an OR-gate, similar to IEEE symbology, since it was easier to draw using ASCII text.

  Are you sure? yes | no

Keith wrote 01/19/2024 at 17:53 point

I looked at that too. It puts a whole cycle of delay in, just like in the Z80. The 6809 has no WAIT signal so it uses clock stretching, and I felt this was the way to do it for the 6502. You can stretch a cycle to fractions of a whole signal, which is faster than a whole wait cycle. However, I don't think the 6502 is used where you need speed. Most cycles will be on-board memory, not the bus, so probably not makes little difference in a real system.

  Are you sure? yes | no

Ralphw wrote 01/04/2023 at 18:24 point

There is some early (1975-early!) work that the folks making the ECD Micromind did in making an asynchronous bus, they used an NMOS 65RC12 as their main processor, the 65RC12 had some interesting properties, but they also intercepted opcodes to do unusual things with them.

http://ecdmicromind.blogspot.com/2006/07/initial-response-from-jsl-design-notes.html

Has some details.

  Are you sure? yes | no

Keith wrote 01/05/2023 at 19:43 point

That link has gone 404 for me. It mentions multiple processors but for industrial control apps three was a practical number, giving triple redundancy and majority voting. You could have one bus master and 20 intelligent slaves. But even a modest PC could outperform 20 Z80/6502/6809 chips.

  Are you sure? yes | no