To summarise, perhaps, and to explain the causation: it's desirable for the RAM to be able to pull the output adequately high. So don't load it too much. In this case, don't load it with original type TTL chips.

If the RAM is presented with the challenge of driving chips which demand a lot of current, then it will not be able to maintain a high voltage for a logic 1 output. The 1mA specification in this case represents an upper limit on how much current those receivers are allowed to draw, if the voltage is to reach a good level.

But CMOS inputs take very very little current, and therefore there's no problem if all the loads are CMOS loads.

Original 74-series TTL inputs take a lot of current, so you'd need to select devices from a modern family if you hope to see adequate levels. In fact chips from a modern family might well have CMOS-technology inputs even though they respond to TTL logic levels.

I've been reading back through this thread, and this data point stood out.

It's been suggested in the last few posts that the issue here is a mismatch in logic high thresholds between a particular manufacturer's SRAM and the W65C02.

I'm not convinced this is actually what's going on....

In a RAM test surely that fault would result in unreliable reads (i.e. a '1' occasionally reading back as a '0'). It would not result in missing writes, which is what Adrian observed with his test program (i.e. where the original value remained intact).

If possible I would go back and try to verify this result on the current hardware, as I think it's quite significant.

One possible fault that might cause writes to be missed is a clock integrity issue that caused additional clock transitions to be seen by the CPU. This might generate occasional, very short write cycles. It's possible that cross-talk from several drivers turning on at the same time (during a RAM write cycle) is getting coupled back onto the CPU clock.

Sometimes just adding capacitance (e.g. a scope probe) to the clock pin of the 6502 is sufficient to change the symptoms significantly.

What scope model do you have?

BTW, this is the sort of problem a cheap logic analyzer and the 6502 Decoder can help with. The 6502 Decoder maintains a model of memory, and checks this model on every read cycle. Any inconsistencies are flagged, and you can usually infer quite alot about the nature of a fault from the pattern of errors.

Dave

Yes, that seems to me to be a highly pertinent observation, Dave. The (presumably) NMOS '02 performs far better than the WDC 'C02... and one conspicuous difference between those two chips is the much superior ability of the NMOS chip to input TTL voltage levels.

But another very significant difference is the speed of the manufacturing processes. It's plausible that WDC's modern CMOS process is fast enough to respond to a clock glitch (or contribute to the generation of the glitch, as there may be a regenerative effect from the drivers turning on, as you say). But the much slower NMOS process is comparatively sluggish, and thus much less likely to respond to or contribute to trouble of that nature.

On the subject of glitches, I wonder about the clock oscillator. Perhaps the oscillator itself is defective or not properly specified. But it's also possible that its connections to the CPU aren't optimal. We've devoted some attention to how the various ICs attach to the Gnd/Vcc network, but the oscillator can also deserves review in this respect.

-- Jeff

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

Sorry this is a long one. Several people have kindly posted and I need to anwer them all propely.


Thanks BDD for your very full answer. Very informative indeed.

I do have a simple oscilloscope. I assume you are suggesting single stepping because you are not aware of that or is it for some other reason?


Okay. I don't think I am overloading. I am using all HC glue chips and all WDC CMOS parts.


I will go back and re-test. I'm not at all sure whether its read or write faults any more. A lot of water has passed under the bridge since I made the "read error" statement.

I have a handheld Owon HDS242S. Not a great scope but better than nothing.


You may remember I PMed you a few days ago about the CY7C68013A-56 EZ-USB. I ordered one and it arrived today. Might take me a while to get it working - I have a Windows PC. The Windows Subsystem for Linux might be an option but I don't know about USB support.

I received a REAL Rockwell R65C02 today (the last one I got was an NMOS 6502 in counterfeit markings). The new Rockwell works 100% perfectly. Has been running for three hours now doing a memory test with interrupt driven clock to the display and serial out.

This is the clincher for me. The issue HAS to be TTL/CMOS levels or noise somewhere doesn't it? Is there anything else it can be?

Regarding the clock. The oscillator can is right next to the 'C02 phi2 input pin.
In the attached image (sorry, its old but not much has changed) the 1mHz oscillator is just above the Alliance memory next to the CPU. Its even upside down so the output is nearer the phi2 pin! The wire is about 3/10th inch. I have a capacitor across the power/gnd of the oscillator. Is there anything else I can do to improve things from the point of the oscillator spewing unwanted rubbish out into the rest of the lines? I even (in my naiveity) tried to find micro miniature coax for the clock line. No such thing available as far as I can find.

When you say the oscillator might not be "properly specified". I didn't go to a lot of trouble I will admit. It is marked ECS-2100 and the datasheet says "The ECS-2100X Series clock oscillator offers low current drain and is compatible with HCMOS/TTL logic".

A what?



Thanks for all your testing. I think we are converging on noise (or levels) (or both!).


I'm just nonplussed then.
p.s.
I'm amazed at the speeds you have been able to run it at.

By the way everyone I got fed up with messing about with rubbish power supplies and bought a variable bench supply.

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

On the subject of RAM chips and which are/are not appropriate I went through my inventory of 32Kx8 SRAMs and tried them out in a working design and scoped the data bus for Voh when they were writing.

The system in question is very small, on a 4 layer PCB and running at 14MHz. The components on the data bus are: W65C02, SST 27SF256 EEPROM, an Intersil CDP65C51, the memory in question and a scope probe with a scope attached to it. The capacitance of the data line with the scope attached measured at 62pF.

From best to worst:

