SE30 Screen artifacts problem

[croissantking]

The UE7 that is now on the logic board, has the number 341-0755-A Unfortunately, the UE6 has worn out lettering

Your UE6 should be 341-0754-A. 0754 and 0755 work together as a pair.

On older SE/30 boards, those chips were labelled 341-0637-A and 341-0688-A. Do you have these versions from another donor board?

 

[croissantking]

Sorry if I overwhelmed you there! I got excited to see someone else with the same issues as mine after tearing my hair out over them all year. Gives me hope that we can finally fix this problem.

Let us know what other findings you get Your observation about UH7 affecting the severity of the problem is interesting.

 

[bromaster]

Sorry if I overwhelmed you there! I got excited to see someone else with the same issues as mine after tearing my hair out over them all year. Gives me hope that we can finally fix this problem.

Let us know what other findings you get Your observation about UH7 affecting the severity of the problem is interesting.

To me, this convergence is not surprising. The problem after a longer analysis is clearly not with the graphics, but with the RAM and the circuits working with it. This IC is a part of that circuit, that's why you can see the changes.

 

[bigmessowires]

This is an interesting puzzle! If the problem is happening on multiple Reloaded boards owned by multiple people, including ones with all original components, then it suggests there's something different about the Reloaded board as compared to the original SE/30 board. I believe the Reloaded board is not a direct copy of the SE/30 board - it has the same logical connections but the traces are routed differently? You may have a situation where there's more parasitic capacitance or coupling between adjacent traces than the original board, and problems appear or disappear with tiny changes in the supply voltage, temperature, or by replacing a chip with an identical chip whose properties are slightly different due to normal process variations.

That would be a very difficult problem to solve, and you'd probably need to watch analog-level signals with a scope to diagnose it. If you can ID exactly what's going wrong, perhaps you could add or remove extra capacitance from a problem trace to compensate, or cut a trace and replace it with a patch wire.

It sounds like you already know that wrong values are being written to RAM. Next would be trying to determine whether it's a spurious write to RAM when no RAM was meant to be written, or if it's a valid write but it's written to the wrong address, or if it's a valid write and written to the correct address, but the data value was stored incorrectly.

 

[croissantking]

This is an interesting puzzle! If the problem is happening on multiple Reloaded boards owned by multiple people, including ones with all original components, then it suggests there's something different about the Reloaded board as compared to the original SE/30 board. I believe the Reloaded board is not a direct copy of the SE/30 board - it has the same logical connections but the traces are routed differently? You may have a situation where there's more parasitic capacitance or coupling between adjacent traces than the original board, and problems appear or disappear with tiny changes in the supply voltage, temperature, or by replacing a chip with an identical chip whose properties are slightly different due to normal process variations.

This is kind of what I’d been feeling - that there’s something about the Reloaded design that under certain circumstances produces this interference. I spent a long time thinking it was something I’d done wrong but here we have another user with the same exact issue.

That would be a very difficult problem to solve, and you'd probably need to watch analog-level signals with a scope to diagnose it. If you can ID exactly what's going wrong, perhaps you could add or remove extra capacitance from a problem trace to compensate, or cut a trace and replace it with a patch wire.

I agree. It will take a lot of work to find the actual source of the fault.

It sounds like you already know that wrong values are being written to RAM. Next would be trying to determine whether it's a spurious write to RAM when no RAM was meant to be written, or if it's a valid write but it's written to the wrong address, or if it's a valid write and written to the correct address, but the data value was stored incorrectly.

My own troubleshooting doesn’t lead me towards a RAM issue, but rather a GLUE/PAL one so it’s interesting that @bromaster has different findings.

 

[croissantking]

Did you get any further with your troubleshooting analysis?