Hi Guys!

I have started playing around with the W65C02 at a low clock speed and a basic circuit consisting of essentially the CPU rom and clock (just 1 Hz). All is going well so far, with just a simple routine of reset vector pointing to $C000 and a jump command looping back to $C000. Monitoring it with a logic analyser shows that it's doing what it should.

I am now attempting to run the circuit by having the BE pin go high on the positive phase of the clock, making the CPU go into high Z on the negative phase (so I can make another circuit use the RAM/ROM on the low phase - like what the C64 did with the VIC2 chip).

I can see that it is going through the reset sequence correctly and can see that the ROM has $00 $C0 at the reset vector, but right after that it goes straight to address $0000 and not $C000. If I tie the BE pin high, then reset, it works correctly.

I read in the timing that it needs 30nS for things to become valid on the W65C02, so I added an inverter and cascaded the inverters to give a ~54ns delay.

Here the 1Hz clock is being fed to BE and tapped from there through the inverter chain and fed in to PHI2 on the W65C02, in an effort to keep the timing happy, but the problem still remains, the addresses the CPU requests are inconsistent (after the reset process settles down).

Again, I can tie BE high, reset the CPU and all is happy.

Are you not able to use BE in this manner? I know the CPU starts setting up the address in the low cycle and was hoping it would merely keep the address lines in high-z. Or does BE low also stop the CPU for doing things internally?

I can look at adding a few buffer chips if needed between the CPU and address bus if this method won't work.

Love to hear your thoughts. Many thanks in advance.

Welcome! I suspect you need to look at the falling edge of phi2 - that's where the interesting stuff happens. The CPU needs to see valid data from the ROM at and around that edge. If you're dropping BE early, before that edge, you might well be disturbing things.

Hi there! Thanks for the reply. Funnily enough, I was just reading this page (https://laughtonelectronics.com/Arcana/ ... iming.html) and realised exactly what you just said, that the data is read all the fall of phi2. Previously I figured it must have been happening mid clock cycle.

I have pull down resistors on the address and data lines, so I’m suspecting that it is reading the reset vector as $0000. Even though my logic analyser is reading correct data in the reset vector as $C000, as it’s reading the data shortly after the phi2 goes high.

I’ve packed up for the night, so I’ll make some adjustments in the morning and let you know. Exciting times! Having great fun here. This is something I’ve wanted to do since I was a kind in the 80’s! Hehe!

Thanks again! Will let you know how it all goes.

Glad you're enjoying the adventure! Did you add the pulldowns because you found you needed them, or because it was recommended somewhere? It's an unusual choice.

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

Hmm, I think I'd put that just a little differently, although the effect might be the same.

First, if you happen to be using one of the chips which uses the rising edge of phi2, then you need its inputs to be stable before then.

And secondly, for writes to be safely written to the correct locations, you need the addresses to be stable before write enable becomes active.

(If that's not right, let me know and I'll rewrite it - or retract it!)

That thought struck me, too.

To perform an access, a memory (or IO) device wants to see two parts to the cycle: an inactive time during which its address inputs stabilize (satisfying the setup time), then an active portion during which an actual transfer (such as a write) occurs.

Normally these correspond to the 65xx's Phi2-low and Phi2-high phases -- the two phases "add up" to one complete access. But, doubling that up to accomplish two accesses (by two devices), I think you'll want each of the 65xx's phases split in half so the memory or IO device still gets two parts to every cycle (as described above). IOW, four phases altogether:

- setup time for access 1
- data transfer for access 1
- setup time for access 2
- data transfer for access 2

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Of possible interest, the insides of the Oric Atmos, a 6502 machine:
http://oric.free.fr/HARDWARE/timing.gif
http://oric.free.fr/HARDWARE/ula.html

Wow! What an amazing community. I go to be and wake up to all this info! Huge thanks to you all.

Yeah, I do realise I'll be up against quite a few timing constraints with what I am attempting to do, with keeping R/W, address, and data states legal. I'll be re-reading through these posts and putting the puzzle pieces together bit by bit, hitting each problem as is comes along. I think half the fun of projects like this is the challenge itself and as much as it is the end result.

The reason for the pull down resistors, was more so I could get things to a known state (using pull ups where that default is better suited). So pull down is unusual? What's the norm, pull up? Or just none at all?

Thanks once again too! It is amazing to see the enthusiasm in this community. I truly wasn't expecting this. Most corners of the internet seem to be filled with 'gatekeepers' and other unpleasant types these days. I can already feel this place is something special!

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

Ah! Very good point.

As mentioned, they are mainly there to give a known good state on my early prototype board. I had some issues early on where I had the last address pin floating on the RAM (128K chip) and it was giving odd results, as you'd expect. But yes, I could just as easily tie that last pin high, through a resistor. Through a resistor as I don't want it permanently 'high' as I am using the same RAM on a VGA board that I made.

Which brings me back to my motives of running the CPU on one phase. My plan is to run my VGA board on the low phase (inverted), so they can share the same RAM at the same time.

So in the end, I can probably discard the resistors on the address and data lines.

BTW, now got this bad boy running on one phase (only 60Hz) as I type this. CPU is just reading at the moment though, to I still have a way to go. Just running the following code.



Nothing too exciting, but it seems stable at the moment.

[edit]
Current timing in the pic below. All working well, but haven't attempted to perform any writes on RAM yet, which I'll expect I'll have to make further 'enhancements'.

BTW, what's the preference on this forum regarding progress pic/info? Happy for me to post in this thread as I go? Or is that a 'no no'?

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

Thanks once again for the info there. Funnily enough, Western Design Center recommended your site to me themselves over on Twitter.

Tons and tons of awesome information. You have done extremely well!

I'm now attempting to perform writes on RAM, which seems to be working to an extent. But then the program counter goes off in to cyberspace somewhere, shortly after the write. About to step through and see if the opcodes and operands are what they should be (might have a loose address or data line - or could be completely something else.



If my coding is correct, it should be storing a value at 'data', incrementing it (which I can see that it is) and looping somewhere around the $C0xx area depending on the branch test. But, presently it jumps somewhere seemingly random shortly after the write to 'data'.

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

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