So I have finally had a chance to start debugging the timing issues I am having on my 6502 SBC. Issues that persist unless the phi2 clock is running at a snails pace (~11hz). The stack definitely seems to be getting corrupt and the RTI command is jumping back to some random place in RAM. I hooked up my scope and noticed that the phi2 clock was taking over 3 times longer than spec allowed to rise and fall ~15ns. I then looked at the PCB schematic I used and there was a resistor in line with the clock input into the 6502 that was causing the delay in rise and fall times of phi2. I removed this resistor and added a decoupling capacitor for the crystal oscillator. Now the clock signal looks much better and is now in spec with < 5ns rise and fall times in the 6502 datasheet. I have attached a before and after photo of the clock and SRAM control signals. The program issues persist, but I feel I am making progress. I am currently qualifying the CS signal of the SRAM chip with phi2 being high. I wonder if I shouldn't also be qualifying the WE signal of the SRAM chip with phi2 being high as well? Right now it is connected straight to the R/W signal of the 6502. I noticed in another post on this forum a person was having similar issues which went away when he changed his SRAM WE signal to be qualified with phi2 instead of the CS signal. Short blurb from that post is below.

Note: click to zoom image
https://imgur.com/a/0C8ghuW

_________________
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 WE\ input of the SRAM is a "don't care" when CS\ is high (ie, false); so I don't think that's your problem.

Logically, and thinking cycle by cycle, yes. But what happens at the end of a cycle, as CS goes inactive and RnW goes low for the next access? There could be a race there. I think qualifying WE might be different in practice, and a better idea.

Can't say if that's what's going on here though, but tying up all the loose ends is a good idea before digging into hypotheses.

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

Ideally, you start with a sound design, and create a solid implementation, and then you get to debugging.

So yes, it would be very useful to see the circuit diagram. If that looks sound, the next question is whether it's correctly and conservatively implemented. It's easy to make mistakes, and easy to cut corners, but that leads to more of a difficult debugging story.

Originally I had the BE6502 kit setup on breadboards. It appears he used Garth's primer for all of his decoding logic. I wanted to free my breadboards up so I moved it all over to a PCB created by another gentleman. The link to the schematics for both are included below (the PCB version I removed R19 that was causing unwanted delay in rise and fall times of the clock). The problem persisted in both designs. I also have a spare 6502 and replaced it just to see if anything would change. I'm beginning to wonder if it wouldn't be fruitful to get a hold of another ram chip or 2 and try them out. I wonder if the one I have is faulty.

https://github.com/tebl/BE6502-Build-a-65c02-computer/blob/master/BE6502%20SBC/export/BE6502%20SBC.pdf
https://eater.net/6502

First thing to check, I'd say, is the design: is it certainly a safe one? And then, the implementation: is everything connected as it should be? No shorts, no opens, no modified connections, all the right chips, and the decoupling caps and power supply in good order.

For everyone, I think, the key to success is lots of attention to detail, and checking things in preference to assuming them. Something isn't behaving as you expect, and so something is not arranged as it should be.

All those little zoogies in the chip select wave forms tell me your bypassing of the clock oscillator isn't doing its job.

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

I'm wondering if I should try another bypass capacitor or one with a different value. Right now I have added .1uF bypass capacitor directly across the ground and power pins of the crystal oscillator.

The zoogies could also arise due to poor power/ground distribution. It's not enough simply for Gnd on the oscillator to be connected to Gnd on all the other devices (and likewise Vcc on the osc to Vcc on all the other devices). What also is matters how the connections are made. The schematic won't specify these important details. But wires that're excessively long or follow a suboptimal route can create trouble.

I encourage you to post some photos of the SBC and a proper schematic. And BTW it's unnecessary to use Imgur. On this forum you can attach images with your post.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.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?

Thanks everyone for all you help. I'm determined to figure the issue out before I start progressing on the software. I definitely don't want to be hunting down a hardware issue when the software gets complex. I've attached an image of the cap I attached to my oscillator. It does look like I have some room to shorten the leads.

There seems to be some confusion between the two capacitors, bgulotta. You've shown a photo of the supply bypass cap on the oscillator, but the cap Garth was referring to -- the one that can cause reset to fail as he described -- is the one between the CPU's /RES input (pin 40) and Vss aka ground (pin 1, except on WDC 65C02's).

Perhaps you should locate that cap right on the CPU, as he has done.

-- Jeff

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

You could instead tie it from the CPU's /RES input (pin 40) to Vdd (pin 8 ). Pin 8 is closer.

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