6502, Φ2, etc.

[BigEd]

Those can oscillators are fine. If you're pushing the clock speed of your design and need a clock close to 50% mark-space ratio, then you'd normally put in something running twice as fast and divide it by two.

Note that viewing a signal through a limited bandwidth channel (like a scope) is always going to lose some higher frequencies. So for very high frequencies, you might not see a square even if the signal really is quite square. Don't worry too much about that - just be aware of it. The real world isn't digital, but logic gates act like high-gain amplifiers and treat their inputs as if they were digital. It's clock and strobe inputs which need to see exactly the edges you intend, and no more.

There are different regimes for tinkering with digital circuits, and if you just want something which boots and works you can be a lot more slapdash than if you're planning to sell something into a life-critical application. The only caveat is that you might end up with some odd behaviours to debug if you cut too many corners. But if you worry about every little thing you might not get started, which is worse.

[ArnoldLayne]

BigDumbDinosaur wrote:

• Although the 65C02 still has the Ø1 out and Ø2 out signals, their use is not recommended in new designs.

Hi, this is basically what the WDC 65c02's datasheet is stating. So, you are saying that this not only goes for WDC but for 65c02 in general?
I'm asking because I did not find anything about this in the Rockwell datasheet.
Our homebrew-65(c)02-computer ("Steckschwein") has a jumper to choose between both configurations (labeled "WDC" and "Non-WDC" )

/thomas

[BigEd]

I really can't think why WDC added this advice - would be interested to hear theories. To make sense of timing diagrams, you need some reference, but that could be either the input clock or the output clock. (It might be that referencing everything to the input clock, and driving everything from that, removes one source of uncertainty, therefore allowing for tighter timings and a higher maximum speed.)

[cbmeeks]

BigEd wrote:

There are different regimes for tinkering with digital circuits, and if you just want something which boots and works you can be a lot more slapdash than if you're planning to sell something into a life-critical application. The only caveat is that you might end up with some odd behaviours to debug if you cut too many corners. But if you worry about every little thing you might not get started, which is worse.

That's a good point. I've had the hardest time starting because I know there are a million things to do.

My homebrew will never be intended for any serious production run or anything remotely close to life-critical applications.

It's going to be a hobbyist retro computer that you can program. With hopefully the power of an Apple IIe with better graphics/sound. (Maybe close to a C64 now that I think about it).

[BigEd]

There's a world of difference between the two! Several custom chips in the C64, and several years of technological advancement.

[cbmeeks]

BigEd wrote:

There's a world of difference between the two! Several custom chips in the C64, and several years of technological advancement.

Oh, believe me, I know. Been programming them both for 30 years.

Just part of my collection:

Apple IIe (x5)
Apple IIgs (x2)

C64
C64c
C64 (PAL edition)
C128 (x2)

[BigEd]

Right! I was just thinking that sometimes people let features creep in, and it can be another way to not get started. Even character graphics - or serial I/O - is enough to make for an exciting self-built machine. Bit-mapped graphics is one up on that, and then sprite engines another step again. There's a lot of logic buried in those custom chips, and setting out to match it is quite ambitious. Of course, it can be done.

[cbmeeks]

BigEd wrote:

Right! I was just thinking that sometimes people let features creep in, and it can be another way to not get started. Even character graphics - or serial I/O - is enough to make for an exciting self-built machine. Bit-mapped graphics is one up on that, and then sprite engines another step again. There's a lot of logic buried in those custom chips, and setting out to match it is quite ambitious. Of course, it can be done.

I agree with that 100%. In fact, I am a software developer by trade and believe me, I understand all about feature creep.

My first iteration won't contain the graphics and sound like I hope to implement later on. It will more than likely be serial I/O only and closer to an Apple 1 in specs.

[BigEd]

Apple 1 is a good starting point!

[BigDumbDinosaur]

BigEd wrote:

So, don't buffer just because you can! But make sure you have a clean clock.

Exactly, especially in regards to the clock.

Incidentally, some chip manufacturers do quote minimum acceptable input slew rates, such as 5ns per volt. This seems to be more common with 74ABT and 74AC silicon than the other types.

[BigDumbDinosaur]

cbmeeks wrote:

