My apologies from the start for a verbose post. Some of this is just how to read your scope screen, or at least what I see and think is/isn't important when I look at your scope screen.
Don't knock your oscilloscope - it likely can help solve the problem. One thing I note is that your scope is 2 channel, but you are only showing 1-channel shots. Because everything is timed to the clock, having the clock on one channel (and triggering off that channel) and using the second channel to probe around (with both channels on the screen) can help us see timing issues. The data lines, in particular, have times when no-one is driving them and they can float (which likely explains some of the curved sections of your data lines; with pullups they will trend in the upward direction when not driven by an output).
Let's go through your scope shots and I will tell you what I see in each one, and then recommend some useful places to look based on what we think the issues might be. I am not an expert on the 6502, but I use oscilloscopes all the time for work (both nice/expensive ones and cheap ones - sometimes the cheap ones are easier to use).

Thank you for clearly describing how you grounded your probe. I see a reasonably good looking square wave at 1MHz. I can see that you have properly adjusted the compensation on your probes (assuming you are using the 10X setting, which you should prefer when possible). I do note that GND (indicated by the thicker yellow arrow at the left of the screen) is in the middle of this waveform, but then I also notice that channel 1 is in AC mode by looking in the lower left and seeing the sine wave next to channel 1. AC mode subtracts the DC offset and puts the "average" voltage at 0V on the screen. We will generally prefer DC mode for all waveforms for digital logic work except for a few special cases. I do see a little wiggle at the bottom of the waveform, just after the falling edge, that might be something interesting (especially if it shows up in other places at larger amplitudes), but it is unconcerning at the amplitude shown. This is a perfectly good clock here, but it's right at the oscillator output - you will want to see what it looks like in other places (using the ground of the chip you are probing it on).

This looks like a very good A0 signal. I don't see anything that concerns me here. Your ground is properly connected (looking at the large yellow arrow at the left side of the screen). I do note that your scope is showing multiple traces on top of each other (looking at the right side where it appears the signal is high and low at the same time). This is OK as long as you know your scope does this. You might have trace persistence turned on, but a glance in the user's manual for your scope does not show a way to turn it on/off. Because we are potentially looking for "glitches", we actually prefer this mode of looking at things because it will show normal looking traces AND the glitchy one if it happens while the scope is looking.

Normally I might be concerned at the ringing spikes that are not 500ns apart (we expect small ringing at both rising and falling clock edges, but not when the clock is steady high or steady low), however we know (from your previous scope shot) that your scope shows multiple traces overlapped and I see your trigger (the smaller yellow arrow on the right) isn't at a useful level here. Your trigger is set to 2V rising edge (as noted in the bottom right corner) however this trace has no portion that crosses 2 V in either direction, so the scope is auto-triggering (as noted in the upper left hand corner). This means the scope just picks a starting time (not synchronized with the signal) and draws the trace. Because your scope shows multiple traces of the signal on the screen, we get what appears to be 2 traces, both with the expected ringing at 1MHz rate, but they are not properly overlaid on top of each other. To fix this, move the trigger point up until it is in the trace. I'd move it up to the lowest point (below the 5V level) where it reliably triggers (as noted by "Trig" appearing in the upper left corner of the screen). Having the clock on one channel and triggering off it would also fix this issue.

It's worth noting that the amplitude of the ringing is about +/- 0.5V. That's not a terrible or unexpected level here, but it is worth looking in other places as well. Because they are only one pixel wide, I would zoom in to investigate them, but they should be fine here. It's worth looking at 5V of all the chips, but make sure you are using the ground for that particular chip so you get an idea of what the chip actually sees for power.