Samsung KM68257BP - 4.84V average from 4 samples
Winbond W24257AK - 4.24V average from 10 samples
Cypress CY7C199 - 4.12V from 3 samples
Toshiba TC55328P - 3.53V from 4 samples

The interesting thing is all of these are spec'd the same: Voh=2.4V @ 4ma. Clearly they are not the same.

BTW, they all work in that board with no issues.

Another thing of interest. Given the stray capacitance of 63 pF, you'd expect, according to the spec sheet and the calculation done by Garth earlier in this thread, that these chips would have a 3V rise time of in the order of t ~ (3V*62pF)/4mA ~ 42.6nS.

The worst of them, the Toshiba, was measured at ~4.4nS! 10 times better!


Well, the situation is as clear as mud and in my estimation we can't take any of the data sheet information seriously. From my perspective, I will stick to the Samsung and Winbond chips going forward.

BTW, here is the measurement of the data line capacitance with the scope attached.

_________________
Bill

Thank you BDD. And thank you for the single stepper schematic

(I am (truly, no messing) impressed at the name drop! )


I have a Samsung RAM in the post that I ordered yeasterday because of one of the posts earlier - and a little luck that I chose Samsung

Now...
Here are some recent shots from my (ahem) oscilloscope:
This is phi2 at the 'C02 pin37 with the probe GND lead removed and a GND spring to the oscillator can (its that close)

This is A0 at the CPU. You can see the clock noise

Here is +5V at the oscillator pin

I have the pullup resistors still attached on the data lines, so I disconnected the resistor on D0 and here is a trace of D0 at the RAM chip pin

Here is D1 (with its pullup attached) at the RAM chip pin

Clock noise is everywhere and what are those curved - really slow rise lines on D1 (with pullup) (they are also on D2-7)?

Sorry about the really rubbish scope folks - I know the John Ruskin quote ( https://www.nthong.co.uk/ruskin.htm ) but I regularly ignore it, much to my disadvantage!

Those 5V voltages you are showing on the data lines are likely from the CPU. I do see a runt pulse in one of the data line shots. However, it's difficult to know where that is coming from.

You need to look at the data line when both the RAM /CS and /OE lines are low at the same time. That is when the RAM is driving the data buss.

But that runt pulse is a little weird. It could be a timing problem (two devices trying to drive the bus in opposite directions at the same time), a short to another data line or even a weak device trying to drive the bus high.

_________________
Bill

I don't see anything unusual. Clock noise is normal, some is instrumentation induced. Data lines are generally chaotic; they only need to be stable around the falling edge of the clock. With pull up resistors on data lines you'll see slow rising waveform because of the pull-up resistor overcoming the data bus capacitance. The waveform you need to watch out in any signals (data/address/control) is mid-value steps in the range of 1-2V with sharp rise and fall before/after the steps. That's strong indication of contention. Generally there is a supply voltage spikes coincide with the steps because of large current draw at the time of contention.
Bill

... in the first half of the cycle. To be clear in case anyone's wondering, I'm sure Bill is referring to the Phi2-low time, during which neither the CPU nor memory/IO is driving the bus.


This too perhaps bears clarification, because the empirical testing was published firstly, not subsequently. BDD wasn't convinced. Echoing his comments elsewhere, he remarked, "With modern SRAM and ROM having TTL output levels, I'd find it hard to believe WDC would effectively shut out use of those products by producing an MPU whose inputs will reliably respond only to CMOS levels."

Later he announced, "I have a query into WDC on this." Then further downthread he good-naturedly conceded,
-- Jeff

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

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

'K, thanks. But heck, let's face it -- the alcohol wouldn't do either of us any good! I've just recently started seeing a cardiologist myself. (Nothing terribly serious at this point, thank goodness.)

-- Jeff

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

OK, good. And I've just checked one other detail, which is the rise/fall time. At 5ns max, it satisfies the WDC 'C02 spec. So, that's good... but, to be honest, part of me was hoping to reveal a clue regarding the trouble!

Well, it's not just the signal line; you also want a fairly direct return path between the oscillator and the CPU. I hope and assume the power/gnd pins of the oscillator connect reasonably well to the power/gnd pins of the CPU... ?

BTW, upthread I mentioned (pursuant to hoglet's remark) that a fast logic family can contribute to the generation of a glitch, due to a regenerative effect from the drivers turning on. I'm not convinced your project suffers from this, but as an illustration of the effect you might be interested in the final few posts of this thread. In your case, a fast CPU misbehaves, plausibly because of inductance causing the Gnd and/or Vcc lines to bounce, resulting in a glitch. In the linked thread it's a bad connection that causes the ground bounce, but still it illustrates one of the various ways a glitch can manifest. Spoiler alert:
Understood. Congrats on your progress so far, and we look forward to a fresh appraisal of the situation!

-- Jeff

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

Another example of self-inflicted ground bounce is my experience with interfacing modern compact flash to retro computing. CF has 16 data lines with robust drivers so when they switch all 1's to all 0's, lots of ground currents are needed. The retro components are too slow to be affected, but CF's data buffer is a FIFO where ground bounce resulted in glitch on the read line that advanced FIFO pointer to next word. This is data-dependent corruption of CF read due to self-inflicted ground bounce. Low-pass filter on CF's read line helped, source termination of data helped, operating in 8-bit data mode helped, and lower CF supply voltage also helped. New people to Z80 retro scene still wrestling with this problem on a monthly basis, but I'm tired of explaining it.
Bill