!pr0
!lm12
!rm75
Finding Trouble in a Big RAM Card..........Bob Sander-Cederlof

Last night (Monday, Nov 28th) I took home an Apple to do some spreadsheet work.  I took home the most portable one, but first swapped RAM cards.  I took the STB-128 out of my oldest Apple and put it into the Apple II Plus with the fewest attachments.

When I plugged it in at home and booted the spreadsheet program, all appeared to be well.  But it wasn't.  I loaded in a model, and during the re-calculation the spreadsheet program hit a BRK opcode and died.  I pressed RESET and looked at the partially re-calculated sheet:  it was sprinkled with nonsense characters, and the keyboard was locked up.  I played with various combinations for an hour or so, including other programs which use the RAM card.  Everything pointed to there being a bad bit somewhere in the card.

Of course the RAM card test program was back at the office.  I decided to write another one rather than face the two mile round trip.

The 128K space on the STB-128 is divided into 8 banks.  You select a bank by storing a bank number (0-7) at any address in the $C080+slot*16 space which has bit 2 = 1.  For slot 0, that means store in $C080, $C081, $C082, $C083, $C088, $C089, $C08A, or $C08B.  The card has three green LEDs on top which show which bank is currently selected.

Each 16K bank is further divided to fit into the 12K address space between $D000 and $FFFF.  The softswitch controlled by bit 3 in the $C08x address selects which of two 4K banks will be enabled at $D000-DFFF.  The other 8K always sits at $E000-FFFF.  A red LED signals which $D000 bank is selected.

The low-order two bits of the $C08x address control the mode of the RAM card.  Accessing $C080 or $C088 write protects the card, and read enables it.  This means the $D000-FFFF references the RAM card rather than the motherboard ROM.  Accessing $C082 or $C08A write protects the RAM card and disables reading it; in other words, it switches on the motherboard ROM.

$C081 or $C089 also turn on the mother board ROM for reading, but if you access one of these twice in a row it will write enable the RAM card.  In this mode reads reference the motherboard ROM, but writes write into the RAM card.  This mode is used when loading the RAM card so that monitor and Applesoft routines which are in motherboard ROM can be used for the loading process.

Accessing $C083 or $C08B once read enables the STB-128 card and write protects it.  A second access write enables the card.  This is the mode we use for a memory test.

Thinking about how to test such a card, I wrote down the following "flow chart":
!np
       For Bank = 0 to 7
           Store Bank in $C083
           Access $C083 again to write enable
               Test $D000-DFFF
           Access $C08B twice
               Test $D000-FFFF
       Next Bank

I broke the actual testing of a range of memory into four parts.  First I stored zeroes into every location, and checked to be sure I read zeroes back.  Then I did the same with $FF.  Then, $55.  Then, $AA.  This is certainly not an exhaustive test, but I hoped it would be sufficient.

The tricky part was informing myself of the locations and values involved of any memory errors found during the test.  I could not conveniently use the monitor subroutines to write addresses and values on the screen, because the monitor only existed in the motherboard ROM and it was switched off!  So, I wrote a quick and dirty display routine.

The routine for display in the listing below is not quite so "quick and dirty".  The program starts by clearing the screen using the monitor HOME subroutine at $FC58.  Then it switches to the RAM card and runs the test.  The program pokes test failure data directly to the screen.  I direct the data for each of the 8 banks to a different line.  When a failure occurs, I print the address, the value that should have been there, the actual value found, and the exclusive-or of the two values.  The exclusive-or shows me which bit or bits was incorrect.

After running the test it was obvious that the least significant bit in banks 5 and 6 was not working.  When it should be zero it was sometimes one, and vice versa.

I did not know which chip on the STB-128 card belonged to which bit slice or which bank, so I guessed.  I was lucky, and guessed right the first time.  I pulled out the chip I thought might be the bad one, and re-ran the test.  This time the test indicated the least significant bit of banks 4-7 was missing.  (It happened to be the chip in the lower-left corner when looking at the face of the card.)

I put the chip back in, hoping that it would miraculously heal itself.  Then I looked at the back of the board to see if anything looked suspicious there.  Sure enough!  STB did not trim off the excess length of the socket pins after soldering the board.  One of those long pins had bent over and was possibly shorted to another, on the lower left socket.  I straightened the pin and re-ran the test.  Voila!  It passed!

After I finished patting myself on the back I tried to run the spreadsheet again.  It still failed!  This morning I put the cards back in their usual homes, and everything works fine.

Tuesday Afternoon....Lo and behold, the card is still bad.  I found the STB Systems diskette, and ran their RAM test program.  It identified the same chip as being bad.  But after running the test for several hours, the errors stopped.  Obviously the chip's problems are intermittent.

Wednesday Morning....The chip is still giving errors.  I called STB and they said to bring the board by.  Wednesday afternoon....STB replaced the chip, and all is well.
