Hi everyone.
This is my first venture into a home built computer (or even just powering up a standalone CPU) so I'm probably going to make plenty of mistakes ^_^

One thing I've come across having just finished connecting everything up and adding power is that the address bus is alternating between an address location and 0xFF. I'm using an Arduino to tap into the bus and output to 7 segments with some shift registers, but I don't feel like that is causing an issue because when I hold the reset on the 6502, it will either halt on the address value or 0xFF on my display, so that makes me think the problem is with the CPU.

The address location that it displays will increment when I pulse the clock input with the 555 circuit I have, but not consistently and it seems like it will only increment when the display shows the address location rather than when it is showing 0xFF. I also have a 1MHz oscillator connected up and when it switch over to that, the display will run normally with no 0xFF interrupting it.

If it helps to specify the connections I have to the CPU here's a quick list..

VPB - NC
RDY - +5V (3.3k)
PHI10 - NC
IRQB - +5V (3.3k)
MLB - NC
NMIB - +5V (3.3k)
SYNC - NC

RESB - +5V (RC w/ switch)
PHI20 - NC
SOB - +5V (3.3k)
PHI2 - CLK INPUT
BE - +5V (3.3k)
RWB - NC

The data bus is tied directly to VDD and GND to input 0xEA or NOP.

I've been following the Veronica series to get an introduction with Garth's primer info to alter some things to suit the W65C02S.


I'll try and put a video up to show what is happening if it will make diagnosis easier.

Thanks for any help!
Simon

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

Oh sorry, it is a 16 bit bus, but my current display setup only shows 8 bits at a time so I've only got it hooked up to the least significant 8 bits, but i've also tested it on the most significant 8 bits and the same thing is happening.

It's a genuine WDC 65C02S

I don't know if I'm reading your list of connections right.

On the 6502/65c02, Φ2 is an output, not an input. Your clock oscillator needs to go to Φ0, and the Φ2 output then goes to the system. The oscillator should not go directly to the system. On the 65816, Φ2 is indeed an input; but you don't have an '816.

[Edit:] Sometimes Φ0 input is called Φ2 input. In any case, your oscillator should not go to the Φ2 output. If you're using the DIP, the clock input is on pin 37 and the output to the system is on 39.

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

According to the WDC datasheet, there are 3 clock pins:

PHI1O - Phase 1 Out Clock
PHI2 - Phase 2 In Clock <--- which I assumed was the clock input for an oscillator. If I were using a crystal I would have connected it up to PHI2O as well as PHI2
PHI2O - Phase 2 Out Clock

I read your primer and noticed that you (and others) use PHI 0, 1 and 2 but the datasheet has 1O, 2 and 2O

Do I understand correctly that you are able to single-cycle it and examine all the lines each time Φ2 comes high? What memory do you have connected? Any program?

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

No memory or program at the moment, I've hard wired NOP commands to the data bus which IIRC was 0xEA, so after the start up sequence, it should look for memory location 0xEAEA, which will then mean that it reads NOP commands from the spoofed memory by hard wiring the data bus.

I can increment the CPU in a single-cycle fashion yes, but it isn't consistent and only seems to work when the hex display shows a the current memory location that the CPU is searching for, not when 0xFFFF (i'll refer to it in 16-bit fashion for ease of reading) is on the display. I'll upload a video tomorrow (it's pretty late right now here in the UK ^_^) which will explain the behavior a bit better for you if you can see what is happening.


EDIT - I was just fiddling around and I think it may be something to do with the 555 single shot circuit. I'm waiting on some inverters and then I'll try and rebuild that part of the circuit.

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

I believe the 'c02 has a Schmitt-trigger input for phase-2-in, but they don't say how much hysteresis it has. It is possible that with poor construction, when other lines switch, signals coupled into the clock input by stray inductance could result in some "studdering" there, with glitches and runt pulses that put the internals into uncontrolled states.

_________________
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 only this was during term time, I could use my University's oscilloscope to take a look at the signals and timings and such but being a poor student I don't have that luxury

I'll try and reconstruct the single-shot circuit over the weekend and see if that cures the problem. Either way I shall report back soon!

Thanks for the help so far.

Here's the video if it's any help...

http://www.youtube.com/watch?v=1ttkqt5n6SA

So what was different from what I was understanding earlier is that it goes to FF off and on even when the clock is dormant. If you probe the address lines with a DMM (since a dormant clock gives you time to do that), does it confirm what the display is saying? Are the voltages solid 0's and 1's?

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

I've disconnected the display at the moment while I build a different one that will run off the same power as the CPU rather than the Arduino power but once that's done I shall check while watching what the display does.

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