exxos blog - random goings on

[dml]

Here is a version with 2 changes:

https://www.dropbox.com/s/znxpb5fdjm6vz ... 3.zip?dl=1

- limits spam to 64 prints per error pass, then it continues the test in silence
- at the end of a pass, if there were data errors, it will print a graphic error map down the right-hand side of the screen, with solid marks indicating the error locations in ram.

In this vertical error map, 1 pixel = 32kb region, any error in that region will be a solid mark in the map. this should give a rough idea of where the fault starts/ends or if it repeats through all of memory (excluding the begin/end which are offlimits for testing anyway). it can squeeze the first 12mb or so of ram on a 480-scan displaymode (use mono/vga for this test, ideally) which should be enough to get a general idea of whats going on.

[exxos]

Here is a version with 2 changes:

https://www.dropbox.com/s/znxpb5fdjm6vz ... 3.zip?dl=1

- limits spam to 64 prints per error pass, then it continues the test in silence
- at the end of a pass, if there were data errors, it will print a graphic error map down the right-hand side of the screen, with solid marks indicating the error locations in ram.

In this vertical error map, 1 pixel = 32kb region, any error in that region will be a solid mark in the map. this should give a rough idea of where the fault starts/ends or if it repeats through all of memory (excluding the begin/end which are offlimits for testing anyway). it can squeeze the first 12mb or so of ram on a 480-scan displaymode (use mono/vga for this test, ideally) which should be enough to get a general idea of whats going on.

Interesting...

IMG_0236.JPG

[exxos]

Now I ran it in the proper video mode :lol:

IMG_0237.JPG

I guess this sort of tallies with what TOS RAM test does on bootup.

IMG_0234.JPG

[dml]

Yeah, looks the same - if anything it just adds detail showing the problem is very densely spread through each blob (at least every 32k is damaged and from the prints, its narrowed further to every 8k). But both tests say the same thing about the location of the blobs.

If it helps I can get it to print the start address of each 32k blob, but it would be rounded off to 32k. The extra offset you'd need to derive from the individual error prints.

[stephen_usher]

It could be an internal addressing error in the chip, along with some other badness. If you could work out the size (in words) of the black bits you can probably work out which address line isn't working. Given that it looks like it's repeating exactly four times in the 16MB range it's probably the top but one bit in the address. which is fubared on the chip(s). That'll be 0x000100000, the 20th address line if it's 32 bits wide.

[dml]

It could be an internal addressing error in the chip, along with some other badness. If you could work out the size (in words) of the black bits you can probably work out which address line isn't working. Given that it looks like it's repeating exactly four times in the 16MB range it's probably the top but one bit in the address. which is fubared on the chip(s). That'll be 0x000100000, the 20th address line if it's 32 bits wide.

This could help explain why the Videl isn't showing obvious errors via the rampan tool - if the bit is being sourced from the wrong memory cell under some conditions but agrees with its neighbours - until the bit is modified locally by the scanning test where it disagrees. Maybe...

[exxos]

It could be an internal addressing error in the chip, along with some other badness. If you could work out the size (in words) of the black bits you can probably work out which address line isn't working. Given that it looks like it's repeating exactly four times in the 16MB range it's probably the top but one bit in the address. which is fubared on the chip(s). That'll be 0x000100000, the 20th address line if it's 32 bits wide.

Yeah That is what I am trying to figure out exactly which address ranges are failing and correlated to a address.

I just threw it out there that may be MAD8 was broken. I mean do the bad bits fail exactly when that address changes on that pin. Or does it fail slightly before then switches MAD8.. and continues to fail.

EG: Address example..

00010000 - Does it start failing at this point exatly
00111111 - Or does it fail at this point
01010000 - Does it fail at this point onwards

Not had chance to look at the error address range yet to work out where exactly the first bad block starts and ends...

[stephen_usher]

You could write your own program to test this. Does STOS allow you to access memory directly?

[exxos]

You could write your own program to test this. Does STOS allow you to access memory directly?

Yep. Though I cannot do much typing at the moment because of my RSI :( voice recognition does not work well for programming :lol: :roll:

[exxos]

Went through the previous ram test video to get the start and end bits of the bad block. Will digests shortly..

1.PNG

2.PNG

EDIT:

Code: Select all

300AC6
1100000000101011000110

3FEAC6
1111111110101011000110

Code: Select all

222111111111
1098765432109876543210
1100000000101011000110
1111111110101011000110

But I don't think that is so simple because the tests aren't simply going up by small numbers..

:dizzy:

For example these two addresses fail, but the addresses in between pass.

Code: Select all

300AC6
1100000000101011000110

302AC6
1100000010101011000110