Atari 800 RAM test

[1050]

Now we are on the same page thank goodness. Yes, I agree completely, it does make sense that SALT would be looking for 8K blocks and it would be arranged to report on those too. From what little I have seen of the disassembly so far, it appears that one possibly 'sets' it to the number of 8K blocks so as to help it in this process perhaps? We could have the situation where 16K blocks were not written for too, can't know this until I run it to learn the operation of it and then have the disassembly whimpering in the corner like a properly owned beast - just kidding. Only in the early stages of looking around though, I very much can be all wet here. Just as you outlined it, SALT remains a viable tool even with modules larger than 8K. So it's not a perfect tool as we have to 'interpret' the impossible results reported (back half can't be good while the front half is bad - it should be reporting (2) 8K blocks as bad -- THIS is what I'm complaining about the most), it remains a viable one. I think that's the point where Atari said 'start the press - print it'. A better chip finding tool then was never made.

 

So a dirty contact with module select pads might be where the back half does test good and the front half shows bad... It's a select issue and not bad data in the ram nor bad ram at all. Can't complain too loudly then because without this 'impossible and erroneous' report, I wouldn't know to look for a problem precisely there in extra fine detail or then be able to correct it. Sockets and module select board edge pads need some looking at is what I 'interpret' from SALT results today. This could be a damaged trace on the module board, scratched the day it was born, and only now corroded to the point of creating data errors. Reviewing your link just now, I predict issues with module edge pin 18 or it's trace to Z501 and Z501 itself is suspect too. Just about to post and I hesitate to reconsider Claus's advise of reversed order, so in that event it's now module edge pin U or it's trace to Z501 with Z501 also suspect. I now believe that's the fix - JoSch, you don't need to wait for replacement ram that's not bad in the first place, it's the sixth contact pad from the right on the non-chip side, flipped upside down to work on it, it's the 6th pad from the left, get out your magnifying glass and follow that trace to the Z501 chip right there too. Re-seat this chip if nothing else found or repaired and retest.

 

Interesting note about the upper half business first - so now I WILL have to take another look at the thread linked to in order to re-learn just how that business comes about. And having done that now, I can report that it took longer than it should have, but yes I can see that now. So much depends on what is in slot one which is a 16K module too. I'll run that BASIC program and get a screenshot just to look at. Thanks for all your contributions Claus, this kind of stuff is priceless.

[JoSch]

Now we are on the same page thank goodness. Yes, I agree completely, it does make sense that SALT would be looking for 8K blocks and it would be arranged to report on those too. From what little I have seen of the disassembly so far, it appears that one possibly 'sets' it to the number of 8K blocks so as to help it in this process perhaps? We could have the situation where 16K blocks were not written for too, can't know this until I run it to learn the operation of it and then have the disassembly whimpering in the corner like a properly owned beast - just kidding. Only in the early stages of looking around though, I very much can be all wet here. Just as you outlined it, SALT remains a viable tool even with modules larger than 8K. So it's not a perfect tool as we have to 'interpret' the impossible results reported (back half can't be good while the front half is bad - it should be reporting (2) 8K blocks as bad -- THIS is what I'm complaining about the most), it remains a viable one. I think that's the point where Atari said 'start the press - print it'. A better chip finding tool then was never made.

Why should it report 2 bad 8K blocks, when just one bit on one chips is bad?

[ClausB]

JoSch (Johann vielleicht?), please post a photo of the SALT error display, so that we might better see the problem.

[JoSch]

JoSch (Johann vielleicht?), please post a photo of the SALT error display, so that we might better see the problem.

 

It's Jochen

It showed B2, D2 and A6, IIRC. At the moment the fuses of my two 1050 PSUs are blown. So I have to wait for their substitutes.

The service manual, if I understand it correctly, says that is a RAM error in the third 8K block and nothing else.

[ClausB]

I was not familiar with the SALT II RAM test so I looked at the Service Manual. The manual does not mention rows A and C of the matrix, but it does say row D identifies which RAM chip is bad. So it is a chip level diagnostic after all.

[1050]

Why should it report 2 bad 8K blocks, when just one bit on one chips is bad?

Because it's not like that situation at all, just one bit bad due to a bad ram chip shows itself 16,384 times across the entire address range that the memory module covers. And that's 16K, NOT 8K as reported. Because of this wide band data destruction, one half of the module can't be good either. `UNLESS it's not a bad ram chip at all - it's a fault within the circuits that turn on the ram at 8K boundaries and that's the job of the module select logic - Z501. But note that half is good and Z501 also decodes the select logic for that good half as well as the bad half and here we are again looking at a chip that only half of it works. No, they just don't do that as any normal failure mode. It strongly points precisely to a bad connection to the half of Z501 that does the upper half selection of the module and that is the trace from edge pin U.

