6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri May 03, 2024 6:11 pm

All times are UTC




Post new topic Reply to topic  [ 38 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 3:25 pm 
Offline
User avatar

Joined: Wed Aug 17, 2005 12:07 am
Posts: 1207
Location: Soddy-Daisy, TN USA
Hello all. Been a lurker around here for a long time.

I've programmed the 6502 since I was 12 years old (30 years!!! WOW I'm old).

I'm an amateur when it comes to the actual circuits but I've been dabbling with Arduinos, Parallax Propellers, sound chips, etc. So I have a very basic understanding. And "basic understanding" is being kind.

Anyway, I am brainstorming some ideas for my first 6502 based computer. So I want to start slow.

But one thing that is confusing me, is how the 6502 and the Φ2 really work together. For example, the 6502 has a clock input (Φ0) of 1MHz (for example). And that Φ1 and Φ2 are OUTPUTS.

So, could someone please explain to me what the purpose of Φ1/2 really are? I see them used in address decoding, etc. But *why*?

I have many more questions but I will leave it at that for now.

Thanks!

_________________
Cat; the other white meat.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 4:20 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
The clock tells a circuit which half of the cycle it's in. We usually use phi2, which is low in the first half of the cycle and high in the second. Because the address lines change at the beginning of the cycle, and because it would be unsafe to write to a chip while the address lines are changing, we usually use the clock signal to control the write. If writing is restricted to the second half of the cycle, we can assume that the address lines are stable, the decoding logic has done its job, and exactly the right location in the right device is selected.

The other thing often done is to qualify a chip's output drivers with the clock. If chips only drive in the second half of the cycle, then there can't be a conflict between the device activated by the previous cycle and the one activated by the present cycle. That is, in case the first device is a bit slow to turn off its drivers, for whatever reason.

In an aggressive design, the small phase difference between the input clock and the output clock might be important, so early NMOS designs would (I think) typically feed a clock into phi0 and use the phi2 output for all other purposes. More recently, WDC has given some advice which is I think to use the input clock for all purposes. Better you check that though!

Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 4:55 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8172
Location: Midwestern USA
cbmeeks wrote:
But one thing that is confusing me, is how the 6502 and the Φ2 really work together. For example, the 6502 has a clock input (Φ0) of 1MHz (for example). And that Φ1 and Φ2 are OUTPUTS.

So, could someone please explain to me what the purpose of Φ1/2 really are?

The Ø2 clock input is the "regulator" that sequences the circuits within the microprocessor (MPU). With each rise and fall of the clock, the internal gates in the MPU operate in various ways, depending on the instruction being executed. This causes the 6502 to set up bit patterns on the address bus, read or write data, add and subtract numbers, and so forth. So it can be said that the Ø2 clock is the master clock for the computer.

In the old days, the clock generator circuit wasn't capable of driving other devices that required the clock signal, such as the 6522 versatile interface adapter (VIA) or the 6551 universal asynchronous receiver/transmitter (UART). Hence the MPU was equipped with two clock outputs to drive other devices that also need a clock signal. Those outputs are Ø1 out and Ø2 out, often referred to in schematics as PHI1O and PHI2O. Ø2 out is essentially a strengthened Ø2 in, and Ø1 out is the inverted form of Ø2 out—that is, when Ø2 rises, Ø1 falls. Due to internal gate delays in the MPU, Ø1 out and Ø2 out slightly lag Ø2 in. To avoid confusion, the clock input was referred to as Ø0 (PHI0). The modern CMOS form of the 6502, the 65C02, refers to this input as PHI2. I just call it Ø2.

Although the 65C02 still has the Ø1 out and Ø2 out signals, their use is not recommended in new designs. These signals exist primarily to allow the 65C02 to be retrofitted to a unit that has a 6502 and is using Ø1 out and Ø2 out. Any 65C02 circuit that uses the 65C22 (the updated form of the 6522) or 65C51 (the updated form of the 6551) should have these devices' Ø2 clock inputs connected directly to the clock generator device. Non-6502 I/O hardware generally doesn't reference the system clock (with a few exceptions), so it is possible that the only device connected to the Ø2 clock generator would be the MPU (as is the case in my POC unit).