Is it advisable to simply plug in a 1 MHz crystal oscillator (can) directly into the CPU? On my oscilloscope the signal appears pretty "square". Or would it be better to run it through some inverters to square it out a little more?

Most of these can oscillators produce ample drive strength and a clean output. For hobby usage at moderate Ø2 frequencies (10 MHz and under) directly driving the MPU (and 65Cxx I/O if used) from the can is fine. My recommendation is once you cross that 10 MHz threshold you should run the can's output through a flip-flop (e.g., 74AC74 or 74AHC74) to sharpen the waveform and assure true 50:50 symmetry. Naturally, the oscillator's frequency in such a setup would be twice the desired Ø2 frequency. You should do your best to keep the signal path from the Ø2 generator to the Ø2 input on the MPU as short and direct as possible.

Incidentally, Jeff Laughton (Dr. Jefyl) has developed animated forms of a WDC timing diagram that illustrate, among other things, the effects of an asymmetric Ø2 clock.

Quote:

My faster crystals start appearing more sine wave in shape.

As Ed noted, scope bandwidth limitations may be why this is happening. A rule of thumb is that the scope's bandwidth should be at least 10 times that of the frequency being sampled in order to see a reasonable representation of a square wave. Your probe will also have an effect. The probe should be operated in the ×10 mode to reduce capacitive loading on the circuit and the scope's ground connection to the circuit under test should be through the ground pigtail on the probe.

The quality of the probe is also a significant factor. There is no such a thing as a good, cheap oscilloscope probe.

ArnoldLayne wrote:

Hi, this is basically what the WDC 65c02's datasheet is stating. So, you are saying that this not only goes for WDC but for 65c02 in general?
I'm asking because I did not find anything about this in the Rockwell datasheet.

This is design advice from WDC, who designed the 65C02—Rockwell enhanced the original 65C02 design, mostly with added instructions. WDC states that the prop time from Ø2-in to Ø2-out and Ø1-out is neither tested or guaranteed. This advice becomes important at elevated Ø2 rates, as signal slew can cause obdurate timing issues. For that reason, as well as the fact that currently available clock generation hardware has greatly improved over the years, all devices slaved to the Ø2 clock should be driven by the clock generator, not the MPU.

The two clock outputs on the 65C02 are there primarily to allow the device to be used in old hardware that was equipped with an NMOS 6502. There is really no good reason to use them in a new design, as modern clock generation hardware can easily drive many loads, which wasn't the case back in the days of the NMOS parts.

Quote:

Our homebrew-65(c)02-computer ("Steckschwein")...

Snort! Oink-oink!

BigEd wrote:

I was just thinking that sometimes people let features creep in, and it can be another way to not get started. Even character graphics - or serial I/O - is enough to make for an exciting self-built machine.

You are so right! Creeping featurism can not only increase the likelihood of a DOA design, it can result in the project never getting done.

Both of my POC units were designed with serial I/O driving a dumb terminal. By going this route, I was able to concentrate on the core logic and the development of the firmware, and not have to spend many hours trying to figure out how to put a picture on a screen or scan a keyboard. Hence from the time I first sketched out my design until I powered it only about four months elapsed, and it "almost" worked on the first try.

A final point to consider, and one that Ed also mentioned: while construction methods can have a strong influence on the success or failure of your project, some sloppiness is tolerable if you don't intend to run the unit too fast. You can get away with murder at 1 MHz. is something that has often been said around here. Construction can be wires on a perfboard and as long as the logic is right and the wiring is correct, it will work. Only when you decide to amp up the Ø2 rate will construction techniques become important, and that would be the time to do a tight wire-wrap unit, or get a PCB made.

[cbmeeks]

Again, thanks for this great information.