This scope shot is interesting. We have multiple overlapping traces of this signal again, which makes things a bit confusing. The only place where the signals really should be overlapping is at the trigger point (noted by the orange T at the top of the screen) and all traces should be a rising edge crossing 2V (as per your settings in the lower right corner). The interesting part here is that D0 is being driven high (rising edge at the trigger point in the middle of the screen) and the immediately driven low about 50ns later on at least one trace. That doesn't look like a pullup driving it high (it's too fast of a rise) and it doesn't look like it is floating - it looks like it is being actively driven high and then low. This might be related to your issue and it is worth investigating.
The other overlapping areas are inconclusive because we can't tell which trace is high or low before and after the transition. Because there is that small gap at the bottom, just after the trigger point, I can tell that there is at least 1 trace that went high and then very quickly went low. As noted by others, the older micros might be too slow to even notice but the newer WDC parts may see that and sample the data during the glitch. Having everything synchronized to the clock using a second trace would likely make this much clearer and help determine if it's a problem or not. If the falling edge is during (or even very close) to that kind of glitch, it might be your problem.

When using pullups, the "shark fin" sections are totally normal. That's the resistor "charging" the capacitance of the bus and is a standard Resistor-Capacitor charging curve. The resistors are there to help finish pulling up for chips that can only pull part-way up but not quite high enough (one of the potential issues were were looking for based on the discussion so far). The data only needs to be valid at the falling edge of the clock (so falling edge would be good for triggering on the clock on a second channel here), so it's technically OK to be in the middle as long as it's not on a clock edge. I don't really see any waveforms that look like the data line isn't getting high enough, and the sharkfins shown look like times the bus simply isn't driven by any chip. The sharkfin in the middle is an entire half-cycle that the bus was not driven. The sharkfin on the right is a little more interesting. The bus was undriven for about 100ns before someone decided it should be low and drove it low (most likely propagation delay in chip select and inside the memory). The little double sharkfin drawn in the same place is a little weird, though.

Your scope is fine and should be plenty good enough to locate and solve this problem.