Speaking of the 6502 and 65C02, we generally recommend that the 6502 not be used in any new design. The 65C02, especially the WDC version (the W65C02S, which is in current production), has a number of improvements over the 6502, as well as bug-fixes that remedy design defects in the orignal 6502, such as the JMP (<addr>) page crossing bug. Also, the W65C02S can be operated at much higher clock speeds than the old NMOS parts, with an official maximum speed of 14 MHz.

Quote:
I see [the clock] used in address decoding, etc. But *why*?

I've often asked the same question, as it is incorrect circuit design.

Using the clock to qualify chip selection needlessly limits the maximum speed at which the unit can run, as half of a valid memory cycle is essentially wasted, greatly narrowing the window in which a read or write on the selected device can occur. Generally speaking, chip selection should occur as soon as a valid address is present on the bus, which occurs approximately mid-way during Ø2 low. As Ed noted above, the read/write signal (RWB) should be gated by Ø2 so that data transfer occurs only while Ø2 goes high. The reason for this is that the data bus is not guaranteed to contain valid data while Ø2 is low (write operation).

In the case of the aforementioned 65C22 VIA and 65C51 UART, these devices must be selected before the rise of Ø2 in order for them to work. Gating their chip selects with the clock would result in no operation. Also, RWB on these devices must be directly connected to RWB on the MPU. As the VIA and UART are clocked by Ø2, they "know" when the data bus is valid and hence do not need a qualified read/write signal.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 5:34 pm 
Offline
User avatar

Joined: Wed Aug 17, 2005 12:07 am
Posts: 1207
Location: Soddy-Daisy, TN USA
Those were some great answers. Thanks for putting so much effort into those.

Unfortunately, the only 6502 I have (not counting the 50+ computers I own) that is breadboard ready is a vanilla, legacy 6502 so it sounds like I need to get some more modern variants.

I originally got into this by reading the Apple 1 Replica book.

Anyway, my 6502 design is going to utilize a Propeller (prop) and, like the Propeddle, I was thinking of using it to clock the 6502. I know 1 MHz would be easy to get out of the prop. I think it can even reliably output up to 128 MHz so I'm assuming it could handle a 14 MHz design.

To show you how old-school I really am, the thought of running a 14 MHz 6502 makes me drool. I mean, to me, that is FAAAST. lol

OK, back on topic.

So it sounds like I should tie Φ2 (output) from the 6502 to my SRAM so that when I am writing, I am doing so in the second half of the cycle? And, that would be pretty much the only reason to use Φ2 at all?

Does that sound right?

I think, however, for my first iteration I will stick to 1 MHz because 14 MHz would probably be more complicated.

Thanks again!

_________________
Cat; the other white meat.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 5:42 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
Be sure to check Garth's primer. His page on address decoding covers the Phi2 question, I think.
http://wilsonminesco.com/6502primer/addr_decoding.html

An old NMOS 6502 is absolutely fine for many purposes. But you won't get one to go at 14MHz! And if you don't already have a supply, or a reason to make an old-school project, then a CMOS device will probably be a better bet.

Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 5:47 pm 
Offline
User avatar

Joined: Wed Aug 17, 2005 12:07 am
Posts: 1207
Location: Soddy-Daisy, TN USA
Yeah, I've been reading that site over and over. :-) Very nice site but I clearly need to do more research for it all to sink in.

I'll probably try to build a hybrid of the Replica One and the Propeddle on a breadboard as my first version. I like the idea of the prop controlling the clock and it should be pretty simple to copy over a small ROM at boot up.

So, if I use the propeller to generate a 1 MHz clock, can I simply "pause" the signal generator when I want the propeller to access SRAM? Would I have to wait for the CPU to finish what it was doing (i.e., finish the clock cycle) before I did anything else?

Thanks.

_________________
Cat; the other white meat.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 6:13 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
It might make a difference as to whether you pause with clock high or clock low. And, to cope with more than a millisecond or so of pause, you certainly need a CMOS part.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 6:16 pm 
Offline
User avatar

Joined: Wed Aug 17, 2005 12:07 am
Posts: 1207
Location: Soddy-Daisy, TN USA
BigEd wrote:
It might make a difference as to whether you pause with clock high or clock low. And, to cope with more than a millisecond or so of pause, you certainly need a CMOS part.


Is that because non CMOS (NMOS??) parts can't handle having their clocks "pulled out from under them" whereas CMOS can?

It seems more and more that CMOS is awesome. lol. But I clearly need to learn more about CMOS, TTL, NMOS, etc.

