The Macintosh II computer motherboard revision 820-0228-A is the most common. Unfortunately, it is the most corroded due to using many more surface-mount electrolytic capacitors. Nearly all of the repair work is located around these leaky capacitors.
The techniques described in this post are applicable to the earlier motherboards, although the issues are rarer on those boards due to fewer surface mount electrolytics.
The motherboard parts were renumbered with each major revision. This posting and the Bomarc schematic uses the 820-0228-A numbers.
Do Not Pass Go
Sometimes you need to decide to walk away from a motherboard that is too damaged. Instead, use it as a parts machine. Examples:
Power
Almost all Macintosh II motherboards suffer from power-on issues, due to the batteries constantly applying power to long traces. In the presence of moisture or leaked electrolyte, this results in electrolysis, which corrodes metals more rapidly.
It is assumed that you’ve already corrected broken traces leading from the power switch and batteries, as well as likely replaced UB2. Before proceeding, your Macintosh should power on (fan turns on) and the +5 and +12V voltages should test as good.
Recap, Obvious Trace Repair, and Cleanup
It is assumed you’ve recapped the motherboard, repaired any obvious broken traces, and cleaned residue. This is always your first step in getting an old Macintosh working.
Next Steps
Reset Line
Test ~ARST, which is nicely available on pin 5 of the sound chip. This is the reset line and flows throughout the board. It should be high (5V) when the computer is allowed to run. Pressing the reset button causes the line to go low and then high.
(In the image above, my UI15 is socketed because I had to replace a bad sound chip.)
If the reset line is never going high, or is repeatedly and immediately going low again, then check the reset switch, sound chip, and the traces, capacitors, and resistors connected to them. Below is an image of an oscilloscope trace of the reset line (yellow trace) immediately resetting due to a bad sound chip. This chip is near three of four leaky capacitors.
On the other hand, if there is a decent time gap between going high and then low (briefly), then the CPU is likely running and having trouble reading the ROMs (more details later). To verify that, you should watch the bus error pin 19 on the GLU chip. Reset should go high, bus error should go high, and then if bus error goes low, the CPU is correctly supposed to assert a reset.
When diagnosing a problem, I like to use the reset line as the trigger on my oscilloscope. I can press the reset button and capture a trace of the initial behavior anywhere on the board.
Crystals
Check the 40 MHz clock by measuring pin 18 on UG8. Check the 31.3344 MHz clock by measuring pin 9 on UG8 (and optionally pin 11 on H5 and on the CLK pin on CPU socket). I have had to replace 31.3344 MHz oscillators on two of my dead boards. This could be due to my ultrasonic cleaner. Or, it could be these were poorly manufactured.
Removing the oscillator can be challenging due to the metal can. Check your work carefully, as I broke the ground pad on mine. It would have been really difficult to find this fault had I not checked before soldering a new oscillator on top of it.
Actually --- before removing the oscillator, test the pins directly underneath with power turned on. If you’re getting a good frequency there, it may be that UG8 itself is compromised. Capacitor goo from C11 may be preventing contact with the pads, may have broken traces leading to the pads, or may have damaged UG8.
Here are the traces underneath.
Wonderful GLU
At this point, power is good, reset is going high for at least a while, and a good clock signal is being generated. The CPU should now be running. Its first step is to try to read from the ROMs.
The GLU chip watches the address lines and lets all the other support chips know when it is time to listen or talk. It does this by enabling (low signal) a trace that goes only to a specific chip when their address is selected. As such, the GLU is a great place to watch the start up process and to see where something gets stuck. (Image below: Just look at all of those select lines.)
ROMs
As stated earlier, the first step after coming out of reset is to read the first four bytes out of the ROMs. Each ROM chip supplies one byte simultaneously. Put a low trigger on pin 20 of UF11. That’s the enable pin. In normal operation at startup, you should see a continuous or repeated low signal as the CPU executes ROM code (read, execute, read, execute) and sometimes high for a short time (reading RAM or another chip).
If you see two enables or a long enabled followed by a bus error (pin 19 GLU) and a reset, then the ROM is not being read correctly. Swap them with known working ROMs if you can. Check continuity on each trace. You can even pretend to be Adrian from Adrian’s Digital Basement and watch each ROM line on an oscilloscope to see if it is showing activity and strong highs and lows.
Worst case, you can flip the board over, set the scope to trigger on reset (single shot capture), and then one by one manually read the data line values (move to the next data pin, rearm the scope, pressing the reset button on the Mac II). Do that 32 times and you should have what the CPU is seeing as the first four bytes of ROM.
You might think this is a crazy approach. But, if there is a bad chip (or shorted trace) somewhere on the board, it can interfere (talk over) with the signals coming back from the ROM. This is how I found a bad SWIM chip on the Macintosh Portable. It was talking on the data lines even when it wasn’t that chip’s turn.
Diagnostic ROM
The Macintosh II (and later machines) have a built-in serial diagnostic. If the CPU is able to read the ROMs and access the SCC, then the serial port routines will kick in upon cold-start error detection, even if the RAM is bad.
https://wiki.retrotechcollection.com/Diagnostic_Serial_Console
For one bad Mac II, I noticed pin 60 on the GLU was enabling (low signal) the SCC (serial chip) repeatedly. It struck me that the Mac was sitting and listening on the serial port. Oh! That’s a good thing. Serial diagnostic!
Soldering it properly fixed this Mac. Thank you Serial ROM Diagnostic.
Other notes:
One of the benefits of getting the Macintosh to point of the Sad Mac chime, is that the Macintosh TechStep device can then work with it. Although I haven’t had a lot of success finding the source of issues using a TechStep, it can confirm what works.
In this odd case however, the TechStep reported that the ROM checksum failed. After swapping individual ROMs with known good ones, I found that bits 4 & 5 were bad in about 100 places on one of the ROMs. I am surprised it could even get to the diagnostic mode.
Using a GQ-4x4 universal programmer, I read the known good ROM and wrote it to a 27C512 EPROM to replace the bad one.
Boot to Frozen Cursor or Stuck Mouse
Your Macintosh II is now working. You get a happy chime, a cursor, a happy Mac, and you boot into the OS. Congratulations.
But wait, the cursor won’t move and the keyboard doesn’t type. If you’re lucky, the mouse click will pull down the Apple menu to show you that ADB is actually working. What’s going on?
Every 60th of a second, the Mac performs tasks like calculating mouse movements. If the interrupt signal from the VIA chip does not arrive at the GLU, then the CPU doesn’t know it’s time to calculate. And wouldn’t you know it, our old friend C11 has sneakily leaked right under the corner of the GLU chip, where the VIA interrupt arrives.
A little solder, cleaning, and maybe a bodge wire fixes this.
Three Successes
Using these techniques, I was able to fully revive a number of ‘dead’ Macintosh II boards. More importantly, it helped me to understand the early power up process. Even if you have a newer Macintosh, you can apply many of the same techniques to diagnosing early failures.
- David
The techniques described in this post are applicable to the earlier motherboards, although the issues are rarer on those boards due to fewer surface mount electrolytics.
The motherboard parts were renumbered with each major revision. This posting and the Bomarc schematic uses the 820-0228-A numbers.
Do Not Pass Go
Sometimes you need to decide to walk away from a motherboard that is too damaged. Instead, use it as a parts machine. Examples:
- Motherboard is battery bombed. Not just a little corrosion or leakage.
- Trace damage all over (not just near capacitors). Might have been stored in moist conditions.
- Shorted inside the PCB. Moisture, battery juice, or capacitor juice got into the layers. This is rare, but not repairable.
- Physically destroyed. Cracked board, smashed SIMM slots.
Power
Almost all Macintosh II motherboards suffer from power-on issues, due to the batteries constantly applying power to long traces. In the presence of moisture or leaked electrolyte, this results in electrolysis, which corrodes metals more rapidly.
It is assumed that you’ve already corrected broken traces leading from the power switch and batteries, as well as likely replaced UB2. Before proceeding, your Macintosh should power on (fan turns on) and the +5 and +12V voltages should test as good.
Recap, Obvious Trace Repair, and Cleanup
It is assumed you’ve recapped the motherboard, repaired any obvious broken traces, and cleaned residue. This is always your first step in getting an old Macintosh working.
Next Steps
- Remove and reseat the memory SIMMs. DeoxIT. Check for tarnish on SIMM pads. Try known good memory. 1 MB SIMMs (not larger) in Bank A only are a good test. Make sure the SIMMs are clipped in nicely and that broken SIMM socket tabs aren’t the problem.
- Remove and reseat the ROMs. DeoxIT. Check for tarnish on leads. If you have a working Macintosh II, swap the ROMs with it.
- You can try swapping the IWM, CPU, FPU, MMU, and Sound Chip between a working and non-working motherboard. However, I have not encountered a Macintosh II where any of these chips was at fault.
- If no startup chime, test the speaker itself after unplugging it from the motherboard. It should be around 32 ohm. Shorted or open means the speaker is bad.
- Test the Reset and Interrupt Switches. Measure across the top of each switch with a multimeter. On the board, they should be 1 kilohm (interrupt) 140 ohm (reset) or more when released, and less than 10 ohm when pressed. If you aren’t seeing a wide swing between pressed and released, the switch is corroded internally and needs to be removed or replaced.
Reset Line
Test ~ARST, which is nicely available on pin 5 of the sound chip. This is the reset line and flows throughout the board. It should be high (5V) when the computer is allowed to run. Pressing the reset button causes the line to go low and then high.
(In the image above, my UI15 is socketed because I had to replace a bad sound chip.)
If the reset line is never going high, or is repeatedly and immediately going low again, then check the reset switch, sound chip, and the traces, capacitors, and resistors connected to them. Below is an image of an oscilloscope trace of the reset line (yellow trace) immediately resetting due to a bad sound chip. This chip is near three of four leaky capacitors.
On the other hand, if there is a decent time gap between going high and then low (briefly), then the CPU is likely running and having trouble reading the ROMs (more details later). To verify that, you should watch the bus error pin 19 on the GLU chip. Reset should go high, bus error should go high, and then if bus error goes low, the CPU is correctly supposed to assert a reset.
When diagnosing a problem, I like to use the reset line as the trigger on my oscilloscope. I can press the reset button and capture a trace of the initial behavior anywhere on the board.
Crystals
Check the 40 MHz clock by measuring pin 18 on UG8. Check the 31.3344 MHz clock by measuring pin 9 on UG8 (and optionally pin 11 on H5 and on the CLK pin on CPU socket). I have had to replace 31.3344 MHz oscillators on two of my dead boards. This could be due to my ultrasonic cleaner. Or, it could be these were poorly manufactured.
Removing the oscillator can be challenging due to the metal can. Check your work carefully, as I broke the ground pad on mine. It would have been really difficult to find this fault had I not checked before soldering a new oscillator on top of it.
Actually --- before removing the oscillator, test the pins directly underneath with power turned on. If you’re getting a good frequency there, it may be that UG8 itself is compromised. Capacitor goo from C11 may be preventing contact with the pads, may have broken traces leading to the pads, or may have damaged UG8.
Here are the traces underneath.
Wonderful GLU
At this point, power is good, reset is going high for at least a while, and a good clock signal is being generated. The CPU should now be running. Its first step is to try to read from the ROMs.
The GLU chip watches the address lines and lets all the other support chips know when it is time to listen or talk. It does this by enabling (low signal) a trace that goes only to a specific chip when their address is selected. As such, the GLU is a great place to watch the start up process and to see where something gets stuck. (Image below: Just look at all of those select lines.)
ROMs
As stated earlier, the first step after coming out of reset is to read the first four bytes out of the ROMs. Each ROM chip supplies one byte simultaneously. Put a low trigger on pin 20 of UF11. That’s the enable pin. In normal operation at startup, you should see a continuous or repeated low signal as the CPU executes ROM code (read, execute, read, execute) and sometimes high for a short time (reading RAM or another chip).
If you see two enables or a long enabled followed by a bus error (pin 19 GLU) and a reset, then the ROM is not being read correctly. Swap them with known working ROMs if you can. Check continuity on each trace. You can even pretend to be Adrian from Adrian’s Digital Basement and watch each ROM line on an oscilloscope to see if it is showing activity and strong highs and lows.
Worst case, you can flip the board over, set the scope to trigger on reset (single shot capture), and then one by one manually read the data line values (move to the next data pin, rearm the scope, pressing the reset button on the Mac II). Do that 32 times and you should have what the CPU is seeing as the first four bytes of ROM.
You might think this is a crazy approach. But, if there is a bad chip (or shorted trace) somewhere on the board, it can interfere (talk over) with the signals coming back from the ROM. This is how I found a bad SWIM chip on the Macintosh Portable. It was talking on the data lines even when it wasn’t that chip’s turn.
Diagnostic ROM
The Macintosh II (and later machines) have a built-in serial diagnostic. If the CPU is able to read the ROMs and access the SCC, then the serial port routines will kick in upon cold-start error detection, even if the RAM is bad.
https://wiki.retrotechcollection.com/Diagnostic_Serial_Console
For one bad Mac II, I noticed pin 60 on the GLU was enabling (low signal) the SCC (serial chip) repeatedly. It struck me that the Mac was sitting and listening on the serial port. Oh! That’s a good thing. Serial diagnostic!
- Connect another computer to the Mac II modem port. UART to USB adapters work. You’ll need a null-modem or crossover cable so that the transmit line of one computer connects to the receive line on the other.
- Open a terminal program on the other computer with 9600 baud, 8 data bits, 2 stop bits (unusual), and no parity. Echo off.
- Power up the computer. You can press the interrupt button quickly to force the diagnostic mode. But usually, you’ll enter this mode without a choice because a critical startup test will fail.
- Wait for the sad mac chime to end. The computer is running without interrupts or RAM at this point, so everything is sequential.
- Type *A (always capital letters) and no return.
- If diagnostic mode is entered, the Mac will respond with *A
- Type *R if you’re bored. The Mac may respond with 0000FFFF0001*R or something like that. On later computers, this gives the reason that the Mac entered diagnostic mode. On these early Macs, it might be installed SIMMs or it might be garbage. But, it isn’t the reason the Mac failed startup.
- Don’t type *V, which displays version information on later Macs. The Mac II didn’t have this feature. For the initial ROM, it supports S, L, B, D, C, G, N 0, 1, 2, 3, 4, 5, 6, A, H, R, M, E, I ,T(0 to 7 see ROM instruction at 803184). On a working Macintosh II, you can enter Macsbug and type _TestManager to find the start of the diagnostic code, if you’re interested.
- Type *L00800000 (always 8 digits). The Mac will respond *L. This sets the address for the next read or write to the start of ROM.
- Type *M. The Mac should respond with 9779D2C4*M. Search for those 8 digits with your browser and you’ll see those are the first four bytes of ROM. If your number is different, confirm that matches your ROM. If not, I’m not sure how you got here.
- Type *L00000000 to set the address to the start of RAM.
- Type *B0004 (always four digits) to say you want to write four bytes.
- Type *D12345678 (or whatever you want) to write four bytes to the start of RAM.
- Type *L00000000 to set the address to the start of RAM again.
- Type *M and the Mac should respond with 12345678*M.
Soldering it properly fixed this Mac. Thank you Serial ROM Diagnostic.
Other notes:
- You can’t use the non-critical tests (N) until RAM is working.
- If you try to execute a test or command that it doesn’t have, it will respond with ‘?’.
- If you type too many digits or too few, you may get into a weird spot where it doesn’t seem to be taking commands. This is particularly common with digits 0 and 1, as they are the start of two other commands. So, L000000000 (nine digits) it will read the last 0 as the start of a command that expects eight more digits. If you ever get hung up, press the reset button and try again.
One of the benefits of getting the Macintosh to point of the Sad Mac chime, is that the Macintosh TechStep device can then work with it. Although I haven’t had a lot of success finding the source of issues using a TechStep, it can confirm what works.
In this odd case however, the TechStep reported that the ROM checksum failed. After swapping individual ROMs with known good ones, I found that bits 4 & 5 were bad in about 100 places on one of the ROMs. I am surprised it could even get to the diagnostic mode.
Using a GQ-4x4 universal programmer, I read the known good ROM and wrote it to a 27C512 EPROM to replace the bad one.
Boot to Frozen Cursor or Stuck Mouse
Your Macintosh II is now working. You get a happy chime, a cursor, a happy Mac, and you boot into the OS. Congratulations.
But wait, the cursor won’t move and the keyboard doesn’t type. If you’re lucky, the mouse click will pull down the Apple menu to show you that ADB is actually working. What’s going on?
Every 60th of a second, the Mac performs tasks like calculating mouse movements. If the interrupt signal from the VIA chip does not arrive at the GLU, then the CPU doesn’t know it’s time to calculate. And wouldn’t you know it, our old friend C11 has sneakily leaked right under the corner of the GLU chip, where the VIA interrupt arrives.
A little solder, cleaning, and maybe a bodge wire fixes this.
Three Successes
Using these techniques, I was able to fully revive a number of ‘dead’ Macintosh II boards. More importantly, it helped me to understand the early power up process. Even if you have a newer Macintosh, you can apply many of the same techniques to diagnosing early failures.
- David
