The RC2014 bus has just one clock signal, CLK, used for all system timing. The RC6502 bus is a variant that added two more clock lines, so it has:

• Φ0 (pin 21, the same pin as RC2014 CLK), which is the clock input to CPU pin 37, if an external oscillator is used. (Presumably this line is unused if there's no external oscillator feeding the CPU, though that's not entirely clear as there's no real documentation about this.)
• Φ1 (pin 23), the inverted Φ2 output from CPU pin 3.
• Φ2 (pin 19), the clock output from CPU pin 39 which is used for all timing (including RWB qualification) except for the input to the CPU itself.

In some recent discussions about the RC6502 bus, we've been talking about which of these we can drop to free up bus lines for other purposes. Φ0 has to stay because some CPU boards have the CPU take its clock from a different board. Φ1 seems unnecessary (one can get it by inverting Φ0). I am uncertain, however, about whether Φ2 is really necessary.

What would be nicest is if the bus reverted to the RC2014 arrangement where there's only one clock line. In the case where the CPU internal clock is used (via a crystal or RC network on pins 37 and 39 of a 6502), where the CPU doesn't have a clock output (MOS 6510) or where the vendor specifically says to avoid using that output (WDC W65C02) it's easy: there is only one clock signal that can be put on the bus.

The sticky case is with CPUs that are being driven by an external clock but have their own clock output, which output of course is invariably at least slightly delayed from the clock input. Opinion seems to be divided on which clock to use.

The modern WDC W65C02 has a clock output but they make it pretty clear in the data sheet that it ought not be used: under the timing diagram it says, "PHI1O and PHI2O clock delay from PHI2 [input] is no longer specified or tested and WDC recommends using an oscillator for system time base and PHI2 processor input clock." It doesn't seem to say whether or not the problem might be too little or too much delay on PHI2O.

On older systems (which is really the main area of interest here) it's not unusual to see an external clock on the Φ0 input but the CPU's Φ2 output used for system timing (including RWB qualification). Some examples:

• The VIC-20, the only commercial system I've found that does this (but I didn't look too hard for others).
• Grant Searle's 6502 SBC.
• The Wilson Mines Co. 6502 Primer Clock Generation page seems to show an external clock and the Φ2 output being used for RWB qualification, and the whole computer schematic with the external clock option uses Φ2 out as the system clock.
• And of course the RC6502 bus and boards do this, mainly due to examples like the above.

On the other hand, as well as newer systems that I guess would generally use Φ0 system clock per WDC's advice, plenty of older systems also seem to do this, leaving the CPU Φ2 output unconnected. These include the Apple 1, Apple II and Apple IIc. And of course the C64 must do it this way since its 6810 CPU has no Φ2 output. The same is true of any systems using some of the MOS 6500 family CPUs that were available from the very start, including the 6501 and 6512 through 6515.

Particularly given that the 6501 and 6512 through 6515 had to work properly using Φ0 as the system clock, it seems to me implausible that the internal CPU design was different enough between those and the 6502 that the 6502 wouldn't work in the same way. But that's just my thinking, not based on any actual knowledge of chip design.

Does anybody have any thoughts on this, or any experience with issues using Φ0? Under what circumstances is it reasonable to say that you really should use Φ2 over Φ0?

_________________
Curt J. Sampson - github.com/0cjs

Just in case it's helpful, here's a crystal oscillator external clock to the Φ0 input (yellow) vs. 6502 Φ2 output (cyan) on an old NMOS 6502. (That's the Φ1 output in pink below.) I don't know the exact manufacturer or date of this CPU because it's been relabeled, but from the power consumption (>100 mA) it's definitely NMOS. You can see that there's considerable delay there, though most of it comes from the slow ramp-up of the leading edge; there's little delay on the falling edge.

That's from my RC6502 Apple 1 clone SBC board. I've got some more timing examinations of Φ0 vs. Φ2 vs. RWB on that board that I'll put together and post in a subsequent message, in case that provides any illumination on this topic. (Or maybe in a different topic if I'm finding myself too confused about them.)

_________________
Curt J. Sampson - github.com/0cjs

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

BDD, thanks for your detailed answer. Though I'm operating on the assumption that the external clock will always be clean and properly conditioned, it's good to remember that one needs to be careful to achieve this or it may affect what otherwise would be working timings. I use a can oscillator on my RC6502 Apple 1 clone SBC, and intend to continue using those on other boards.