:-)

_________________
Cat; the other white meat.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 6:21 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
Yes, the NMOS parts are dynamic, like DRAM, so they need to keep running or some on-chip values will change. I forget the details of exactly what you can and can't do with specific parts!


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 6:49 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8172
Location: Midwestern USA
cbmeeks wrote:
Unfortunately, the only 6502 I have (not counting the 50+ computers I own) that is breadboard ready is a vanilla, legacy 6502 so it sounds like I need to get some more modern variants.

You can build with the NMOS 6502, as long as you understand the limitations of this device. As Ed pointed out, you won't be able to run it at 14 MHz, as most 6502s can only operate in the 1 to 2 MHz range. Also, being an NMOS device, its output drive is weak, which sets a hard limit on how much you can attach to the address and data buses—poor drive strength also increases sensitivity to the effects of sloppy construction techniques. As I earlier said and Ed also noted, the 65C02 is a much better choice for a new design.

Quote:
So it sounds like I should tie Φ2 (output) from the 6502 to my SRAM so that when I am writing, I am doing so in the second half of the cycle? And, that would be pretty much the only reason to use Φ2 at all?

Please re-read my previous post!

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

Also, you must not have read the part where I said chip selects should not be gated by the clock. :?

Quote:
I think, however, for my first iteration I will stick to 1 MHz because 14 MHz would probably be more complicated.

14 MHz operation isn't any more complicated than 1 MHz operation—circuit design, hence complexity, is a function of the required logic. The desired clock rate, however, dictates the degree of meticulousness required in the construction of the unit. As Garth Wilson has often noted, you can get away with murder at 1 MHz. At 14 MHz, reactive effects due to sloppy construction techniques may result in an unstable or DOA unit. As I've often advised, learn how to fly a Piper Cub before climbing into the cockpit of a 747. In other words, build for 1 MHz and learn from it so when you do decide to build that 14 MHz unit you will have a high probability of success.

Quote:
So, if I use the propeller to generate a 1 MHz clock, can I simply "pause" the signal generator when I want the propeller to access SRAM? Would I have to wait for the CPU to finish what it was doing (i.e., finish the clock cycle) before I did anything else?

You could, although as Ed notes, this is best accomplished with the 65C02. The NMOS parts require that a minimum clock rate be maintained at all times in order to avoid loss of data from the registers. The WDC 65C02 can be completely stopped with the clock in either phase for an indefinite period of time without data loss.

However, a better way to stop and start the 65C02 is by using the RDY input and not fooling around with the clock. When RDY is high the 65C02 is active and processing instructions. When RDY is low the 65C02 stops at the next Ø2 high and remains stopped until RDY goes high again. While stopped, the 65C02 maintains bus state, which gives a slow device more time to respond to selection and read/write commands—this is what we call a "wait-state". Note that the NMOS 6502 will not respond to RDY during a write cycle, which is yet another reason why the NMOS part should be avoided in new designs.

That said, there's more to allowing both the 65C02 and Propellor device to share access to SRAM than just stopping the MPU. Not only must you stop the MPU, you have to "disconnect" it from the circuit so as to avoid bus contention. With the 65C02 this is accomplished by negating the BE (bus enable) input. As long as BE is low, D0-D7, A0-A15 and RWB will go to the high impedance (hi-Z) state, allowing something else to drive the buses. When BE is brought high again the 65C02 will resume driving the buses.

Similarly, while the MPU has control (that is, acting as the "bus master"), the Propellor must be "disconnected" from the buses, again to avoid contention. I don't know enough about the Propellor to advise as to how you might do this, so you will need to read that device's data sheet for guidance.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 7:09 pm 
Offline
User avatar

Joined: Wed Aug 17, 2005 12:07 am
Posts: 1207
Location: Soddy-Daisy, TN USA
Thanks, BigDumbDinosaur. That was very helpful.

I did read your previous post but it just didn't register with me. But I get it now and it makes more sense.

I'm going to get me a few 65c02's to play with and just forget my NMOS version. I like the idea of just using BE and RDY to control the MPU. This should actually simplify my design because I won't have to dedicate a pin (and a full COG) on the propeller to drive the MPU. I can just plug in my crystal oscillator and be done with it...meanwhile, "properly" interrupting the MPU when I need to read/write to the video RAM.

