Page 2 of 11

Re: 1040 STF showing occasional rogue pixels

Posted: 27 Sep 2018 04:33
by Steve
Before even reading this topic I thought bad ram, now it is confirmed for sure to be bad ram.

Re: 1040 STF showing occasional rogue pixels

Posted: 27 Sep 2018 08:17
by 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...

Re: 1040 STF showing occasional rogue pixels

Posted: 27 Sep 2018 19:33
by 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.

Re: 1040 STF showing occasional rogue pixels

Posted: 27 Sep 2018 20:01
by 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.

Re: 1040 STF showing occasional rogue pixels

Posted: 27 Sep 2018 23:19
by 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

But behold:

test2.jpg

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

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?

Re: 1040 STF showing occasional rogue pixels

Posted: 27 Sep 2018 23:43
by sandord
exxos wrote: 26 Sep 2018 23:18 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?

Re: 1040 STF showing occasional rogue pixels

Posted: 27 Sep 2018 23:52
by sandord
sandord wrote: 27 Sep 2018 23:43 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?

Re: 1040 STF showing occasional rogue pixels

Posted: 28 Sep 2018 08:20
by exxos
you lift the MMU end up of those resistors and then tie the free ends to 5V.

Re: 1040 STF showing occasional rogue pixels

Posted: 28 Sep 2018 08:22
by 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.

Re: 1040 STF showing occasional rogue pixels

Posted: 28 Sep 2018 10:39
by Smonson
sandord wrote: 26 Sep 2018 22:40 - 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.