1040 STF showing occasional rogue pixels

[exxos]

If its dropped 50% after resoldering, you must have caused that new fault. Slow speeds like that is normally bad DTACK signals. You may need to check out that route from the CPU to MMU. Also add a extra 1K resistor from DTACK to 5V somewhere.

[sandord]

Apparently, RAM access has fallen down to 50% of regular ST performance. On the upside, the rogue pixels don't show up anymore. But, I see the occasional flash in the bottom 20% of the screen in Metrocross. It's rather subtile, more like a few lines dim during a single frame. The dimmed area in the picture below is not what I am talking about btw ;)


IMG_20180929_125222.jpg

It may not make a difference, but your reference machine is an STE with TOS 2.06 and Blitter enabled, it may be worth looking at the reference you're comparing against just to be doubly sure of your readings.

Thanks for the suggestion. I did another run using the STFM1024 reference, this time taking the effort of making a proper screen shot :D

Untitled.png

[sandord]

If its dropped 50% after resoldering, you must have caused that new fault. Slow speeds like that is normally bad DTACK signals. You may need to check out that route from the CPU to MMU. Also add a extra 1K resistor from DTACK to 5V somewhere.

That's a very interesting suggestion. I'll try that as soon as I have time.

[sandord]

I've seen that Exxos pointed you to a program that (specifically?) tests the screen memory -- without any status output. Did that program find any errors?

Well, there it is, finally (including proof, see red arrow):

IMG_20181001_112147.jpg

If I can get this machine to run at 100% memory speed again, it's probably time to make the decision to either replace/upgrade the RAM or put it on a shelf.

[sandord]

If its dropped 50% after resoldering, you must have caused that new fault. Slow speeds like that is normally bad DTACK signals. You may need to check out that route from the CPU to MMU. Also add a extra 1K resistor from DTACK to 5V somewhere.

I measured GND->DTACK at the MMU and at the 68K and both gave me a solid 999R. I guess I could put the resistor on the path somewhere between the MMU and the CPU but if both ends read 999K, will it make a difference?

I also measured DTACK at the 68K with my scope and got this reading. Does this look normal or do the different peak levels indicate there is a problem?

DS1Z_QuickPrint1.png

[exxos]

Looks OK to me.

[czietz]

Maybe just allow the screen to fill with whatever patten its testing, and just pause the text output during that time, and just display the text when not testing screen memory ? We don't need the text to display 100% of the time really.. and testing screem mem is only a few seconds...

Attached is what I came up with quickly: YAART beta version 0.2.5 that tests the screen memory as well. I'm not 100% happy with it though, because all the special handling of screen RAM measurably slows testing down. Yet, sandord might want to try if that finds any errors within the last bytes of RAM that were previously untested by YAART.

[exxos]

Attached is what I came up with quickly: YAART beta version 0.2.5 that tests the screen memory as well. I'm not 100% happy with it though, because all the special handling of screen RAM measurably slows testing down. Yet, sandord might want to try if that finds any errors within the last bytes of RAM that were previously untested by YAART.

Thanks. I think its as good as it can really be.. but yeah, the overhead with the new routine I can imagine would make it a tiny bit slower... But Still doesn't mean the old version isn't still useful anyway.

The only other way I guess would be to add a user input when it loads, where the user could input number of fails before the program stops and outputs the failures on screen (at that point the program would be paused). Then just forget the real time screen output text until the fail count is reached.. Similar turning the border to red is could be useful to show visually its failed.

I guess it really depends how much slower this new version is, if its not much, then I would just leave it how it is with your new version...

[sandord]

Attached is what I came up with quickly: YAART beta version 0.2.5 that tests the screen memory as well. I'm not 100% happy with it though, because all the special handling of screen RAM measurably slows testing down. Yet, sandord might want to try if that finds any errors within the last bytes of RAM that were previously untested by YAART.

Thanks a lot! Here's the trophy:

1.jpg

along with some nice speckles!

2.jpg

The error occurs 2300 bytes for the end of the RAM so that's exactly within the 2.5k area previously untested.

[czietz]

The error shown is in bit 13:
0xFFDF = 1111111111011111 was read, but...
0xDFDF = 1101111111011111 was expected.

If the error always is in bit 13 (the errors you previously posted were and also the speckle pattern looks reasonably repetitive to me), then you know which RAM chip to change.

PS: Even though I gave it some thought, I'm still puzzled by which effect the RAM access speed could be halved.