Last week I 'scoped out my Apple 1 clone SBC to look at some of the timings related to Φ0 (the CPU clock) and Φ2 (the system clock output from the CPU). I was focusing on the data bus here. I now realize I actually wanted to be looking at the address bus, but something of a little concern to me came up with the data bus signals, so I thought I'd post this here both to get confirmation that I'm looking at these things properly and get thoughts on the data bus timing.

The code I'm using to test is a tight loop incrementing a location in memory. Below I gave the address in binary (LSB only) and hex, the data in memory and the assembly language code. I kick the machine off by jumping to $80; the loop is obviously $81-$84. The code at $85 returns to Wozmon; this is executed only if I change the BCC to a BNE to run the loop only for a short time. (I used this to test the code.)


Below the code I have the actions of the CPU worked out cycle by cycle. The details for the cycle behaviour of each instruction were taken from the MOS MCS6500 Microcomputer Family Programming Manual and then confirmed against the timing capture. The T-times above are annotated in the capture below. This is followed by another capture with A3 instead of A0 on the third channel, as that helped confirm that I was correctly differentiating between the program reads (A3=0) and data access (A3=1).



So as I mentioned, this experiment turns out not be properly set up to confirm that the address lines change well before Φ0 rises (which of course would also be well before Φ2's later rise). But it does show that the data bus appears to be changing well after the Φ0 rise on which we'd enable a write, and even probably a little after the Φ2 rise. (The latter is harder to determine because it's not a sharp edge.) Following are a couple of single-shot captures of a loop execution where D0 (which changes with every loop) goes from 0 to 1 and 1 to 0, with the third channel now showing Φ2 instead of an address line. The top-half of the capture is at the same time base as the captures above, with a selected area marked, and the lower have is a zoom in to that selected area to make it easier to see the exact relationships between the signals when D0 changes.



I see two things here that worry me.

First, RWB asserts write on cycle T3, while the CPU is still incrementing the value its read, as well as asserting write on T4 when it's writing the now-incremented value. The is not what the book says it should be doing, and this will cause the previous value to be rewritten just before the new value is written. Obviously this isn't a big deal for RAM, but it seems to me it could be problem for other devices, such as output ports that trigger an indicator to a remote device on write (such as with a 6821 PIA's control output pins in certain modes). Those might see this as two sequential writes of the old and new values, rather than just a single write of the new value. Is this kind of thing to be expected with the INC instruction, making it something that just generally should not be used for I/O unless "extra" writes are acceptable?

And second, I notice that the data lines are changing after the Φ0 rise that one might use to qualify the write, and even around or possibly after the Φ2 rise that this board uses to qualify the write. I think this is not a problem for RAM, since the proper data value will have been held for some time before the chip's select and write signals are deasserted, but I'm not totally sure about this. But again, for I/O, this could cause incorrect values to be output, even if just for brief fractions of a cycle, which seems as if it would be a bad thing, and this looks as if it could happen on any write instruction, not just the read-modify-write INC instruction. Is that something that I/O devices are supposed to be designed to be careful of, e.g. by not reading the data lines until the system clock's falling edge?

I guess I need to go back and do some further experimentation to determine timings for the address bus line and a non-RMW instruction, but I'd appreciate any feedback on what I've got so far, and any thoughts on how use of Φ0 vs. Φ2 as the system clock might make a difference to this, and whether it should make a difference to this.

_________________
Curt J. Sampson - github.com/0cjs

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

If you can, it might be instructive to recapture at a slower clock speed. I think this will show that address and control signal changes are caused by the falling edge of the clock, with the rising edge being irrelevant. On the other hand, the databus is not driven during clock low, so will be indeterminate or will hold its previous value during clock low, and then will be driven to the right value as a consequence of, and therefore a little after, the rising edge.

Of course, if the time for the address and control signals to take on their new values happens to be less than half a clock cycle, it might appear that the changes are caused by the clock rising. That's why running slower might be informative.

It doesn't surprise me to see the unincremented value written before the incremented value: I haven't memorised which RMW instructions do this, but visual6502 shows a double write and it's been discussed previously. Any given documentation might be wrong, or might refer to a different design: it was useful back in the day to have such tables of clock by clock behaviour, but they are not definitive, as you've found.

Which "book" is this? If it's talking about the 65C02, then some of the details won't apply to NMOS chips.
On NMOS, RMW instructions access the target address three times: read the original value, write the original value back, then write the new value. I don't think it was officially documented anywhere, but it's well known among demo coders, and is a key part of a popular way of acknowledging interrupts on the C64.

See above:

I'm not clear on why a slower clock speed would make a difference here. Ought the CPU not have the same behaviour and timing constraints regardless of clock speed, so long as the speed is within the ranges on the spec sheet?

Were you perhaps instead trying to say that you felt there weren't enough samples to see the timing accurately with the current 1 MHz clock? (It looked to me as if there there were plenty, even in the small segment in the zoomed in view. It looks like I'm capturing at least a hundred samples per clock half-cycle.)

I'm also finding "the rising edge being irrelevant" comment a bit odd for the purposes of this thread, since aren't we supposed to use that rising edge to qualify things like RWB? The (not insignificant) difference between rising edge timings for Φ0 and Φ2 thus might be very relevant, depending on how early or late relative to one or the other we can be when doing things like reading the address lines.

If your comments were just all about not seeing the address bus relationship with the clocks, that's just because in the second set of captures I don't even have an address line on a probe and in the first set I've not set up the code to properly generate changes that would clearly show the relationship between the clocks, RWB and the address lines. (To do that I need to go redo this experiment to be focusing on the address bus rather than the data bus, as I think I mentioned.) But even from what's there it seems clear that the address is changing after the falling edge of Φ0, and probably after the falling edge of Φ2 (which is very little delayed from the Φ0 at that edge), and given that as far as the address lines go we're always reading around the rising edge, it looks to me as if either clock would be absolutely fine for qualifying that.


This I also find confusing. Did you mean perhaps that the data bus state is not changed during clock low? If it's never driven during clock low I don't see how it could hold its previous value, since there would be nothing driving the bus. It seems to me that if you're supposed to read the data bus on the falling edge of the clock, it must be driven for at least part of clock low or the data might vanish before the reader gets around to reading it.


Ah, so this is known behaviour! Ok, that's fair enough then. And thanks for the hint about being able to use Visual 6502 to check these things.


And still useful today! I'm guessing that the description in the manual was an error or something where an update got missed when the design changed.

_________________
Curt J. Sampson - github.com/0cjs

Sorry, I have been unclear. I will confess I have a hobby horse, which is that the role of the two phases of the clock is often misunderstood, and I'd like it to be better and more widely understood.

I was reacting to this:

because it implies some linkage between the rise of the clock and the change of the address lines. My reaction contained a poor suggestion - that you could learn something important by running at a different speed - and it's poor because it doesn't relate to what we see in your images.

If we imagine a 6502 running at rather a fast clock rate and with rather heavily loaded address lines, I think we will see the address lines settling as late as we like, without relation to the rising edge of the clock. If we then slowed that 6502 right down, we'd see the address lines settling before the rising edge of the clock, simply because enough time has passed since the falling edge. If we only had the second situation to observe, we might not realise the first situation is possible, and that it tells us something.

In other words, without somehow moving the rising edge around in time, it's difficult to infer from observation whether or not it's an important milestone, whether or not it causes anything.

My belief is that the rising edge is a convenient, but not a definitive, timing marker, and that it's potentially confusing when we see people speaking as if it is definitive. We understand the 6502 better if we understand this aspect of the timing, although it's clear that we don't have to understand it (or, agree with me) in order to build interesting things successfully.

However, the whole thing is more complicated because of the data bus, which is indeed driven by the CPU only during the second phase of the cycle (and of course only during a write.) If you have pullups or pulldowns on your databus, you'll see the effect of the undriven bus. If you arrange some other device to access memory during this phase, you'll find you can, because the CPU is not driving. If there's nothing driving the bus, the bus will for a time hold its value, possibly being weakly pulled up, over time, if there are TTL I/Os on it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It's always made most sense to me that the period right around the falling edge of the clock was what mattered for both reads and writes. For RAM it doesn't matter much if you write throughout phase 2 as the data written at the end is what matters. For edge-triggered I/O though it is most important to trigger it after enough time has passed for the data lines to be stable, and you might as well just use the falling edge of the clock as you probably don't have a good way to measure the right data setup time to trigger the write earlier.

As an example, I sometimes use 74HC273 or similar as a simple output port, and its clock needs to be triggered late in phase 2, not right at the start of it - so I use the falling edge. Bus capacitance is enough to keep the data valid long enough after the CPU lets go.

Slightly more distantly related, in my video circuits with bus sharing between the CPU and the video circuit I also delay writes until e.g. halfway through phase 2, because I don't allow the CPU's write address onto the video address bus until phase 2 starts, and I want to give it some time for the address to settle before enabling writes. I could try to enable the transceivers earlier, but there's no benefit though because the data is held valid through to the end of phase 2 so I might as well just write it then. In this case I do have a much faster clock signal that I can use to time things like this within the CPU clock cycle.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The processor used in my captures is relabeled as NMOS and almost certainly is NMOS (unless someone made a CMOS processor that pulls >100 mA; all the CMOS I've seen have been less than one tenth that). The target processors for the original question are both NMOS and CMOS, ranging from antiques all the way through to modern WDC parts.

Continuing, I just want to make sure I'm clear on this: "first phase" is Φ0 and Φ2 low, right?


Well, there is an explicit linkage, is there not? If you follow all the timing calculations transitively, you come up with the conclusion that the address lines must be valid before Φ0 rises, and thus you can (and should?) use Φ0 rise as a signal that address bus value is stable and you should read it then. Or am I getting confused here about how we build systems?

I was not meaning to say that Φ0 rising causes the address lines to do anything, and I am unclear about how my statement could be interpreted that way, since if the address lines become valid before the Φ0 rising edge, that rising edge clearly can't have caused the event that preceded it. (But I welcome comments on where I might have phrased things poorly.)


Wouldn't that be a broken system, then, if you can no longer use the rising edge of Φ0 (or Φ2) to determine that what's on the address bus is now valid (and therefore it's now, e.g., safe to assert a RAM's write signal)? Could such a thing happen if you're obeying all the timing restrictions in the data sheet and not doing things that would cause bus contention?


This is where I'm really confused. If we don't have a definitive timing marker for when the address lines are valid (and can then, e.g., assert a RAM's write signal), how can we have reliably working systems?


I think you by "this phase" you actually meant the other phase, Φ2 low instead of Φ2 high, right?

Looking around at the diagrams, only the one from the 6510 (1982) data sheet gives me much clarity on this, and seems to indicate that A) it will definitely start being driven sometime before the Φ2 falling edge, and B) it will stop being driven some time after the Φ1 rising edge that follows the Φ2 falling edge.

