65xx continuously variable clock

[backspace119]

BigDumbDinosaur wrote:

backspace119 wrote:

So, with this figured out, it should be pretty straight forward to do the wait states, all I need is RDY high qualified with PHI2 low on the 573.

You might also be interested in this topic about wait-stating, especially with regard to the 65C816.

Reading this, I actually got the 816 part down fine, what I didn't realize was the READ and WRITE signals that get qualified by phi2.

This gives more reason to use the EconOscillator chip I mentioned earlier, since the easiest way to handle this is with 2 more flops, as you show in your design (I don't have a flop on the output of the current clock generation, because it only goes up to 33Mhz, and halving that would not let me try and get to 20Mhz). The part mentioned earlier can go much much faster, and so a halving flop (that can also be controlled by the wsg) is not an issue with it.

Ultimately, the afore mentioned clock seems to have 2 clock outputs that can be switched instantaneously, without glitches. Because of this, it may be more profitable to forget the wait states, and go with two separate clocks, a fast and slow clock, programmed into the chip, that can be selected by address decoding.

EDIT: so, reading further into your thread has lead me to a few thoughts.

A: I may not have the 816 part down fine, because I'm qualifying the latch with !RDY and PHI2 as described earlier in the thread
B: using the 2 separate clocks seems the only way to fix this, but I'll still need the "global clock" output for timers on the 65c22s and such.

Using RDY on the 816 appears to be, after reading your thread, nearly impossible to do and not have weird edge cases. The nice thing about switching to that other chip is it saves me a few logic chips, and some board space, and some routing. I'm going to read over its data sheet again, and see about implementing.

Design -> check -> all good -> actually no -> rinse and repeat

[backspace119]

So looking at the data sheet for the DS1085 there appears to be 2 ways of going about using it.

Changing the DIV setting over I2C will change the clock in 1 period, which means we'll be slower on the next cycle.
or
OUT0 or OUT1 can be disabled/enabled by controlling CTRL1 or CTRL0 (provided the chip is in the right setup, which by default it is).

Touching the DAC setting does not seem to be an option (for use with talking to slow devices), it appears to take 8k cycles to settle to the new frequency.

Whichever case is gone with, special care must be taken so the 65c22s and other time sensitive chips maintain the same clock, so no timers are messed up. I *believe* that the 65SPI can tolerate a variable clock, it will just slow down data transfer internally (maybe I should put an oscillator on the EXT CLK pin for it)

I think the best way to do this is to use the CTRL pins, and switch which output we're using, OR set one output to ignore the prescaler value, which will cause its value to not be changed when changing the prescaler, and tie that clock to the 65c22.

I'm guessing that, if talking to the 65c22, we need to be on the same clock as it right? If this is the case, the best case here will be whatever can be done through address decoding, so there's no "oops" moments in code forgetting to set the clock back to the same as the 65c22

[Chromatix]

I would recommend generating a relatively low-frequency clock for the 6522's timers, significantly below that of the lowest CPU clock, and feed it into the external trigger port. Then the 6522's *bus* interface won't be confused by running on a different clock from the CPU, and also you won't have to recalculate all your timer values when you change the CPU clock frequency.

I would also urge you to separate the concerns of choosing a general CPU clock speed and accessing slow devices. Yes, there are complications with generating RDY wait-states, but these are relatively easy to manage with a few logic chips, and then you can stop worrying about it completely. If you try varying clock speeds on the fly instead, you have to manage the clock speed in every part of your software where a slow device might be accessed, which will be an ongoing headache for you.

[backspace119]

Chromatix wrote:

I would recommend generating a relatively low-frequency clock for the 6522's timers, significantly below that of the lowest CPU clock, and feed it into the external trigger port. Then the 6522's *bus* interface won't be confused by running on a different clock from the CPU, and also you won't have to recalculate all your timer values when you change the CPU clock frequency.

I would also urge you to separate the concerns of choosing a general CPU clock speed and accessing slow devices. Yes, there are complications with generating RDY wait-states, but these are relatively easy to manage with a few logic chips, and then you can stop worrying about it completely. If you try varying clock speeds on the fly instead, you have to manage the clock speed in every part of your software where a slow device might be accessed, which will be an ongoing headache for you.

Right, my concern is on the points that BDD brought up in his thread, mostly about how qualifying the data latch with RDY can cause issues, since as soon as the wait state is done the latch will lose its contents (I believe that was the issue, I'm not confident about that though, I may need to re-read).

Other than that, it seemed that the circuit that BDD posted would be the easiest solution, which is to absorb pulses from the clock by holding a flip flop's state during a wait state, its output being used as system clock. Doing it that way would not require a lot of qualification across the board, since it would effectively stretch the clock pulse for the duration of the wait state, rather than holding the RDY line low.

I guess I'm just trying to find the simplest and cleanest solution here, that will avoid the hazards of wait stating with the 816...which is why I was considering just using the variable clock function on that chip.

[BigDumbDinosaur]

backspace119 wrote:

Using RDY on the 816 appears to be, after reading your thread, nearly impossible to do and not have weird edge cases.

Much of it is an artifact of the multiplexed nature of the data bus. If A16-A23 appeared on dedicated pins we wouldn't be having this conversation. Of course, one can ignore the bank bits, as I did in my POC V1 units, and then the RDY conundrum becomes easier to handle.

Quote:

Design -> check -> all good -> actually no -> rinse and repeat

Such is the nature of the hobby. You will find yourself spending a lot of time working out design details, much more time than you will expend building your contraption and writing basic firmware for it.

You can ease the pain, in a manner of speaking, by first learning how to fly a Piper Cub before you get into the cockpit of a 747 and take off for Tokyo. In other words, avoid the creeping featurism that you seem to be promoting in your present design. Less is more in a first effort, especially if you are expecting it to work.

Quote:

Other than that, it seemed that the circuit that BDD posted would be the easiest solution, which is to absorb pulses from the clock by holding a flip flop's state during a wait state, its output being used as system clock. Doing it that way would not require a lot of qualification across the board, since it would effectively stretch the clock pulse for the duration of the wait state, rather than holding the RDY line low.

The flop used to generate the wait-state in POC V2.2 is part of the CPLD logic—it's not a discrete part. The Ø2 high stretching technique does work and since there are two flops in a 74AC74, I'm using no more PCB real estate than if the wait-state logic wasn't in use.

You should know that my POC V1 units didn't use wait-states at all. POC V1.1 would boot at 15 MHz without the SCSI host adapter in the circuit. Routine operation at that speed wasn't practical, however, as there was no mass storage and the Maxim real-time clock couldn't be accessed—there was insufficient timing margin. The maximum speed that was practical was 12.5 MHz, using a 55ns EPROM. That wasn't bad, considering that my design goal was only 8 MHz.

[Chromatix]

Exactly. If your first build has a fixed 4MHz clock, you don't need to worry about *any* of these complications, as even a 150ns EEPROM will be fine. Get one of those working first, *then* think about refinements to try and make it faster and more featureful.

In fact, once you've got one simple machine working, you might not be so afraid of the relatively simple logic needed to make RDY-based wait-states work. And really, if you're scared by *that*, you have no business trying for any of the more ambitious features you've mentioned so far.

[BigDumbDinosaur]

Chromatix wrote:

In fact, once you've got one simple machine working, you might not be so afraid of the relatively simple logic needed to make RDY-based wait-states work.

The logic is not as simple as you make it to be. Doing it in discrete hardware, in fact, is rather convoluted.

Quote:

And really, if you're scared by *that*, you have no business trying for any of the more ambitious features you've mentioned so far.

That's part and parcel of the creeping featurism problem I mentioned in an earlier post.

[backspace119]

Chromatix wrote:

Exactly. If your first build has a fixed 4MHz clock, you don't need to worry about *any* of these complications, as even a 150ns EEPROM will be fine. Get one of those working first, *then* think about refinements to try and make it faster and more featureful.

In fact, once you've got one simple machine working, you might not be so afraid of the relatively simple logic needed to make RDY-based wait-states work. And really, if you're scared by *that*, you have no business trying for any of the more ambitious features you've mentioned so far.

It's not that I'm scared by it, it's that new edge cases seem to pop up out of no where, complicating it further and further (I'm specifically thinking of qualifying the data latch with rdy right now, and the problems that BDD mentioned that can cause)

BigDumbDinosaur wrote:

Chromatix wrote:

In fact, once you've got one simple machine working, you might not be so afraid of the relatively simple logic needed to make RDY-based wait-states work.

The logic is not as simple as you make it to be. Doing it in discrete hardware, in fact, is rather convoluted.

Quote:

And really, if you're scared by *that*, you have no business trying for any of the more ambitious features you've mentioned so far.

That's part and parcel of the creeping featurism problem I mentioned in an earlier post.

Ya, this is why I made ports for video and audio, so I could put off designing those features until later. I really do just need to settle on a lower clock and build this damn thing already. My next machine can do fancy clock acrobatics.

Still, I'll keep this thread going for information I find, and I plan on buying some of the chips mentioned here to prototype with, maybe come up with a working design off of a computer first.

[Chromatix]

My notebook has some sketchy schematics for working with the RDY signal. I'll see if I can flesh those out into a complete wait-state system; I'll want one of those for my own projects.

[BigDumbDinosaur]

Chromatix wrote:

My notebook has some sketchy schematics for working with the RDY signal. I'll see if I can flesh those out into a complete wait-state system; I'll want one of those for my own projects.

Controlling RDY in a 65C02 system isn't too onerous. Doing so with the 65C816 in a machine with more than 64KB of RAM is a whole other challenge.

[BigEd]

It seems to me we could do with another thread, just about RDY, and including all the findings so far.

[Chromatix]

Well, I think I've got a handle on it. Let's start by establishing the circumstances where we need one or two wait-states; both conditions can be generated from one 74109 (JK flipflop pair):

The 28L92 UART will work without wait-states at up to 8MHz with 5V power, or about 6.5MHz with 3.3V power. It needs one wait-state to keep up with a WDC CPU's maximum clock rate at either voltage.

SRAM can be assumed to work without wait-states, as long as a suitably fast part is used. An inexpensive 55ns part is sufficient for 8MHz at 3.3V. (These parts likely run faster at 5V, but that aspect of their performance is not specified in the datasheet, only that they will *tolerate* being used in a 5V system.)

Atmel EEPROMs with individual byte-write capability are available with 150ns access time at 5V in PDIP format, and with 200ns access time at 3.3V in SOIC or PLCC format. The 150ns parts require a 100ns /WE pulse width for in-circuit programming, and the 200ns parts require a 200ns /WE pulse width. Both have a much shorter /OE access time than address access time (noting that the CPU's address lines become valid some time *before* Phi2 goes high, including the bank address because that "shines through" the transparent latch while it's open).

So the 150ns parts can be run at 5MHz (or more safely at 4MHz) for both reading and writing with no wait-states, require one wait-state for up to 10MHz, and two wait-states permit full 14MHz operation of the CPU.

The 200ns parts will run at 4MHz for reading only with no wait-states; the relatively slower write cycle requires reducing that to 2.5MHz for programming. Introducing one wait-state increases the limit to 7.5MHz for both modes of access; you could then sensibly run both the CPU and a UART from a single standard 7.3728 MHz oscillator, and reuse the same wait-state logic for safe UART access. If you prefer 8MHz as a round number, you'll need two wait-states on the EEPROM to be safe, so overall performance may be slower if you run a lot of code from ROM.

Jeff's 74109-based circuits trigger RDY to change just after the rising edge of Phi2, so we can assume RDY to be stable during the Phi1 phase of the clock - a very useful property. They also naturally provide /RDY without an additional inverter gate, because each flipflop includes both Q and /Q outputs. We want the bank address (and thus /CE), /OE and /WE to remain stable while RDY is held low, and the necessary logic equations involve /RDY, so this is very useful. We can lead the positive RDY signal straight to the CPU pin, through a parallel RC circuit to avoid conflicts upon executing WAI or STP.

Normally, the bank-address latch is triggered by ~Phi2. To avoid corrupting the bank address, replace that with ~(Phi2 | /RDY).

One of the things we want to do with an '816, as opposed to a 6502, is to qualify /OE and /WE with (VDA | VPA), so as to suppress spurious accesses during "internal operation" CPU cycles. The equations without wait-states would be:

/OE = ~(R/W & Phi2 & (VDA | VPA)) = (~R/W | ~Phi2 | ~(VDA | VPA))
/WE = ~(~R/W & Phi2 & (VDA | VPA)) = (R/W | ~Phi2 | ~(VDA | VPA))

Wait-states require that *either* Phi2 high *or* /RDY high are sufficient to qualify these signals, and this is most convenient to arrange with the latter form of each equation, though it increases the gate depth from Phi2 by one level (compensate for this by using a fast logic family such as 74AHC). We get to reuse the ~(Phi2 | /RDY) signal from the bank address trigger:

/OE = (~R/W | ~(Phi2 | /RDY) | ~(VDA | VPA))
/WE = (R/W | ~(Phi2 | /RDY) | ~(VDA | VPA))

We also need to qualify the wait-state circuit's trigger with (VDA | VPA), so that a spurious access that just happens to select the slow EEPROM doesn't trigger an unnecessary wait-state or two. Since we're already generating ~(VDA | VPA) in the above, we can trigger the wait-state logic with (~(VDA | VPA) | (/CS_UART & /CS_EEPROM)) for example.

Is there anything I missed?

[backspace119]

Chromatix wrote:

Well, I think I've got a handle on it. Let's start by establishing the circumstances where we need one or two wait-states; both conditions can be generated from one 74109 (JK flipflop pair):

The 28L92 UART will work without wait-states at up to 8MHz with 5V power, or about 6.5MHz with 3.3V power. It needs one wait-state to keep up with a WDC CPU's maximum clock rate at either voltage.

SRAM can be assumed to work without wait-states, as long as a suitably fast part is used. An inexpensive 55ns part is sufficient for 8MHz at 3.3V. (These parts likely run faster at 5V, but that aspect of their performance is not specified in the datasheet, only that they will *tolerate* being used in a 5V system.)

Atmel EEPROMs with individual byte-write capability are available with 150ns access time at 5V in PDIP format, and with 200ns access time at 3.3V in SOIC or PLCC format. The 150ns parts require a 100ns /WE pulse width for in-circuit programming, and the 200ns parts require a 200ns /WE pulse width. Both have a much shorter /OE access time than address access time (noting that the CPU's address lines become valid some time *before* Phi2 goes high, including the bank address because that "shines through" the transparent latch while it's open).

So the 150ns parts can be run at 5MHz (or more safely at 4MHz) for both reading and writing with no wait-states, require one wait-state for up to 10MHz, and two wait-states permit full 14MHz operation of the CPU.

The 200ns parts will run at 4MHz for reading only with no wait-states; the relatively slower write cycle requires reducing that to 2.5MHz for programming. Introducing one wait-state increases the limit to 7.5MHz for both modes of access; you could then sensibly run both the CPU and a UART from a single standard 7.3728 MHz oscillator, and reuse the same wait-state logic for safe UART access. If you prefer 8MHz as a round number, you'll need two wait-states on the EEPROM to be safe, so overall performance may be slower if you run a lot of code from ROM.

Jeff's 74109-based circuits trigger RDY to change just after the rising edge of Phi2, so we can assume RDY to be stable during the Phi1 phase of the clock - a very useful property. They also naturally provide /RDY without an additional inverter gate, because each flipflop includes both Q and /Q outputs. We want the bank address (and thus /CE), /OE and /WE to remain stable while RDY is held low, and the necessary logic equations involve /RDY, so this is very useful. We can lead the positive RDY signal straight to the CPU pin, through a parallel RC circuit to avoid conflicts upon executing WAI or STP.

Normally, the bank-address latch is triggered by ~Phi2. To avoid corrupting the bank address, replace that with ~(Phi2 | /RDY).

One of the things we want to do with an '816, as opposed to a 6502, is to qualify /OE and /WE with (VDA | VPA), so as to suppress spurious accesses during "internal operation" CPU cycles. The equations without wait-states would be:

/OE = ~(R/W & Phi2 & (VDA | VPA)) = (~R/W | ~Phi2 | ~(VDA | VPA))
/WE = ~(~R/W & Phi2 & (VDA | VPA)) = (R/W | ~Phi2 | ~(VDA | VPA))

Wait-states require that *either* Phi2 high *or* /RDY high are sufficient to qualify these signals, and this is most convenient to arrange with the latter form of each equation, though it increases the gate depth from Phi2 by one level (compensate for this by using a fast logic family such as 74AHC). We get to reuse the ~(Phi2 | /RDY) signal from the bank address trigger:

/OE = (~R/W | ~(Phi2 | /RDY) | ~(VDA | VPA))
/WE = (R/W | ~(Phi2 | /RDY) | ~(VDA | VPA))

We also need to qualify the wait-state circuit's trigger with (VDA | VPA), so that a spurious access that just happens to select the slow EEPROM doesn't trigger an unnecessary wait-state or two. Since we're already generating ~(VDA | VPA) in the above, we can trigger the wait-state logic with (~(VDA | VPA) | (/CS_UART & /CS_EEPROM)) for example.

Is there anything I missed?

from the other thread that BDD posted:

BigDumbDinosaur wrote:

Such an arrangement likely wouldn't work. The problem is that the '573's LE has to be kept continuously low after the bank has been latched. RDY would only be low for the duration of the wait-state, which means using RDY to qualify LE would result in LE going high immediately after the wait-state has expired.

This was the statement that was tripping me up about the wait states, but thinking about it now I think that RDY and PHI2 qualification of the 573 should work, since the latch will remain closed if PHI2 is still high after the wait state for any amount of time, and we want the latch to be open after PHI2 falls anyway. I may be misinterpreting this though, there may be something more sinister at work here that BDD was trying to point out.

[Chromatix]

Quote:

Jeff's 74109-based circuits trigger RDY to change just after the rising edge of Phi2, so we can assume RDY to be stable during the Phi1 phase of the clock - a very useful property.
(…)
Normally, the bank-address latch is triggered by ~Phi2. To avoid corrupting the bank address, replace that with ~(Phi2 | /RDY).

I'm pretty sure the above takes care of the bank address. That and the VDA/VPA wrinkle are the only things specific to the '816.

[backspace119]

Chromatix wrote:

Quote:

Jeff's 74109-based circuits trigger RDY to change just after the rising edge of Phi2, so we can assume RDY to be stable during the Phi1 phase of the clock - a very useful property.
(…)
Normally, the bank-address latch is triggered by ~Phi2. To avoid corrupting the bank address, replace that with ~(Phi2 | /RDY).

I'm pretty sure the above takes care of the bank address. That and the VDA/VPA wrinkle are the only things specific to the '816.

This should do it then: