Apple II Repair Tips
Note that authorized Apple dealers repaired boards by swapping them out for tested and repaired boards provided by Apple. They left the board level debugging to Apple.
These approaches may restore many boards to operational status, but certain faults like opens, shorts in the PC board or bad sockets will not be found.
Basically most Apple II's and Apple IIplus machines that don't work correctly, can be "repaired" by reseating chips that aren't making good connections with their sockets. This is the number one problem that occurs with early Apple II's and Apple II plus machines. Finding the chip with the bad connection can be a challenge, but if you are desperate, you can always reseat every chip on the board.
If reseating the chips doesn't
work, then you might have a bad chip. One way to
trouble shoot this is to swap one chip of the same type for another of the same
type and see if behavior of the system changes.
You can also swap chips with chips from another known "good" board. Except for the ROMs, almost all of the chips on the Apple II are still manufactured and available from distributors like mouser or digikey. Some parts are even available from Radio Shack.
The best way to repair a board is to understand the circuit and use an oscilloscope to debug it. This will save wear and tear on old chips and sockets and allow you to fix problems not found by simple swapping/reseating of chips.
You need an oscilloscope and schematics in order to
pinpoint problems without swapping chips. The famous "Red Book" has
the required schematics as well as a nice system diagram. The schematics
and detailed circuit descriptions can also be found in the book "Understanding
Your Apple II" by by Jim Sather. This book is available for download
in pdf format from http://alfter.us/files/uaii.pdf. Older Tektronics oscilloscopes can now be had for very low prices
on Ebay or you can buy a new USB scope that uses a PC
for monitor and control for a few hundred bucks. Keep in mind that
bandwidth may become important as there are some fairly high frequencies in the
video circuit. For instance, a 60 MHZ HP digital storage scope that I
once borrowed didn't have the bandwidth to troubleshoot a color video problem.
It didn’t have enough resolution to detect the master crystal was
out of tolerance. I finally only changed
it only after examining the rest of the circuit and finding no fault.
There are two common errors for Apple II's that are not working: no video and/or system will not boot.
A common failure for a non-working Apple II is that it will not display prompt or boot. You will not even hear the bell, which is done almost immediately after reset is removed from the processor. This is because a large portion of the logic of the Apple II needs to be working before the computer can even get this far. The following parts of the system are required to work in order to ring the bell and get a prompt. In parenthesis is the schematic page in the "Red Book". Be aware that all portions of all of these systems don’t have to be working perfectly in order to get a boot, but some components of each of these systems are critical.
The parts of the system that are not required in order to get a prompt (beware that without video, it is hard to tell how far it gets past the startup beep).
For debugging I would recommend following this sort of sequence
If everything looks normal, then you must try to find out what is happening right after boot. You want to reset the system and check the signals as she boots. Check to see that the F8 ROM is selected right after reset and the output from the ROM looks reasonable both on the ROM itself and back at the processor. DRAM is also accessed just a few cycles after boot when the processor calls a subroutine and the return address is put on the stack. Almost immediately, the screen is put into text mode and the bell is rung.
If your system beeps and boots from floppy disk, but doesn't display video, you problems are far more constrained than a system that simply will not boot. This problem is probably limited to one of the following.
The DRAM address mux (S-7) is used to refresh memory and share DRAM between processor and video. Note that the video system was designed to work at either PAL or NTSC frequencies. Some cuts and jumpers are made on the motherboard to switch frequencies. The master crystal is also changed out to a slightly different frequency for PAL operation. I once spent a considerable amount of time trying to figure out why the vertical sync wouldn’t lock on a new board I had just obtained from eBay. It turned out that it was set up for PAL. Reconfiguring the board to NTSC timing and changing out the PAL frequency crystal to an NTSC frequency crystal solved the issue.
No Prompt Screen after
One system that would not boot, was recently debugged.
Data Bus But Not Driven Completely to
All expansion cards were removed. After probing the clock, data and address pins on the processor with an oscilloscope, I found that the data bus had some bits that looked odd. These bits were not being driven completely down, but only down to 2.5 volts during some cycles. The R/W line was never being driven low, so I knew that the processor was trying to read, and was never writing. After studying the schematics, I found that there were two primary sources for data on the data bus for reads when no I/O cards were present. One were the ROMs and the other was the latches on page S-10.
These latches are 74LS257s at location B6 and B7 on the motherboard. I checked the ROMs to see which ones, if any, were being selected and found that only ROM F8 was being read. I pulled the 74LS257s and the data bus looked cleaner, though I knew the system couldn't boot, since it couldn't read DRAM without these latches. Next I removed the case from the Apple II so I could reach this section of the mother board with an oscilloscope probe. I also put the 74LS257 chips back in place.
Bad Select - F2, pin 12 (less than 1 volt in high state)
I looked at the enable line to the 74LS257s and found it looked funny, being partly driven with a signal of less than 1 volt. As expected, the latches were being selected at the same time as the
Total time to diagnose this problem was about an hour and a half.
After debugging the problem described in case 1, I found that I could now get both a monitor and a basic prompt. However the system would still not boot from floppy. The disk would make noises, but wouldn’t load DOS and start up.
First part of the debugging session involved eliminating the disk controller, floppy and drives from consideration as the source of the fault. This was done by swapping out each of these items with spares that I had available. The result in each case was the same failure to boot. The next step was to move the controller to a different slot in case something was wrong with the slot or slot select logic. No change in symptoms occurred. This pretty much eliminated the floppy sub system or the slots themselves as being at fault. At this point, I called it a day and turned on the TV to see what the Boston Bruins were up to. I did take the schematics along to look for possible fault areas. It turned out to be a good idea as the Bruins soon found themselves on the losing side of a 4-1 score.
The next morning, I had some new energy. Since the system did give me a monitor and
basis prompt, I felt the culprit was most likely the memory subsystem
addressing logic. In order to diagnose
this, I wrote a simple address in address ram test in Applesoft
basic for the memory subsystem. The problem
was most likely in high order bits (8-15) of the address. I didn’t think you would get a monitor
or basic prompt if the system had a problem with the low order bits (0-7) of
the memory addressing system. This program
pokes the high order byte of each location’s address into each memory location
from 6000 to 49151 with a for loop. It then checks the contents of each location to make sure that it was written correctly. The starting point of
6000 was pretty arbitrary, but was high enough to avoid having the program
write over itself or it’s variables.
This is what I should have written. For a memory test, always write all of memory, before checking it. The hardware error would have caused the program to write over itself and crash before finding the error. However it would have been obvious that there was an issue, because video memory would have been written over, prior to the crash.
10 PRINT “WRITING MEMORY”
20 FOR I = 6000 TO 49151
30 I%= I
50 POKE I%,J%
60 NEXT I
70 PRINT “CHECKING MEMORY”
80 FOR I = 6000 to 49151
110 IF PEEK (I%) = J% THEN GOTO 140
120 PRINT “ERROR AT ADD:”;I%;” DATA:”;PEEK(I%);” EXPECTED:”;J%
130 GOTO 160
140 NEXT I
150 PRINT “NO ERROR”
This is what I actually wrote. Turns out the print statement moved video memory prior to the read, causing the peek to fail since it was reading video memory instead of the correct address space. What really made me realize that there was an issue with addressing was the data being written to video memory showing up on the screen.
10 FOR I = 6000 TO 49151
20 I%= I
40 POKE I%,J%
50 PRINT I%,J%
60 IF PEEK (I%) <> J% THEN STOP
70 NEXT I
The results of running this program was an immediate failure at location 6000, revealing that something was wrong with memory addressing. I also noticed that characters filled the screen when this program was run, which was very strange, since low res display memory starts at address 1024 and only runs for 1024 bytes. In order to diagnose further, I dropped down to the Apple’s monitor and converted the address 6000 to hexadecimal 1770. Poking variations of the hexadecimal address 1770 revealed that 770, 1770, 2770 and 3770 all affected the same memory location. This was a bit easier to track down than it sounds, since 770 is a visible part of screen memory and writing zero to any of these locations immediately showed up on the display as an inverse video character. This indicated that bits 12 and 13 of the memory address were being somehow tied together. It was now time to get out the oscilloscope.
To make signals easier to see on the scope, I wrote a simple assembly language program to continuously read from location 1770. This machine happened to be an original Apple II with the mini assembler in ROM and I used it to write the program, but it wouldn’t be much harder to manually enter the 6 bytes necessary for this program using the monitor. The program was.
8000: LDA $1770 ;AD 70 17
JMP $8000 ;4C 00 80
I started the program by typing the monitor command 8000G. Using the oscilloscope, I looked at the address bits on the processor pins 22 and 23. They looked good with address bit 12 toggling high, every cycle in which location 1770 was read and bit 13 staying low all the time. Then the address bus drivers at H4 and H5 were examined at pin 3 on each. Everything looked normal here, as well. The address bus must be ok, if the output of the drivers looks good. The only place remaining where there could be problems with the addressing of DRAM on address lines A12 and A13 was detailed on page S6 of the schematics. I started examining A12 and A13 related signals on chips described on this page of the schematics. As expected, I found that bits A12 and A13 of the address bus looked OK. However the output pin 7 of the 74LS153 multiplexer at C1 that uses A12 and A13 as inputs wasn’t being driven properly. The output from this pin was less than a volt, similar to the output of the 74LS139 in the previous case. I pulled out the jumper block that this signal was connected to, in order to make sure that some other fault wasn’t disturbing this signal. Pulling the jumper block did not affect the signal. I now assumed that this chip was bad and I swapped this chip with a good 74LS153. The output now looked good and the system was able to boot.
Total time to debug was about 2 hours spread over two sessions. The first session was mostly spent eliminating the floppy disk subsystem. The majority of the real progress was made in the second session. I started the second session by focusing in on the addressing of the memory subsytem. Once the memory addressing test was tried and failed, it didn’t take long to track down the root cause of this problem.
I’m still concerned about why two chips in the same section of this computer’s logic failed in a similar way at the same time. With the chips replaced, examination by a scope reveals nothing unusual. I’ll have to keep a close eye on this computer for further failures.
Same board failed again on me. This time it went into a flakey
state where the board would usually, but not always give me a BASIC
prompt after reset,cntrl-B. However, once in Basic, behavior was
eratic, with it accepting some commands at times, and not at other
ranged from crashing to the monitor, to hanging, to printing various
Basic error messages. Behavior was not consistant, so I had
trouble figuring out what I would look at in a scope. Other than
examining various signals for quality, I wasn't sure what to do.
I ended up resorting to the chip swap strategy.