I get conclusion A) from T-MDS (data setup time) being max 200 ms. (at 1 MHz) from the start of the Φ2 rising edge, which is well under the 470 ms. minimum of PWHΦ2 alone even before you add in the length of time it takes the edge to rise (T-R). I get conclusion B) from T-HW (data hold time–write) being a minimum of 10 ns after the Φ1 finishes rising, which is no earlier than when Φ2 finishes falling.




Well, I knew that, but it just now finally sunk in that of course I'm seeing the results of this in my captures above: while I can tell when something starts to drive the data bus, I can't tell when it stops because the data bus won't change much, if at all, when that happens. (Though there is an interesting little "bump" in the zoom of DB0 0→1 increment capture just after the Φ2 falling edge where the D0 level actually increases slightly (a fraction of a volt) for some reason at just the time when you would expect the CPU to stop driving it.)

At any rate, if my above timing analysis is correct, and a correct summary is "on writes the data bus will start being driven sometime after Φ2↑ and well before Φ2↓, and will stop being driven very shortly after Φ2↓," then I think I'm good with this part.

And then, getting back to the original topic of this discussion, I think we can also conclude that, given the relatively huge amount of time between data setup finishing and Φ2 falling, the Φ0 falling edge should also always be perfectly fine for indicating that data on the data bus are driven and stable and so for that particular purpose it's always safe to use Φ0 instead of Φ2. The only way I can see that breaking is if there's some stupidly long delay between Φ0 and Φ2 which would probably mean a system terribly broken in many ways, right?

