One of the most frequent failures I find in Apple II systems is that of a bad memory chip(s). In my years of doing this work I have not yet come across a good way to test memory. Sometimes it's easy to spot one with an oscilloscope, sometimes I can use the chip stacking method, and sometimes, if I can get to this point, I can use a memory test program I wrote. However, all of these methods have their weaknesses. So I am asking if anyone has a good way to troubleshoot bad RAM chips without removing them from the board (as most are soldered in). The only solution I can think of is a logic analyzer. Is this a good solution? Is there another option that maybe I am not considering?
- VCF SoCal - February 15 - 16 2025, Hotel Fera, Aneheim CA
- VCF East - April 2025, Infoage Museum, Wall NJ
- VCF Southeast - July 2025, Atlanta, GA
- VCF West - Aug 2025, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 2025, Schaumburg, IL
-
Please review our updated Terms and Rules here
Best way to test memory?
- Thread starter oldpcguy
- Start date
Gary C
Veteran Member
Pull them and put them in a tester
Sorry, just noticed you mentioned they are soldered in ?
All the II's I own have got the RAM in sockets.
Sorry, just noticed you mentioned they are soldered in ?
All the II's I own have got the RAM in sockets.
Last edited:
I am searching for a method which doesn't require me to do so as unsoldering 16 RAM (Apple IIc as an example) chips is not ideal for troubleshooting.
Gary C
Veteran Member
Yes, sorry didn't notice. WHen you said Apple II most think of the Apple ][ which has all chips socketed.
daver2
10k Member
If you are testing DRAM, and attempting to use a logic analyser, it will turn you mad.
The DRAM failure modes are quite complex (see the standardised MARCH family of tests).
One problem with a 6502 CPU is that it uses memory in pages 0 and 1. In a machine, the memory could be faulty that you are forced into using!
The only way around this is a bespoke piece of hardware to replace the CPU. This substitutes it's own (known good) RAM for pages 0 and 1. You still need to test the system RAM used for pages 0 and 1, and this can be performed by memory mapping in the bespoke hardware.
I used to use an in-circuit emulator. Of course, this does assume that the CPU is in a socket.
I wrote a PETTESTER. This is good for testing the DRAM, but suffers from the page 0 and 1 issue (because it just occupies a ROM socket).
Dave
The DRAM failure modes are quite complex (see the standardised MARCH family of tests).
One problem with a 6502 CPU is that it uses memory in pages 0 and 1. In a machine, the memory could be faulty that you are forced into using!
The only way around this is a bespoke piece of hardware to replace the CPU. This substitutes it's own (known good) RAM for pages 0 and 1. You still need to test the system RAM used for pages 0 and 1, and this can be performed by memory mapping in the bespoke hardware.
I used to use an in-circuit emulator. Of course, this does assume that the CPU is in a socket.
I wrote a PETTESTER. This is good for testing the DRAM, but suffers from the page 0 and 1 issue (because it just occupies a ROM socket).
Dave
Hugo Holden
Veteran Member
I think there is a good way of doing it (bespoke hardware as Daver2 says), especially in cases where there is an array dynamic RAM chips soldered into the board, but the idea also works for static RAM. DRAM can have more complex fault modes related to refresh sub-cuits and sub-circuits within the IC's them than SRAM.
One of the issues that has to be worked around is that the computer's operating system is mostly critically dependent on the lower memory area. The computer, if it is going to be any use to diagnose most of the defects in the general RAM bank, needs to be perfectly functional.
My solution is to dynamically switch in known functioning SRAM. This only requires that memory reads from the existing RAM to be inhibited, and switching to the known good SRAM in the lower address range only (using an address decoder) and then use the working computer to run diagnostic RAM programs (kept in a ROM) on its own RAM bank. These consist of a block move program to the known good inserted SRAM area and checkerboard patterns and selected byte patterns and happen over a time frame where refresh problems are detected in dynamic RAM. In addition, it allows the DRAM refresh circuits to be checked with the scope.
It is explained in this article how this was done for the PET:
But the basic idea would work for any vintage computer.
The method never fails to get to the bottom of which DRAM chips are defective. It does require interpretation of the bytes returned from memory, as there are some interesting interactions as explained in the article.
This is good to know
My memory test program uses 3 bytes of zero-page memory and 54 bytes a "regular" memory. It has to be hand typed into the ROM monitor. Before doing so I test the three zero-page locations by storing different bytes ($00, $FF, $55, $AA) into them and then reading the contents back. Once they've been verified I type the program into memory (typically $300). I then verify the program is what I had typed in. If it is I feel comfortable using it to test.
The zero-page locations allow me to set the start and end pages and also the start byte within the first page. This allows me flexibility to test different regions of memory. The key is that I need to be able to get the system to this point. Many times I can but other times I cannot. It is also limited in that it cannot test the memory hidden by the ROMs nor the upper 64KB in systems which have it. This was deliberate as I wanted to keep the program small. The larger the program the greater the risk of possibly stumbling across a bad memory location which would prohibit its use. Plus I don't want to type in a lot.
It has limits but it has worked reasonably well to catch several bad memory chips.
I just realized I had purchased the 6502 ROMUlator which should permit me to substitute memory regions for testing purposes. I'll have to get it out and start looking into it again.
daver2
10k Member
I do the same 'trick' with my PETTESTER for page 0 and 1. This catches most stuck bit faults. However, some of the more weird failure modes only turn up with the MARCH test and, by that time, my working memory in pages 0 and 1 are toast and my memory test fails...
Catch 22 situation.
Dave
Catch 22 situation.
Dave
That it is. Sometimes the only answer is to remove the chips. Not a very difficult task but I like to put sockets in and certain chips in a IIc can't utilize sockets as they would raise the height of the chips too high.
Mochatea396
Experienced Member
In my personal experience, and I emphasize personal experience, I've found that the only true accurate way to test RAM chips is in circuit on a working system. Testers have proven to be hit or miss. If the tester says its good, it probably is good but if it says it's bad It very well might not be. I know it's a pain to remove soldered IC's. And oldpcguy is right, the iic has zero clearance for sockets under the drive. I've successfully socketed all 16 ram on 2 of my iics and I think the way the underside of the drive is designed the drive sat down all the way, so nothing is hitting, Very tight though, but you'll be alright socketing the ram . I want to pull the IWM and test it, thats where I left off with that horror story, but I don't think I'll be able to socket it to put it back on, the stepper motor is right there and it's flush with the bottom of the drive, and using a straight edge across the CPU and the IOU projecting that height out, a socketted IC is higher than the bottom of the stepper motor.
Removing the chips isn't difficult but it's something that I would rather not have to do if it can be avoided. I'd rather troubleshoot an issue rather than replace parts. Especially since replacing eight (or sixteen) chips would require eight replacement chips. That would work with one, maybe two systems but I've worked on more than that. Plus there's no guarantee the replacement chips, even if new old stock, work.
Maybe one way to approach it is to take one of the known working boards and place a few of the memory chips into a socket. This would be a test board so there would be no concern about drive clearance. That way I could use the system as the tester. It wouldn't eliminate the need to remove chips from the non-working boards. I can then remove chips from the non-functioning board one by one until I found the bad one(s).
Kelly Gray
Member
Assuming there's even a tiny bit of space below the circuit board, you might be able to use some zero height IC socket pins like these: https://www.digikey.ca/en/products/detail/mill-max-manufacturing-corp/0552-1-15-01-11-27-10-0/158199
Mochatea396
Experienced Member
Those are interesting. How do they install? One in each pin hole and solder the body to the board from underneath?
To simulate a socked I stacked a second DRAM chip on top of the existing chips and then placed the floppy drive in place. There was sufficient clearance so my plan is to install sockets in order to use new, old stock memory chips for testing. If there is insufficient clearance with the sockets I'll pull them out and install the chips directly on the logic board.
Kelly Gray
Member
Yes.
I typically put the pins onto a dead IC then insert that into the board and solder. Once done, I pop out the dead IC, and I have a zero height socket ready for the real IC. It makes keeping the pin alignment easier.
Mochatea396
Experienced Member
That's how I always install pin headers. Put the IC on the headers then solder them on. Keeps them lined up perfectly.