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.
It was an issue with my RAM OE#/WE#/CE# logic. I completely rewired it to switch from CE# to WE# controlled write cycle logic (if this even make sense, basically switched the phi2 nand-strobe from one line to the other) and everything started working fine. I think there was some unwanted delay on the OE# creating this problem (or something else, anyway...). I still can't believe it didn't manifest earlier/worked at all.
Right now my address decoding / logic chips block look like a tangled mess but I'll stick around and post the result once it's all cleared up.
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.
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. I would again refer you to the 6502 primer, especially in this case the address-decoding page at http://wilsonminesco.com/6502primer/addr_decoding.html which has notes also about avoiding problems with stray writes to RAM.
The signals do look very strange. Why do WE\ and OE\ go down together for three cycles at a time, then come up together?
> 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.
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.
I don't think it would be a problem, because he has CS\ gated by Φ2, and R/W does not change until a short time after Φ2 falls. OTOH, there could be a problem if he has a lot of propagation delay between Φ2 and the CS\, a pitfall that's common with beginners who get lots of gates cascaded and the propagation delays accumulated. I think if that were the case though, slowing it down to 10Hz wouldn't help. Mystery. I don't think he has posted a diagram of this computer. BTW, bgulotta, if/when you present a diagram, let me encourage you to make it a true schematic, not just a netlist written around boxes. A true schematic is much easier to follow, even if it's hand-drawn like the one at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU . It doesn't have to have the entire computer on one schematic, but in this case all the relevant glue logic should be on the same diagram, showing all connections.
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.
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.
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.
Thanks for the schematics. The one thing that jumped out immediately was that there's only a capacitor in the reset circuit, and nothing to produce an edge. Some manufacturers had a Schmitt-trigger input on the reset, and others did not. I don't know if WDC's has. I looked again at their data sheet for any specification on this, and found nothing concrete.
On the little computer board shown near the bottom of the 6502 primer's address-decoding page, you can see the 74HC00 quad NAND gate one of whose sections is used for RST\. A CMOS gate without Schmitt-trigger input(s) will act as a high-gain amplifier, but not an infinite-gain amplifier, so you won't necessarily get a fast edge on the output. I don't remember why there's a '00 instead of a '132 (which is a Schmitt-trigger quad NAND which would produce a well defined RST\ output to the processor); but even with the Rockwell R65C02, a problem we ran into with the '00 is that as the RST\ voltage reached a high-enough level for the processor to recognize it as meaning it's time to get to work, apparently what was happening was that as the processor started producing the first signals on its outputs, the tiny bit of noise that got coupled into the RST\ line was making it start over, but the voltage didn't stay low long enough to get a valid reset, only long enough to mess things up. The solution was to put a capacitor directly across the pins, with the leads as short as possible like this, to filter out that noise:
ShortLeads1.jpg (44.1 KiB) Viewed 4067 times
Obviously it won't improve the rise time, only get the noise out of the slow-ish rise. Leads any longer didn't work. For example, in the following picture, the extra inductance from longer leads kept it from working:
LeadsTooLong1.jpg (41.73 KiB) Viewed 4067 times
I couldn't guarantee that that's the source of your current problems, but it's worth looking at, and might solve other problems that could otherwise surface later.
I didn't explain that very well; but there's a reason I put in the 6502 primer's reset page that just putting a resistor and capacitor on the RST\ input won't do the job for processors that don't have Schmitt-trigger reset inputs.
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.
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).
You are correct Jeff. That would be pins 40 and 21 on my WDC 65C02. Thanks for the clarification.
Perhaps you should locate that cap right on the CPU, as he has done.