But just for my knowledge, a NMOS MPU would need something between the addr/data pins and the I/O because the drivers are so weak in those? Something like a buffer? If that's true, then yeah, I can clearly see why using a more modern (CMOS) 65c02 would be better in new designs because of fewer components.

Thanks!


EDIT

Just bought me two 65c02's and two W65C22S's. Now I can only hope they arrive before the long weekend!

_________________
Cat; the other white meat.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 7:48 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8430
Location: Southern California
cbmeeks wrote:
But just for my knowledge, a NMOS MPU would need something between the addr/data pins and the I/O because the drivers are so weak in those? Something like a buffer? If that's true, then yeah, I can clearly see why using a more modern (CMOS) 65c02 would be better in new designs because of fewer components.

Simple designs with NMOS 6502 can get away without the bus drivers, particularly if all the loads are MOS (74HCxx, CMOS memory, CMOS/NMOS VIAs, etc.). The inputs of these essentially take no current except when their tiny input capacitances are charging, ie, when the logic state is changing. If you hang a lot of 74LS ICs on there, then yes, you'll need the buffers. There's no reason to use 74LS though. Use CMOS, at least 74HC. See http://wilsonminesco.com/6502primer/LogicFamilies.html .

_________________
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Tue Jun 30, 2015 11:33 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8172
Location: Midwestern USA
cbmeeks wrote:
But just for my knowledge, a NMOS MPU would need something between the addr/data pins and the I/O because the drivers are so weak in those? Something like a buffer?

Garth answered that but I'll give you a little historical perspective.

Back when computers were built with gobs of 74LS logic, bus drivers and transceivers were necessary to handle the loads. Some of the early machines on which I worked had hundreds of chips, which meant there was quite a bit of loading. The circuits would not have worked without drivers. A side-effect of all this was that the computer consumed a lot of power and generated a lot of heat. This meant that the computer had to have a dedicated power source, and also had to be set up in an air conditioned room.

The introduction of CMOS to computer circuits greatly reduced the steady-state current consumption and the need for bus drivers and transceivers was lessened, although not totally eliminated in some cases. In the process, the air conditioned room was no longer required and the typical CMOS-equipped minicomputer could be plugged into a wall socket.

One thing that a device has to contend with is output loading due to parasitic capacitance. Each time a signal changes state, parasitic capacitance has to be charged or discharged by the device controlling the signal. So even though the current draw under steady-state conditions is extremely low with CMOS hardware, the driving device has to produce enough oomph to change quickly signal states despite the parasitic capacitance. Otherwise, a lazy rise or fall in voltage at a device input can trigger instability.

Physical layout and construction are what ultimately determine how much parasitic capacitance is present in a unit. The problem can be greatly exacerbated if the buses are extended over some distance (also, signal skew and propagation time can become significant). For this reason, it is advised that the MPU's buses not be taken off-board, such as on a backplane.

One of the places where excessive parasitic capacitance can cause no end of grief is in wired-OR interrupt circuits, giving rise to a phenomenon known as a "spurious interrupt." Both Garth and I describe this problem in our interrupt articles—Garth has been bitten by it at least once. I haven't run into it in my designs but have seen it in some commercially produced hardware.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Wed Jul 01, 2015 5:45 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
I'd say that the only real hazard to slow edges in logic circuits is when the edges are clocks or strobes. Early microprocessor systems were expected to be very small, so buffering wouldn't have been necessary - only a large memory system might need it. The later idea of driving video from the main memory also gives rise to a need for some kind of separation.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 6502, Φ2, etc.
PostPosted: Wed Jul 01, 2015 12:08 pm 
Offline
User avatar

Joined: Wed Aug 17, 2005 12:07 am
Posts: 1207
Location: Soddy-Daisy, TN USA
Thanks BigDumbDinosaur for the history lesson. Yeah, I imagine large computers with spinning tapes needing constant air conditioning. I have over 50+ retro computers in my collection but my wife would kill me if I tried to bring one of those home. lol

BigEd wrote:
But make sure you have a clean clock.


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?

My faster crystals start appearing more sine wave in shape. For example, my 14.31818 MHz crystal is pretty much a perfect sine wave (IIRC). I know that is slightly faster than the 14 MHz max of the 65c02 but my point is that at higher frequencies, should I be more concerned with make the wave more square?

Thanks!

_________________
Cat; the other white meat.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 38 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: