apple 2 logo
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.

"Shotgun" Repairs

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.

Bad Connections: reseating the chips

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.

Bad Chips: Exchanging the chips

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.

Targeted Repairs

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.

What you need

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  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.

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

  1. Check voltages from power supply
  2. Check processor to make sure it is not being held in reset
  3. Check processor to make sure it is receiving 1MHZ clock
  4. Check address bus to make sure that all signals look normal
  5. Check data bus to make sure that all signals look normal
  6. Check chips selects on ROMs to see which ones are being selected, if any.
  7. Check R/W line to see if processor is just reading instructions or writing data, as well

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.


No Video

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.

Apple Service Notes!

Check out these service notes that someone sent me.  There are a lot of tips in this doc, including information on peripheral cards.  I found at least one error while putting these notes into PDF format, so beware, but there are a lot of good ideas in there.

Testing Ram

Apple's programmers aid prom contantains a nice memory test that can be run from PROM.  I have ported a 6502 memory test to the Apple 1 and Apple 2, but it runs from memory, so the system has to be pretty functional for it to work.

Example Debugging Sessions

Case 1:


no boot

Typical No Prompt Screen after Power ON

One system that would not boot, was recently debugged.

bad data bus bit
Data Bus But Not Driven Completely to Low State

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)

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 ROM.  The source of this line went through the jumper at D1 back to pin 12 of the 74LS139 at F2, which also looked bad.  The inputs to the chip at F2 looked good.   I swapped F2 with the 74LS139 at E2 and I got a prompt.  I expected a bad connection between the chip and the socket that would be resolved by this swap. Further testing showed that something else was now wrong with the system.   Now suspecting a bad chip, I swapped the two chips back and the system failed to boot, revealing that the source of my problems was a bad 74LS139 at location F2.  The output of pin12 of this chip was burned out.


Total time to diagnose this problem was about an hour and a half.


Case 2:


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

            40 J%=I/256

            50 POKE I%,J%

            60 NEXT I

            70 PRINT “CHECKING MEMORY”

            80 FOR I = 6000 to 49151

            90 I%=I

            100 J%=I/256

            110 IF PEEK (I%) = J% THEN GOTO 140


            130 GOTO 160

            140 NEXT I

            150 PRINT “NO ERROR”

            160 END

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

            30 J%=I/256

            40 POKE I%,J%
            50 PRINT I%,J%

            60 IF PEEK (I%) <> J% THEN STOP

            70 NEXT I
            80 END

 writing video memory

Arrows Show How Writes to Some Memory Locations Causes Ampersand to be Written to Video Memory

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.

Case 3:


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 times.  Errors 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.  

I had a spare board of the same rev level and I started swapping chips.  Mostly, I tried chips that were connected to various chip selects such as address decoders.  Not much luck with that.   I did write a simple address in address test and got it to run, when the machine was being somewhat nice to me, but it found no problem.  I decided to drag out the old copy of Red Book schematics, and take a break.  Thinking that  addressing was probably OK, I thought about what other kind of problem would give me this kind of flakey results.  The next obvious choice was the data bus.   I swapped the 8T28s data bus transceivers, but got the same results.  I swapped memory from one bank to another in case a memory chip was going bad on me.  No change.  Looking at the schematics again, revealed a couple 74LS174's buffering the DRAM data outputs(B5 and B8).  I swapped these with the chips from my donor board and the problem went away.  I swapped them back and the problem returned, showing that the problem wasn't a bad connection in the socket.  I now swapped just one of the two chips and found the problem disappeared, once again.  Total time to resolve the issue was about an hour and a half.  

Moral of this exercise is that random chip swapping will probably not get you to a solution very rapidly, at least without some thought.  The chip swapping approach needs to be done with some strategy in mind.   When I was first just swapping likely chips in the addressing area, I really wasn't using my full knowledge of the computer.   Once I pulled out the schematics and really thought about it, I found the problem rather quickly.

Also See My VCF Presentations


Back to Mike's Hobby Home Page