Strange memory write problems

[BigEd]

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.

[hoglet]

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

adrianhudson wrote:

It also seems that it is the write that didn't work since, when I find a mismatch, I output the address, what I expect to find at that address and what I actually find at the address. Since I am storing an increasing set of values to all memory e.g. all $00, and check, all $01 and check all $02 and check, I "usually" (I haven't double checked it is "always", but it might be) get the preceeding value, I get, say, $54 when I should get a $55. By the way, the program occaisionally crashes, I guess through the stack itself becoming corrupted.

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

[Dr Jefyll]

hoglet wrote:

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.

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

[adrianhudson]

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

BigDumbDinosaur wrote:

1 mA is feeble.
...
You should see about single-stepping the clock so you can measure bus voltages with a DVM. That should help in pinpointing the problem.

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?

BigEd wrote:

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.

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.

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

hoglet wrote:

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

adrianhudson wrote:

It also seems that it is the write that didn't work since, when I find a mismatch, I output the address, what I expect to find at that address and what I actually find at the address. Since I am storing an increasing set of values to all memory e.g. all $00, and check, all $01 and check all $02 and check, I "usually" (I haven't double checked it is "always", but it might be) get the preceeding value, I get, say, $54 when I should get a $55. By the way, the program occaisionally crashes, I guess through the stack itself becoming corrupted.

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.

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.

hoglet wrote:

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?

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

hoglet wrote:

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.

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.

Dr Jefyll wrote:

hoglet wrote:

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.

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

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".

[adrianhudson]

floobydust wrote:

Running a sequential block read test of a Compact Flash,...

A what?

plasmo wrote:

When an intermittent problem is "cured" by lower supply voltage, system noise is a likely candidate. This is because lower voltage slows down the devices and reduces rail-to-rail voltage swing thus reducing system noise. Contention can also be affected by supply voltage because the drive output weaken and caused less power spike.

The part list for this experiment are W65C02, KM62256, AT28C256, W65C51, 2x1.8432MHz can oscillators, 7430, 74ACT138, and 74AHC00.

I can test whether TTL/CMOS of RAM is a problem by replacing KM62256 with AS6C1008 which is quite similar to AS6C62256. I'll let you know.
Bill

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

plasmo wrote:

Replacing KM62256 with AS6C1008 (pull up A15 and A16 inputs) and verify it still passes memory diagnostic at 2.6V (it should, AS6C1008 is rated 2.7V-5.5V, same as AS6C62256); then raise voltage slowly while running memory diagnostic to 5.5V. Memory test passes from 2.6V to 5.5V. Attached is the memory diagnostic program which resides in AT28C256 EPROM.
Bill

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.

[BigDumbDinosaur]

adrianhudson wrote:

BigDumbDinosaur wrote:

1 mA is feeble.
...
You should see about single-stepping the clock so you can measure bus voltages with a DVM. That should help in pinpointing the problem.

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?

The idea of single-stepping the clock is to be able to hold bus conditions so you can take accurate measurements using a DVM. As the WDC 65C02 may be stopped with the clock held in either phase, this is a convenient method of testing something that is elusive during normal operation.

While a scope can illustrate what your buses are doing, you aren't likely to see subtleties that may be sufficient to interfere with stable operation. Being able to stop the MPU with the clock in the low or high phase gives you all the time you need to precisely measure the voltage on each bus line.

Quote:

BigEd wrote:

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...

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

Indeed, the use of 74HC logic should assure very light loading, as well as outputs that swing rail-to-rail. Obvious exceptions to the rail-to-rail output swing are the RAM and ROM, both of which output at TTL levels, not CMOS.

In the case of the MPU driving the RAM (write operation), the former’s high level output is very close to VCC, well above the TTL logic 1 threshold of ~2.0 volts, so things are good. However, during a read operation, it’s the RAM driving the MPU.

The RAM you have is guaranteed to output 2.4 volts with 1 mA current draw, however, Bill Mensch stated in a conversation I had with him that the 65C02’s logic transition point is approximately VCC × 0.5. Empirical testing by Jeff demonstrated that the transition point appears to be slightly higher than that, 2.6 volts for the 65C02.

So it gets back to whether that 1 mA output of your SRAM is able to push the data bus high enough to make the 65C02 see a valid logic 1.

MPU Clock Single-Stepper

[BillO]

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.

[adrianhudson]

BigDumbDinosaur wrote:

The RAM you have is guaranteed to output 2.4 volts with 1 mA current draw, however, Bill Mensch stated in a conversation I had with him that the 65C02’s logic transition point is approximately VCC × 0.5. Empirical testing by Jeff demonstrated that the transition point appears to be slightly higher than that, 2.6 volts for the 65C02.

So it gets back to whether that 1 mA output of your SRAM is able to push the data bus high enough to make the 65C02 see a valid logic 1.

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

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

BillO wrote:

On the subject of RAM chips
...
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.

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)

at phi2 in pin to can with probe spring gnd.png (5.36 KiB) Viewed 1584 times

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

A0 at CPU.png (5.17 KiB) Viewed 1584 times

Here is +5V at the oscillator pin

5V at osc can.png (4.92 KiB) Viewed 1584 times

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

D0 at RAM pull disconnected.png (5.45 KiB) Viewed 1584 times

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

D1 at RAM pullup.png (5.96 KiB) Viewed 1584 times

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!

[BillO]

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.

[plasmo]

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

[Dr Jefyll]

plasmo wrote:

With pull up resistors on data lines you'll see slow rising waveform because of the pull-up resistor overcoming the data bus capacitance.

... 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.

BigDumbDinosaur wrote:

Bill Mensch stated in a conversation I had with him that the 65C02’s logic transition point is approximately VCC × 0.5. Empirical testing by Jeff demonstrated that the transition point appears to be slightly higher than that, 2.6 volts for the 65C02.

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,

Quote:

It looks as though I will be taking Jeff out drinking the next time I'm in Stratford or the next time he comes to the Chicago area.

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

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

Quote:

It looks as though I will be taking Jeff out drinking the next time I'm in Stratford or the next time he comes to the Chicago area.

-- Jeff

The offer remains, although you may have to come here to take me up on it. After this latest go-around with my heart (two more procedures in the space of seven weeks), the doctor recommended that I not travel outside of the USA.

[Dr Jefyll]

'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

[Dr Jefyll]

adrianhudson wrote:

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".

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!

adrianhudson wrote:

Regarding the clock. The oscillator can is right next to the 'C02 phi2 input 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?

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:

I wrote:

An oscillator has been created. [...] Moral of the story: don't fixate entirely on input and output pins. Their meaning hinges on what VSS and VDD are doing

adrianhudson wrote:

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.

Understood. Congrats on your progress so far, and we look forward to a fresh appraisal of the situation!

-- Jeff

[plasmo]

Dr Jefyll wrote:

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.

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