Just wish I could help you to understand how it works better.

 

I'll have a look at the service manuals too, thanks for the results.

[JoSch]

Because it's not like that situation at all, just one bit bad due to a bad ram chip shows itself 16,384 times across the entire address range that the memory module covers. And that's 16K, NOT 8K as reported. Because of this wide band data destruction, one half of the module can't be good either. `UNLESS it's not a bad ram chip at all - it's a fault within the circuits that turn on the ram at 8K boundaries and that's the job of the module select logic - Z501. But note that half is good and Z501 also decodes the select logic for that good half as well as the bad half and here we are again looking at a chip that only half of it works. No, they just don't do that as any normal failure mode. It strongly points precisely to a bad connection to the half of Z501 that does the upper half selection of the module and that is the trace from edge pin U.

Just wish I could help you to understand how it works better.

 

I'll have a look at the service manuals too, thanks for the results.

Sorry, I am not able to follow how you come to your conclusions.

If one of 16,384 RAM cells is bad (i.e. doesn't hold the stored value reliably), how can that one bit error be repeating 16,384 times. Do you mean, that if one cell goes bad, at the same time all cells go bad, too?

I'm trully curious. I just don't understand, what you want to say.

[1050]

No, one cell going bad doesn't ruin the other 16,383 cells at all. I'm a bad teacher if that was what you got from my typing. I can see where you are getting mislead only after I've seen your response and then look to my words before where I'm speaking to some other context while thinking you are following that context and there is the disconnect. Frustrating here too, my apologies for misleading you like this. I'm quite sure you can understand it once we get on the same page. You might try quoting the sentence that is causing your troubles and then propose your interpretation and questions? That way I could express the context about that sentence and perhaps avert another misunderstanding down the road?

 

Because it's not like that situation at all, just one bit bad due to a bad ram chip shows itself 16,384 times across the entire address range that the memory module covers.

A bad ram chip here means a dead one, if I had meant cell instead of 'just one bit' I would have made efforts in that direction. A dead ram chip will never store data again, the output from it is unknowable while also being immaterial to a tester - it will fail.

 

Cells normally don't go bad in the first place, and this is not the typical failure mode. You might be expecting to see a few sour cells with a memory test but instead you'll find mostly dead chips. By design too - as we just can't have corrupted data, think of it as the prime directive. Above all else it's better to have a dead ram chip that's easily found and replaced than one that is going around polluting the world with bad or random data. The cell part of memory chips is so well over-engineered that corrupt data is in essence not happening inside the ram chip itself. Every other part of the chip can die, buffers, refresh, addressing, but the cells - no. This is not the typical failure mode.

 

Almost odd then that we can only look for sour cells when testing memory - it's the only method we have so not much choice there. Amazingly enough we can find them too, double ha at this part. Thinking on it some, I don't recall ever running across a working ram chip that tossed out bad data. All the bad ram chips I have found were either dead as if nobody was home and they did nothing at all or they were a dead short on the power supply and one might almost lite up a cigarette off it - I'm exaggerating here. The shorted ones just to be thorough here also did not/could not pass a memory test.

 

So think this over and ask more questions. In the meantime though - I would very much like it if you were to run the SALT test again and this time please write down exactly the results and post them again? Along with your memory slots as populated, here I just need confirmation that you are using only two 16K modules for example.

 

I have 'impossible and erroneous' data of a reported B2 result and the Atari_400_800_Field_Service_Manual_June_82.pdf, page 3-14, table 3-2 shows that in order to have a bad 3rd 8K block as reported earlier, that should have been a B6 result or a B4 and a B6 result. B2 isn't valid, from what I can understand, only B4 thru B7 are the block indication results. No info on row A or C? Huh? is all I know to say until disassembly gives me a better clue.

 

And like Claus reports, I also see where they show that individual ram chips are indeed isolated, your results of D2 reported point to Z510 as the bad ram chip. I find this part amazing, how come nobody came here before and stole this code? Better yet is - how come nobody says SALT can find your bad ram chips?

 

A few caveats seem to be in play here though. One being pattern stability, if it's not stable this points to 158 chips. Only when it's stable then is B4-B7 valid it would appear to be stated. Overall there is far, far more talent here than I was expecting to ever see - I still need to disassemble it to have full faith in it. But it sure looks like a keeper here right now. Some of the instructions seem to need a second read though and at 5 times through, it still is a bit vague with a foggy kind of feel to it. As the weatherman says, partly cloudy on some of this stuff.

[JoSch]

Ok, now I understand. You meant the total chip for one of the bits is bad. If the whole IC is bad, then of course you have to see about the whole 16K.

BUT, my point is, that it HAS NOT necessarily that fault. I would even think that this event is the most unlikely one.

I would presume, that's more likely that single cells go bad, before the whole chip dies. And I think, that's what happening.

 

I have make one correction here, though. After looking on my notes again, the results were: B6, D6 and A2, which leads to the third 8K block, IIRC.

[1050]

Good to hear that and yes of course we don't know the exact nature of the fault until we have a fix and a bad chip to examine in further detail with more testing perhaps. We can hope to know then and there may be room for debate as well. In order for my call to examine pad U and it's trace to the select chip to be a part of the fix, all the memory chips HAVE to be good, so I also am thinking we do NOT have a dead chip here. It is very much alive and working fine.

 

I would presume, that's more likely that single cells go bad, before the whole chip dies. And I think, that's what happening.

Well now that we finally have a memory test that can find individual memory chips as bad perhaps I'll see more of the type that are weak and old and tired with soggy data? I don't really think so, I'm just kidding you a little bit, but I'll allow you to believe what you want there. The odds of soggy data being found are very much higher with this tool just the same, and that is not a joke.

 

Notes are wonderful aren't they? So we have a change in the bad chip isolated by SALT, it shows Z506 for the D6 value from the matrix. As a side note I've noticed an engineer's touch in the matrix table already, D2 called for the chip that holds the data on the system's Data Line 2, now D6 is pointing to the chip that holds the data for the system's Data Line 6 - these are NOT coincidence, someone's hand is at work here and he is an engineer.

 

Since I haven't heard your thoughts on the issue of SALT predicting which ram chip has the fault, please re-read at the bottom of page 3-14 and notice that you have nothing for the E row in your notes. This means that the D6 entry is a valid marker to the bad ram chip according to SALT. If you had D6 AND E6 then the 6 column would be the same there and table 3-3 does not apply to that test. Since column 6 IS different for D and E rows, D6 marker is valid in table 3-3.

 

I'm still not sold on the half business of the bad 16K module, what I don't know is if it's incomplete reporting by SALT or if the earlier call to check the pad and trace of pin U is also valid. I'll just have to wait to find out, both for a fix by you and disassembly of SALT to see what A row is about here since you have an A2 entry as well. And many other things that I'm curious about under the hood there.

[JoSch]

Well, yes. Once I reread the section, your right that table 3-3 also applies and that it narrows the problem down to Z506.

At the moment, I can't really test the 800, because I have blown the fuses of both 1050 PSU. I'll have to wait for new fuses.

[JoSch]

So here is the culprit (Z505):

The RAM test now runs through.

Edited May 10, 2016 by JoSch

[1050]

Very interesting that it turns out to be Z505 instead of the pointed to Z506, but very happy to hear you have a fix. To make me happy I need to find such a chip here so I can move it around and put SALT thru it's paces. Nicely done and I learned a lot, thank you for coming back with the solution.

[JoSch]

If you look at this new scan (https://dl.dropboxusercontent.com/u/56947388/Cambouis/Atari%20400-800%20System%20Service%20Manual.pdf), then you will see that D6 indeed means Z505.

The copy I had was probably copied a lot before scanning it, so either I misread the error message or it's refering to an older version of SALT, with different codes.

[1050]

Thanks again, but I actually saw a blatant mistake in their own text. They show D7 as results example, but still call for your Z505 in the text and this version doesn't have 8K VS 16K module results table either. So how can one not come away confused?

 

BUT D6 does mean Z505 there and for 8K modules in the other PDF too. I'll trust actual results far more than wrong examples every time. I also won't toss out these instructions either just because of one mistake.

 

I don't think it's a different SALT with different tables, I think it's just lousy proofreading and errors creeping into the instructions. The proofreaders are not cut from the cloth as the engineers, they know how to spell real good but they wouldn't even recognize a mistake made in a table.

[mike.2000]

recently I discovered a bad connection (done by me) on my 128 KB RAM upgrade for Atari 800 XL.
The bad thing about is the built-in Atari Diagnostic Program only checks the 64KB or even less ?

So I sat down and wrote a diagnose program for those RAM extensions. If you have trouble with your machine and want to examine the 64KB RAM chips on top of the original RAM, here's the link for you to click.

Happy preservation of this greatest 8Bit HW, Mike