Recommended setups:
Have both channels on the screen. Trigger on the rising edge of the /CS line of RAM (which will be the end of the RAM read or write cycle, so look at the other lines just before the trigger point) and use the other channel to look at /WE, /OE, and D0 (I'm picking this one because you've indicated D0 is different when it isn't working - when you said a failed memory test showed the "previous" count value) at the RAM chip and also at the 6502. If you make a test program that only reads or only writes to ram, then you will know that all RAM accesses are reads (or writes) when those programs are running and the chip select on the RAM is active (low).

Using /CS of the RAM, rather than the system clock, will let us see only the times your micro is talking to the RAM. It's not clear in the current waveforms if we are seeing the RAM or the ROM (putting the opcodes of the program on the bus) or the micro itself when the data bus is being driven. It would be nice to find an explanation for the approx 50ns wide glitch, or even to verify that it is real. This setup will also let you measure the output voltage of the RAM, specifically, as only the RAM should be driving the bus shortly after it is selected (/CS has gone low) and its outputs are turned on (/OE is also low). Writing a program that only reads from RAM (could be the same location over and over) would help.

You may also want to investigate the other /CS lines on other chips to make sure they AREN'T active (low) when the RAM /CS line is active (low).

If that isn't showing anything interesting, trigger on the falling edge of the clock (because this is when the data will be transferred from one chip to another, but note that not all falling edges have data transfer) and look at the data lines to see if you can reproduce that glitch. If so, it would be good to know if it's only on one data line, or multiple. The data should be valid and stable during the falling edge of the clock and ideally for a little bit of time (eg. 10ns) before and after. Older parts will need a longer setup time (eg. steady BEFORE the falling edge of the clock). Your setup should provide hundreds of ns of setup time. Running at 1MHz is supposed to be rather easy.

Apologies??!!??

That is a WONDERFUL post! Thank you so much for spending, quite obviously, a long time writing it. It is in effect a mini-primer on scoping and I, and I am sure others, will also find it most useful.

Unfortunately it is getting on in the evening now and I am going to have to stop for the night soon but my next session with this project will be applying what you have posted. I will post my observations.

Thank you once more.

Tell me about it!

I received a bench power supply today.

The first thing I did was to try the W65C02S at various lower voltages - with the pullup resistors in. It worked, and really quite well. AT 4.5V it was rock steady. Various memory test programs and my clock program all ran reliably. At one point I even had it running at 5.5V although not reliably. I suspect my original power supply was poor, although my scope said it was smooth.

Anyway, I decided to get brave and remove the pullups. Bad move. It will no longer run reliably -at all.

(Still fine with the R65C02 though)

1. I want to experiment with stronger pullups
2. I want to apply the knowledge from SamCoVT's wonderful post above.
3. I need to spend tiome digesting the fantastic input from DrJeffyl, plasmo and BDD - and others. Thanks for all your thoughts.

I'm just sorry I don't have more time to devote to all this. What with work and "real life" this all just drags on. Please understand I am not ignoring your input, I just don't have enough hours in the day. It will get done, just timeframes are going to be a little longer.

DrJeffyl suggested a fresh appraisal of the situation. GOOD IDEA. The problem with long threads such as this is that people in the future who may be trying to follow along are faced with hours of reading and digesting. The whole thing becomes unmanagable. I will spend some time writing up where I think we are (and then people who really know where we are can correct me - lol)

I came to the keyboard this eveing and started to type a post to say I was giving up and going to rebuild it. I was very, very frustrated with it. Looking over your posts and then SamCoVT's mini scope primer has really helped me. Yet again THANK YOU.

I forgot about your observation that W65C02 without pull-up will fail even at 4.5V. So I want to return back to your scope pictures discussion: Were they taken with W65C02 with pull up resistors and at voltage of 4.5V? You've removed the pull up resistor to take scope picture of D0, was the program still running OK without pullup at D0? The scope picture show D0 swing 0-4.5V without pull up, so pull up resistor is not necessary at all, at least not for CMOS/TTL compatibility consideration. But yet, it won't work without 8 pull up--but wait, it did work with 7 pull up (no pullup on D0), did it? Perhaps it'll work with 4 pull up or maybe just one pull up on the critical data line? Maybe it is just one data line that's problematic?

Hmmm, why do you need pull up on data bus when pull up are actually not necessary? Now suddenly I'm wondering whether this is a test software problem... Please send me your test software so I can run it on my setup which currently has no pull up.
Bill

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

Sorry folks, I will be away from home a few days so no testing. Just letting you know so you don't think I am being rude and ignoring you. Will try to answer some of your questions this evening.

Hi plasmo,
I have to say I can't 100% remember the exact conditions when I took the screenshots bu here goes:

I'm pretty sure the voltage was 4.6-4.7V. Yes, it was the W65C02.

No, it was unstable. I kept restarting it.
It did work with only 7 pullups but still unstable. Not sure if it was more unstable or not!

An observation:
I can see no discernable difference in voltage swing on D0 (no pullup) and D1(with pullup). That's interesting (well, at least to me it is!).

I am away from home so can't send you my clock program (it needs a display - although it also outputs time on serial). As for memory test program - I use yours. It fails usually within 30 mins. It seems better at lower voltages. I need to do more testing. Won't be until next week though.
Cheers

Thanks for your observations BDD

Okay everyone, I have had some time to think.

Whilst I am confident I made no wiring mistakes - the fact it runs with the Rockewll CPU tells me that, must be the case, I have neverthless decided to start again - in fact I have already started. I had already purchased all the required bits and I have spent an inordinate length of time troubleshooting this board.

I will post picturs as I build it.

Is it too late to make a suggestion regarding layout? I'll tell you what I'd consider, and why.

Your original layout (above) is quite compact, and has all the major chips aligned with pin 1 toward the north, which is nice when troubleshooting -- you don't have to stop and think where pin 1 is. But, on the downside, the data bus pins (labeled in pink) don't necessarily align from one chip to the next. For example, among the eight databus lines, the CPU and the two VIAs have d0 toward the north and d7 toward the south. This is a partial mismatch with the RAM/ROM and a compete mismatch with the two 6551s, which have d7 toward the north and d0 toward the south.

I realize you're working with wire-wrap, and it's not really a problem for the eight data lines to do backflips and cross over one another on short notice, as it were. But consider the layout below. This too is a compact layout, and not only do the databus pins align nicely from one chip to the next; the low eight address lines (labeled in green) do, too. And favorable alignment is a distinct advantage if the design should ever migrate to PCB.
And... there's an advantage even with a wirewrap implementation. Let's face it; wirewrap is labor intensive. It takes a lot of work! But I found a useful shortcut that applies when a row of pins on one chip needs to connect to a row of more-or-less adjacent pins on the neighboring chip. What I do -- before the wire wrapping starts -- is make those more-or-less adjacent connections with bare, fine-gauge wire, soldered as it reaches each pin. YMMV, but I find this a lot faster than wirewrapping. It also conserves height on the wirewrap pins.

The red arrows indicate two sets of opportunities to use the soldered approach... and the ones on the right are actually triple decker because I included a SIP socket for a pullup array. (The socket may end up unpopulated, but it's there in case we need it.) And the soldered approach I'm suggesting avoids a total of 48 wraps.

Just a suggestion! I admit the idea involves a degree of tradeoff. But I'm lazy, and I would seriously consider doing it this way! (and all the more so if a PCB implementation might someday exist)

Even if you do use wirewrap, adjacent connections are still easier because the wire can be entirely bare -- you needn't leave any insulation.

-- Jeff

Afterthought: because they connect to the Outside World, there might be an argument for putting the VIAs on the outside (like this):

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

Beyond what Jeff said,

You may want to take the approach of "less is more". IOW, build a simpler system initially. Less possibly being:

- CPU
- SRAM
- EEPROM
- UART

and some glue logic... a DS1813 for reset, the combination of 74HC00 and 74HC30 chips which will allow chip selects for SRAM, EEPROM and a single I/O device, along with the read and write strobes for memory.

It will take less time to build and if you run into problems, there's less to go through to find the problem. You can make it a nice and compact layout.

Of course, post pics as you go through the process, whatever you decide on.

_________________
Regards, KM
https://github.com/floobydust

Oh dear, I feel really so guilty now. I have progressed beyond being able to implement your thoughts. DrJeffyl and floobydust, thank you so much for all your time though.

First I did this:


and then this:


This is where I am at the moment. I will pause to hear comments before continuing.

You're welcome. And I can easily understand your eagerness to move forward. Moreover, since this thread began you've been subjected to an absolute barrage of information and opinions! It would be no wonder if you sometimes feel the urge to tune out the external noise and instead rely on your own thoughts and intuition.

Looks good to me. I can't see all the bypass caps, but I'd say the example below is satisfactory. Myself, I might've opted for an SMD cap located on the wiring side (not the component side), but that's a small-ish distinction.
Just one minor suggestion. As you continue to add wiring, it's maybe a good idea to stop occasionally and check for continuity between ground and +5... and of course there should be none. But if you've accidentally created a short somewhere then it's better to be aware of that sooner rather than later.

-- Jeff

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

Hello Jeff. You are very perceptive. There has been a lot to think about and you are right about all the input from everyone (and for which I remain very, very grateful). I decided I could battle on and keep trying to troubleshoot it or just start again.The problem has been that each area - components working - wiring - glue logic - timings etc - each area has worked at some point so "there is nothing wrong", yet plainly there is.
I'm not quite sure where I will be if it still has the same problems - but we will cross that bridge when we come to it


Ahh, yes, the caps. Here's the other side (black things are the legs temporarily on the top side while I work on the bottom):

I never even contemplated putting SMD components on perfboard but I see now that you can. Why though choose SMD over the through hole ones? Are they better? I guess no leads??
Which "leads" me on to the next question (sorry about that)... What value? Arrrggh!! I used 10nF. Some say 100nF. I mentally tossed a coin. I might put both on the CPU chip. Good idea?? I put both (and a 100 uF) on the voltage regulator.

Some notes on the pic
1. the edge connector is just a short cut round the voltage regulator straight to my new bench power supply. It wont be used when its all finished.
2. I had a DS1232 MicroMonitor knocking about so I put it on in place of the DS1813 - which I used for the NMI (at someone here's suggestion). I have defeated the watchdog function temporarily by wiring that to A0 - although, thinksing about it as I type - it does add another load to that address line and we are supposed to be giving this thing every chance of working so maybe not such a good idea. Never mind, I can always remove it from circuit and just use a pushbutton and capacitor!
3. I haven't put the socket for pull-ups in. I can add that later if I have problems.

Oh, I promise you... test, test, test, test... after every few connections!!