The method I used to distinguish problem due to under-performing part from system noises is voltage and temperature. Low voltage reduces system noise whereas high voltage increase system noise. Low voltage adds more prop delay but high voltage reduces prop delay. So if your system fails more frequently at high voltage, it is likely a system noise problem, but if it fail at low voltage, it is likely due to under-performing parts. With small heat gun or cold spray, you can heat/cool individual component. CMOS speeds up when cold and TTL speeds up when hot, so CMOS is more noisy when cold and TTL more noisy when hot. This way you can pinpoint the component that's causing the problem.

Since your RAM is so much faster than necessary, you can add a small capacitor to nWE pin to filter out fast glitch. 50pF between nWE pin and ground or VCC should provide decent filtering.

System noise tends to be data pattern sensitive so look at the error report for all '1' or all '0' patterns.
Bill

Edit: My trick when troubleshooting intermittent problems is holding a metal needle with my bare hand and probe every connection while running diagnostic. This does two things: physical probing shows mechanical intermittent problem and the added body capacitance shows the critical timing path.

I tried to take some measurements of ground shift or voltage drops


I then took measurements in a constant read loop (033C JMP $033C) in the SRAM. What I found interesting is that the databus switching does not seem to have a noticeable effect (at least to the naked eye) on the power lines:

The lower three lines are, from the bottom up, GND, VCC-GND (scope math function) and VCC.

Here is the same with measurements by the scope


And here are the same two measurements where I had removed the fix from the schematics, as you can see in the databus signal change shortly after Phi2 goes high:



Note that probes points are not ideal, but the best I could do right now. Luckily I already had soldered an additional bypass cap to the bottom of the board (long time ago), so I could clip the probes in there. The ground is from the flat ribbon cable, so not good. I'd thus rather trust the math signal with the diff between VCC and GND.

Yet, I can't really see a big difference. Maybe it's just so marginal yet still effective...? Or it really is only a write problem (as I have used a read loop here)...? Not sure what to make of it.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I have been trying to improve the power supply situation a bit, by adding additional power and ground lines.
As a side note: the board design is 15 years old, so bear with me. It does not have extra wide power supply lines, not even speaking of ground planes or such.

So I went from
to

I observed two things: the power supply (CHANNEL 4) ripple seems to have been considerably reduced, if the scope measurements are to be believed. They used to be around 1.44 Vpp, now it's about 1 Vpp.
Secondly, the errors have not gone away. They even seem to be more often, for example breaking out of the JMP * read loop in about a minute or so.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

In fact it seems something has gone wrong... now even the Alliance chip does not work without the fix (not qualifying /CS with Phi2).

What happens is that rather quickly the CPU just seems to hang (or does something that is not observable), with both the BSI and the Alliance chips now.

Only when the fix is applied the SRAM seems stable....

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Somewhere above it has been suggested that the /CS, /OE or esp. /WE lines could be a problem. So I have been looking at those today.

First of all, during all the previous tests this has been an ALS type IC producing the signals. You can see this at the max level of about 4V reached:


Edit: the light pink one is the /WE signal. The dark pink one below is a math function substracting the chip's GND from the /WE signal.

Then I replaced the IC with an HCT one.


The signal now reaches to close to 5V.
Unfortunately this did not result in any change, at least from the stability point of view.

Also, looking at the quality of the signal this looks really good. So for now I think I can rule out this one.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

After all these tests on the BIOD board (the one with the SRAM), I decided to look at the CPU board, if I can have a look at the databus driver.

So, I moved the CPU board to another slot on the backplane, and, lo and behold, the system suddenly seems to be "read-stable", only writes seem to go wrong at some time - see the cycle number here to see that it ran for over 2h, but accumulating errors all over the RAM.

(again the $0200-$8000 SRAM is the main RAM, the others seem to be induced errors as they actually test the video RAM)

So, I was looking at the power supply of the 74LS245 that was actually the databus buffer between CPU and backplane. First I replaced it with an HCT, but still no better stabilty.
Then I scoped the power supply lines and this is what I found:


The yellow line is Phi2 (from the backplane), light blue is the 5V line (compared to GND on the backplane), dark blue is the chip's GND line (compared to GND on the backplane), and the dark violet (MATH) one is the difference between the two
What I take from this is that the databus driver has a very "wobbly" power supply directly after phi2 going high - basically when the BSI chip does its databus switch.

Here is the signal from the Alliance chip for comparison


I am not sure what I should make of this. Obviously the slot on the backplane has something to do with the problem as well.

The backplane is a 64pin a+b/c rows DN41612 passive backplane. The outer pins of each row (a1 + c1, as well as a32 + c32) are connected across all slots with a large ground plane. When I designed the bus I made the mistake, NOT to take one of those as supply lines, but used both as GND, and only used two consecutive signals as VCC supply lines. In the meantime I have added a separate "booster" cable across the VCC pins of all the slots as you can see here.

Frankly, I am running out of ideas...

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I have been probing around at this problem, and maybe I have a trace...

First of all, I find it interesting how much of an "antenna" a scope probe is. I measured GND right at the point where the probe ground clip was connected, and still got a weird wiggle on the signal...


and the result:

(edit: the blue one is the actual "GND" signal)

So that makes me wonder how good my signals really are....

But anyway, with keeping that in mind, I changed my test program to run on the SRAM chip that it was testing itself, or on the dRAM also in the computer (on the video board).
Interestingly, when the program was not running on the SRAM and only checking it, it ran over 700 iterations accumulating only one test with error.
If the test program was running in the SRAM itself, it quickly accumulated more errors:

(edit: note that I added more memory tests called "HIMEM", as the original test was only testing the lowest 32k of the 512k SRAM)

I even resoldered every connection on that socket of the SRAM chip. I was getting suspicious, as the system seemed to be very sensitive to a scope probe attaching to an address bus signal. Sometimes the system would very easily crash when I did this.
So, I measured this and found a lot of wiggle on the actual address bus signal


(edit: the violet one is an address line. yellow is phi2, blue is the /CS signal)

Considering that TTL has a Vmax for a low input of about 0.8V (right?), this definitely wiggles out of that area.

And, the best thing is - here is the very first real difference I found between the working and the non-working chip:


The working chip has very much less wiggle on the address line!

And this is the only thing I changed. Address drivers on the bus are HCT type now.

So, I am not sure I am ready to confirm that this is the issue, but it seems it could be - even though timing would suggest that the address lines seem to settle again early enough. But maybe not early enough then.

Tomorrow or so I have to check with the actual fix applied, how the address lines look.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Ok, I couldn't wait.. Here's the address line of the BSI chip, with the fix applied (i.e. /CS _not_ qualified with Phi2):


So, the noise seems to have gone considerably down, to the level of the working Alliance chip.

My assumption now would be, that because the BSI chip just powered up, and the address lines were internally not settled as we can see from the read cycle (data lines switch some way after Phi2 going high), when the address lines in the chip settles, this feeds back enough noise onto the address inputs, as to disturb the signal. Does that make sense?

If so, I'd call that a fix. (Ok, wish me luck, still have to run the two hour burnin test, but 10mins in without error so far...)

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/