Concerning the scope, I have a Rigol (can't remember the model off the top of my head) but it goes up to 100 MHz. So, you're saying that I would really need a 140 MHz or higher scope to *truly* see how that 14 MHz crystal looks? I've read that before...where newbies like me get confused on how scopes work with higher frequencies. So much to learn.

I'm really pumped about this. UPS says my 65c02's should be in tomorrow. So I hope I have enough parts at the house already to start my first homebrew 65c02. I'm going to stick with serial in/out and 1 MHz for now. I want to "see" it work at the terminal.

My next questions are going to be on how to communicate with it. But I will save that for another topic.

Thanks!

[BigDumbDinosaur]

cbmeeks wrote:

So, you're saying that I would really need a 140 MHz or higher scope to *truly* see how that 14 MHz crystal looks? I've read that before...where newbies like me get confused on how scopes work with higher frequencies. So much to learn.

Correct on the 140 MHz scope.

When I started out with my 65C816 endeavors, I had an ancient Beckman dual channel scope (c. 1972) with a 20 MHz bandwidth. The 12.5 MHz Ø2 clock on my POC unit looked like a sine wave on it and that was with a good probe. Eventually the Beckman died of old age and I replaced it with a refurbished H-P scope rated for 275 MHz, along with a suitable set of probes. Now the 12.5 MHz clock looks like a square wave and the IRQ line pulses look like pulses.

Incidentally, here is the Ø2 clock generator circuit I use.

Ø2 Clock Generator

[GARTHWILSON]

From Wikipedia's article on square waves, here's an animation that shows how the wave looks more and more square as you allow more and more of the harmonics that make up a square wave:



So if the X-axis scale of the waveform diagram were microseconds, it would be a 1MHz fundamental frequency. A square wave (with 50% duty cycle) has odd harmonics. There are no even harmonics unless the duty cycle strays from 50%. They show it with just the fundamental, then add the 3rd harmonic (3MHz), then add the 5th (5MHz), the 7th, 9th, 11th, etc.. You can see that by the time it gets to the 9th and 11th harmonics (9MHz and 11MHz), it's looking pretty square. It wouldn't look quite as good if those were down 3dB and their phase were lagging as would be the case with a 10MHz 'scope, but not too bad.

As has already been mentioned, note that even a good probe in the x1 position is only good for a couple of MHz. You must use the x10 position to get the probe's rated frequency. The frequency rating on an oscilloscope is not an absolute cutoff. It's usually the frequency where the response is down 3dB; so there will be very little difference between a 100MHz 'scope and a 140MHz 'scope in that respect. A given harmonic, say the 9th or 11th harmonic of 14MHz, ie, 126MHz or 154MHz, will be there on both, but will be slightly more attenuated on the 100MHz 'scope than it will be on the 140MHz one, and not ideal on either one, but mostly adequate for the job. When I put 70MHz square wave on one of my 20MHz analog 'scopes, it shows a small sine wave, quite attenuated.

As for using a flip-flop to divide the clock frequency by two to get a 50% duty cycle: Having the duty cycle off a bit (say 60/40 which is often the worst-case spec on oscillator cans) is perfectly fine if you're not pushing the speed limits of the parts. Jeff Laughton's animated timing illustrations that BDD mentioned are at http://laughtonelectronics.com/Arcana/V ... iming.html .

The 6502 primer's page on "General Steps for a Successful Project" is at http://wilsonminesco.com/6502primer/steps.html .

[ArnoldLayne]

BigDumbDinosaur wrote:

ArnoldLayne wrote:

Hi, this is basically what the WDC 65c02's datasheet is stating. So, you are saying that this not only goes for WDC but for 65c02 in general?
I'm asking because I did not find anything about this in the Rockwell datasheet.

This is design advice from WDC, who designed the 65C02—Rockwell enhanced the original 65C02 design, mostly with added instructions. WDC states that the prop time from Ø2-in to Ø2-out and Ø1-out is neither tested or guaranteed. This advice becomes important at elevated Ø2 rates, as signal slew can cause obdurate timing issues. For that reason, as well as the fact that currently available clock generation hardware has greatly improved over the years, all devices slaved to the Ø2 clock should be driven by the clock generator, not the MPU.

The two clock outputs on the 65C02 are there primarily to allow the device to be used in old hardware that was equipped with an NMOS 6502. There is really no good reason to use them in a new design, as modern clock generation hardware can easily drive many loads, which wasn't the case back in the days of the NMOS parts.

Hm, then I should be able to leave that jumper always in WDC position.

BigDumbDinosaur wrote:

Quote:

Our homebrew-65(c)02-computer ("Steckschwein")...

Snort! Oink-oink!

Precisely!