1040 STF showing occasional rogue pixels

[Steve]

Before even reading this topic I thought bad ram, now it is confirmed for sure to be bad ram.

[sandord]

There's this one thing I want to try this evening: use freeze spray on the RAM chips. Since the problems only appear when the ST is warmed up, that should provide final evidence. Maybe I get lucky and find a bad soldering contact that way...

[tzok]

If it would be the MMU related problem, the stripes would be on a whole screen. As they are only on some region, it is more likely that the issue is with the RAM itself.

[rubber_jonnie]

This looks very similar, if not quite as bad, to a board I upgraded with known good RAM. After buzzing it out, there was a problem with some of the address lines, so that might be worth a try, though tbh my impression is a bad ram chip or two.

[sandord]

I've been running the YAART RAM test program for over half an hour. As you can see, many passes, no errors.

test1.jpg (70.91 KiB) Viewed 4532 times

But behold:

test2.jpg (65.53 KiB) Viewed 4532 times

There's one of the little bastards, right between "inversions," and "ones&zeros". I had to crank up the saturation of the pixel on the screenshot, in reality is quite clearly visible like it is already.

test2b.png (276.01 KiB) Viewed 4532 times

At the time of writing, 24 passes have passed successfully, no errors yet. Could it be that YAART 'forgets' to test the last bit of RAM, right where the stats are?

[sandord]

If that address is in the upper half of the 1MB area, you could disable the upper bank leaving 512K and try again...

I read somewhere I should remove R60 and R61 but apparently, that didn't work. So actually I don't really know what I'm doing
So how do I properly disable the upper bank?

[sandord]

I read somewhere I should remove R60 and R61 but apparently, that didn't work. So actually I don't really know what I'm doing
So how do I properly disable the upper bank?

Is it by removing R71,R72,R73, the opposite of the 512->1024 upgrade as shown here?

[exxos]

you lift the MMU end up of those resistors and then tie the free ends to 5V.

[rubber_jonnie]

If I recall, if you are leaving the RAM chips in, you'll need to de-solder the bottom end of those 3 resistors and connect them to +5v to disable that second bank of 512KB RAM, a bit like if you added a Marpet or similar RAM add on.

Double check this before you do it though in case I'm remembering it wrong.

[Smonson]

- Given the fact that the corruption is only visible in the part of the screen that doesn't get redrawn every frame and that the pixels don't change location, I think the RAM isn't faulty, it must be the transport to it that has a problem. The shifter simply displays what's in RAM and does so consistently, nothing random there.

I think that the fact that the corruption is only visible in part of the screen and not across the entirety of it actually implicates the ram more. As the screen is being moved 16 bits at a time between the RAM and the shifter, the only thing that changes as it gets to the "bad" bit of the screen is which location in RAM is being accessed. If the problem was somewhere in the transportation of the data, I would expect it to either be random (totally different for each frame) or covering the screen completely at all times.

In support of the "bad ram" hypothesis, you said that sometimes the problem goes away when the problematic part of the screen is redrawn. Possibly this is because the problem has a 50% chance of not affecting a pixel (if it's a single stuck bit in the word), so 8 palette colours would look fine, and 8 would look wrong. So when the colour of a bad pixel is written over, every second time it'll make the problem go away.