_________________
Curt J. Sampson - github.com/0cjs

Yes, sorry, my typo there: as the 6502 uses the databus during phi2 high, the free half for other purposes is the opposite, the first phase.

Jeff wrote up a very thorough treatment with animated diagrams here
https://laughtonelectronics.com/Arcana/ ... iming.html
and discussed here
viewtopic.php?f=4&t=2909

You are of course quite right that, for the older parts, you can add up the various maximum and minimum timings and conclude that phi2 is a good signal to use to declare that the address bus is stable, and this is often done. As I say, it's useful. But it's not definitive: in some systems one might have another clock which rises earlier and gives more time to a memory access. It would of course be necessary to derive that clock in a safe way, such as by using a much higher speed master clock to determine the edges.

In the more modern faster parts, it all gets more compressed, and the documentation is lacking. I think I've seen it said that the modern datasheet doesn't really give room for 14MHz operation of a system - but we're saved by the practical observation that we don't seem to see worst-case behaviour.

But to the original discussion, I'm all for a thorough analysis of phi0 vs phi2 and the pitfalls to be avoided.

In the same area as an undriven bus holding a value for a little while, hold time constraints are very important and often overlooked. And slightly behind those is the question of bus contention. Which is to say, commonly one frets about meeting the timing during an access - meeting setup times - but that's only part of the job, as the various devices see the clock fall and the control lines change but need their hold times to be met.