Re: IIGS memory error

[dempson@actrix.gen.nz (David Empson)]

ground.ecn AppleII Librarian <apple2pd@garp3.icaen.uiowa.edu> wrote:

> When I run the Claris memory test (MemoryCL) from AWGS on a Rom3 with 1Meg
> Apple memory expansion board, I get a memory error at $180582 .

Is the same location reported each time you run the test?  I'll assume
that it is.

$180582 is $100000 + $80000 + $0582.

The motherboard has the first 1 MB ($100000), so the error is on the
memory expansion card.  The card has rows which hold 256 KB ($40000)
each, so the fault is in the "third row" on the card.

I don't know which physical order the rows on the card are arranged.
Given a fully populated card, it seems most likely that the soldered
chips are the first row and the rest are in order of installation, but
it is possible that the mapping changes depending on the jumper
settings.

The following procedure can be used to locate the faulty row.  (If
anyone else knows the physical order of the rows when the card is
operating with 1 MB installed, speak up!)

You could narrow the problem down by setting the jumpers for 256 KB and
512 KB, and seeing whether the problem appears in either case.  Assuming
no problems, this would rule out the soldered-in RAM and the RAM in
whichever row is supposed to be installed for 512 KB (refer to the
manual if in doubt).  I'll call this the "second row" for convenience.

Assuming the fault is in one of the remaining two rows, you can swap all
eight chips from the second row with the row which is probably the third
one, set the card for 512 KB operation, and see whether the problem
appears (I expect it would report the error at $140582).  If it doesn't
appear, then swap the second and fourth rows and try again.

If the fault doesn't appear at all with the card set for 512 KB
operation, then it is probably a physical fault on the card, and not a
problem with the RAM chip.  This doesn't seem very likely - the address
is part way into the RAM row, whereas a card fault would be more likely
to be detected at a row boundary.

> Which chip(s) is most likely at fault.  UA1-UA8 are soldered in.  UA9-UA16
> and UB1-UB16 are socketed.  UA1-UA16 are top row of memory chips, UB1-UB16
> are bottom row.  

Assuming you can locate the physical row which has the problem, the next
issue is to identify the chip within the row.  Each chip contributes one
bit to each memory location, so the fault could be in any of the eight
chips.

If you have plenty of spare 256Kx1 RAM chips available, it might be
easier to swap all eight.  To narrow it down to one chip, you need a
memory test program which can identify the faulty bit.

If the fault is consistently reported at a specific memory location, you
can use the system monitor to identify which bit is failing.

Starting in Applesoft BASIC, use CALL-151 to get into the monitor.

Determine the current contents of location $180582 by typing in the
following command:

18/0582

It should display something like this:

18/0582:00-.

The two digits after the colon are the current value of this memory
location.  Assuming you are going to turn the machine off after running
this test, you don't need to remember this value.

For subsequent references to the location, you don't need to specify the
bank (and the leading zero of the address within the bank is also not
required).  Try setting the location to a series of values, then reading
it back again to see whether the value is held or which bits are in
error.

To set the contents of the location, use a command of the form:

582:nn (where nn is the value you want to store in the memory location).

The display the contents of the location, just type in the address and
press return:

582

I suggest setting the memory location to each of the following values:

00 01 02 04 08 10 20 40 80.

I expect that the fault will cause one specific bit to always read back
as a zero or as a one.  If it is a "stuck zero" bit, then one of these
values will read back as zero.  If it is a "stuck one" bit, then all but
one of these values will have another bit set in the result.

For example, if bit 1 is stuck, then the readback values would be:

02 03 02 06 0A 12 22 42 82.

The bit might be reporting a random value each time it is read, in which
case you will probably get a mixture of correct and incorrect values,
with one particular bit changing state.

If more than one bit appears to be incorrect, then you probably have two
faulty chips (doesn't seem likely).

Assuming you can identify the faulty bit in this manner, you can map
from a hex value to a bit number as follows:

01 = bit 0
02 = bit 1
04 = bit 2
08 = bit 3
10 = bit 4
20 = bit 5
40 = bit 6
80 = bit 7

The bit number can be used to identify the specific chip within the row.
Again, I don't know which order the chips are arranged on this card, but
if you assume the chips are in order (either 0 to 7 or 7 to 0) then it
narrows down the problem to either of two chips, couting from the left
or right end of the row.

Try swapping one of these chips with the matching chip from the second
row, then repeat the memory test.  If you've moved the faulty chip, the
location of the fault will have changed to $100582, $140582 or $1C0582.
If the fault hasn't moved, then try swapping the other of the potential
chips with the matching chip from the second row and run the test again.

Fingers crossed, you've now pinpointed the faulty chip, and need to
replace it.

> What are stategies for finding/isolating bad chip?  Once I find the right
> group of 8 chips I think I can shift and rotate to find bad chip but I
> can't find the right place to start yet.

Moving around the eight chips within one row won't help - it would just
move the fault to a different bit within the byte.  You have to move the
faulty chip to a different row to prove that you have the right one.

-- 
David Empson
dempson@actrix.gen.nz