[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extended 80 column card issue

Linards Ticmanis wrote:

On 05/23/2011 10:39 PM, Michael J. Mahon wrote:



But any high address line could be bad and the text and hi-res
screens would never know about it...



Sure, but a bad buffer chip on the card wouldn't cause such a problem,
right? After all only data is buffered on the card, not addresses, if I
understand the schematic correctly.


That may be.  I'm a little surprised considering the relatively large
fanout to drive memory chips, but apparently buffering is needed only
for the 1MB boards.


Of course there might be a problem with the mainboard as well, but the
OP should be able to rule that out by using a different card in this
board, or this card in a different board.



Unfortunately, only a real memory test will provide any assurance
that the memory is functional.  All "use" tests like those above
are insensitive to a large fraction of problems.  (Though Murphy's
law pretty much guarantees that if you're actually trying to run an
important app, a flaky memory chip will stop it in its tracks.  ;-)



That is true if the problem is just one or a few bits, but breakage of
larger memory areas should usually be detectable with "use" tests,
shouldn't it? And if the card isn't even detected as being present by
some software, as reported by the OP... I'd assume that either some key
address (say, 0, $400, $1234, $ffff or one divisible by $1000) happens
to be the one that is bad, or it's a larger area; at least if I were
writing code to merely *detect* the card (rather than to *test* it), I'd
probably test such an address or a few of them, and not $73be or some
other "random" value. Since the chance that some one-bit error happens
to be in such a "nice" location isn't high, I'd assume that it's likely
that a whole block of addresses has failed, which "use" tests SHOULD detect.

Feel free to disagree, though. Maybe my thinking is not correct.


I don't know how his program detects AUX memory.  Most memory detection
schemes are as simple as possible--EORing a pattern with a byte, storing
it, and then reading it back, comparing, and restoring--nothing fancy.

The fact that PR#3 gets him an 80-column display says that the way
the monitor detects is is working fine.

In the case of a RAM disk, the vast majority of the memory is used
to store data, not file system metadata, so unless the contents of
files is compared to their originals, very little memory is actually
tested.  Data corruption in a large file can go unnoticed for quite
a while.

If large blocks of addresses are bad, and if the "use" uses those
regions and is sensitive to changes in the data, then use will find
the problem.  But there are huge numbers of memory failures that
will not be caught without stringent testing.

Memory tests are not hard to find (though some are much more
thorough than others), so finding one and running it is usually
the best way to verify that the memory is working.

If he has another working machine, I completely agree that swapping
cards to "move the problem" is the most efficient way to test.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."