The Macintosh Portable has a certain cachet. It possesses an exquisite keyboard, a crisp screen, and a complete set of ports and slots. Unfortunately, the size, weight, and price were derided at the time of launch.
Presently, the challenges of a Portable are:
1. Most cases are cracked due to transportation and use. The plastic is repairable, is not brittle like the Quadra 800/840AV series, and so this should be overlooked as a reason to avoid owning a Portable. Unless you run a museum, don't sweat a few repaired cracks and missing tabs. Happy little accidents.
2. The batteries are dead. These can be replaced by modern 3D printed cases and gel cells.
3. Capacitors have leaked. The capacitors are no worse than other Macs from the era and most can be recapped easily.
4. The memory cards are unavailable. Occasionally, modern reproductions are produced depending on NOS chip supply. Surprisingly, this is a significant limitation. Most vintage machines (except the IIfx and 4400) can easily have their memories maxed out. If you buy a Portable that turns out to be unrepairable, don't discard the memory card! On eBay, make sure there is a picture of the slots to ensure there is a memory card installed, otherwise you're stuck with only 1 MB, which isn't enough for System 7.
5. The power circuitry is seriously flawed. In hindsight, this is the biggest problem with the Portable. It doesn't work (and can be damaged) without a healthy battery installed, a higher-current AC adapter from a PowerBook fits perfectly and can kill the Portable, the 5120 has a hybrid module that decays and can die from capacitor juice (replacements readily available), and if you hook up your bench supply to only one of the two +V inputs you can kill a whole line of chips.
Based on the last reason, I recommend getting experience with repairing other Macs before you tackle a Portable.
MY ATTEMPTS
I purchased three 5120 and two 5126 portables over the years. They all needed plastic repairs (done), new batteries (done), recaps (done), 4 new hard drives (SD card emulators done), and the 5120s needed hybrid modules (done). The 5126s came with decent memory cards (done). One of the 5120s came with a 5 MB memory card that just needed Deoxit and reseating the chips/SIMMs (done).
The 5126 backlit Portables are working perfectly now, except one has a screen with a dead (always on) pixel. No worries.
All three 5120 boards were dead even after the recap and hybrid replacement. I suspect I am at fault for at least one of the failures. The biggest mistake when repairing these machines is providing power during testing to only one of the +V inputs. I assumed they were tied together on the PCB. I have since created an adapter cut from an old hard drive cable and the top and bottom pair crimped. I use 6.3V with a 1 amp limit on my bench supply (I don't repair with the hard drive installed).
SCREEN
For bench testing, I used a proprietary VGA adapter created by @Androda and sold by Joe's computer museum:
Read the warnings on that page. ABSOLUTELY DO NOT CONNECT A VGA CABLE DIRECTLY TO THE BACK OF THE PORTABLE ITSELF. Also, while you're at Joe's computer museum, buy the BlueSCSI Portable Adapter and (if you own a 5120) a Hybrid module.
The adapter rules out issues with the Portable LCD screen and it is easier to work with a freestanding modern display, rather than propping up the panel. If you see nothing coming out of the VGA adapter, it is possible that this portion of the Portable is damaged. In that case, try the Portable's LCD screen to be sure.
KEYBOARD
I plugged in the Portable's keyboard and mouse for my tests. Pressing a key on the keyboard powers up the Portable.
DRIVES
I used both a FloppyEMU and ZuluSCSI during bench testing. It's nice to have both in case either the SCSI or SWIM chip is blown. I first power up without either drive attached. There is no reason to risk damage to them until you validate that the motherboard can reach the flashing question mark.
SPEAKER
I like to have a speaker plugged in, just in case it gives me a sign of life.
FIRST BOARD (Impossible)
My first 5120 board has a dead power manager chip. The current draw is 33 mA. Pressing the keyboard shows no sign of life and the current draw doesn't change. In a healthy computer, the current draw is 10 mA, going to 300 mA and up when the space bar is pressed.
Without power, I checked the resistance of both the reset and interrupt buttons when pressed (<5 ohm)/released (> 10 kilohm) to make sure they weren't stuck. With power, I tried pressing and holding the pair of buttons to 'reboot' the power manager. Nothing.
I checked for broken traces and created a pinout diagram.
Ultimately, I have thrown in the towel on this Portable. I swapped its best parts (a nice screen and some plastic elements) with one of the other Portables. I will keep the board for parts or in case someone comes up with the replacement power manager.
SECOND BOARD (Easy Peasy)
The second portable had two obvious issues that were easily fixed. The trace (right side of the image below) and the corroded leg on the 244 (left side of image). If you find any issues like this, look around to be sure you found them all. Also, resolder all the legs of nearby chips if any leg shows dullness or corrosion.
THIRD BOARD (Complicated Success)
This last Portable motherboard did not make a startup sound and shows vertical pinstripes. However, it begins with a low current draw (10 mA) and wakes (~300 mA) when the keyboard is pressed. So, the power manager is working.
The slots on the Portable have lots of valuable pins for testing. (Please note that the ROM and RAM slots are numbered from bottom to top on the motherboard but top to bottom on the schematic, whereas the PDS slot numbering matches the motherboard and schematic.)
Any pin with an asterisk '*' at the end of the name means it is activated when the signal goes low. For example, SYS_PWR* is 5V when the Portable is sleeping and 0V when the Portable is awake. Got it? Opposite day. SYS_PWR* = 0 = GOOD.
ROM_CS* 0V indicates the ROM is being accessed. ROM_CS*=0=GOOD.
BERR* 0V says a bad address was accessed. BERR*=0=BAD.
SYS_RST* 0V means the computer is halted waiting for power to stabilize or the computer will now restart. SYS_RST*=0 steady=BAD.
Get yourself some male-to-male jumper test leads and male-to-female jumper test leads for connecting an oscilloscope to the ports. I really like these:
In the image below, I am watching BERR* (bus error) and SYS_RST* (system reset).
On this board, I noticed that after power up, this computer would show bus error, then system reset (correct: it should reset after a bad address), followed by four ROM accesses, followed by quiet, and then repeat.
What's going on? Well, when the power manager tells the 68000 to proceed (SYS_RESET* 5V = GOOD, SYS_PWR* 0V = GOOD), the following happens:
1. The CPU sets the address lines to $00000000 to read the ROM.
2. The CPU GLU sees this and sets ROM_CS* (ROM chip select) to 0V. Remember, low signal is active on pins with an asterisk. ROM_CS*=0=GOOD
3. The ROM chips see the ROM_CS* signal on their pin 22. The LO ROM chip outputs 8 bits (D0-D7). The HI ROM chip outputs 8 bits (D8-D15). Why? This is 16-bits. Ever heard of a 16-bit data bus? That's what this is.
4. The CPU reads all 16 bits of data and sets the address to $00000002.
5. The CPU GLU disabled ROM_CS* (5V) when the CPU completed the read. But, it now sees the request for $00000002 and sets ROM_CS* to 0V again. ROM outputs.
6. The CPU reads those next 16 bits (32 so far) and stores that as the stack pointer. It then sets the address to $00000004.
7. CPU GLU, ROM supply the next 16 bits. CPU sets to address $00000006. CPU GLU etc ROM supply the next 16 bits.
8. The CPU jumps to the address specified in those most recent 32 bits.
To summarize, read the first 4 bytes of ROM (2 bytes at a time) for the stack pointer. Read the next 4 bytes of ROM (2 bytes at a time) for the address pointer.
The next step in a healthy Portable should be:
9. CPU sets the address to $0090002A because this was the most recent 32-bits sent from the ROM. If you disassemble the ROM (or a ROM file), you'll find these are the fourth through eighth bytes in the ROM.
10. A magical moment for the CPU GLU. It says "Wow! You found the final home for the ROM. I am remapping it to $009XXXXX from now on." Cool huh? ROM started at $000XXXXX at power up, but from now on will be $009XXXXX. The CPU GLU will also set the ROM_CS* active (0V) because it knows the CPU wants to read the next instruction from ROM at this new address.
On my Portable, however, ROM_CS* was not going low at this point. I got four good pulses (reads the first 8 bytes, 16 bits at a time) followed by this moment when ROM_CS* was not being activated by the CPU GLU. Why not?
Since the circuit was auto restarting over and over, I connected my oscilloscope to each data pin on the CPU and recorded the low/high pattern. In a spreadsheet, it looked like this:
The third+fourth row should be $0090002A, but instead the data from the ROM reads $00800022. D4 is always low.
What is address $00800022 on the Portable? Nothing. Bus error! Reset! The CPU is doing its job -- it is just being told the wrong information.
SWIM DROWNING D4
I checked the traces with a multimeter. They're good. Is the ROM faulty? Possible but unlikely.
@techknight advises people to replace the SWIM on their Portable. Why? On a hunch, I snipped D4 on the SWIM.
Chime! Good ROM data.
The SWIM can fail passively (no response) or actively (interfering with other signals). My SWIM failed actively on pin D4. Yours may differ.
The Portable now got to here (see image below). We see a valid pattern on the screen. This is really good news. It means video works, the CPU works, the ROM works (this pattern was read from ROM), etc, etc etc. But, look closely and you'll notice this isn't the normal every-other-pixel pattern. This is the 'I'm testing memory or other stuff' diagonal pattern. No cursor and no disk icon.
I removed the SWIM with hot air. Same diagonal patten. Some people think the Portable can boot with the SWIM removed. It cannot.
I substituted the SWIM from a dead PowerBook 170 and was greeted with:
Success.
This particular board also needed a sound crash fix which I will describe some other time. But, hopefully this demonstrates the start up sequence and a technique that you can use to hunt down problems in your Portable.
- David
Presently, the challenges of a Portable are:
1. Most cases are cracked due to transportation and use. The plastic is repairable, is not brittle like the Quadra 800/840AV series, and so this should be overlooked as a reason to avoid owning a Portable. Unless you run a museum, don't sweat a few repaired cracks and missing tabs. Happy little accidents.
2. The batteries are dead. These can be replaced by modern 3D printed cases and gel cells.
3. Capacitors have leaked. The capacitors are no worse than other Macs from the era and most can be recapped easily.
4. The memory cards are unavailable. Occasionally, modern reproductions are produced depending on NOS chip supply. Surprisingly, this is a significant limitation. Most vintage machines (except the IIfx and 4400) can easily have their memories maxed out. If you buy a Portable that turns out to be unrepairable, don't discard the memory card! On eBay, make sure there is a picture of the slots to ensure there is a memory card installed, otherwise you're stuck with only 1 MB, which isn't enough for System 7.
5. The power circuitry is seriously flawed. In hindsight, this is the biggest problem with the Portable. It doesn't work (and can be damaged) without a healthy battery installed, a higher-current AC adapter from a PowerBook fits perfectly and can kill the Portable, the 5120 has a hybrid module that decays and can die from capacitor juice (replacements readily available), and if you hook up your bench supply to only one of the two +V inputs you can kill a whole line of chips.
Based on the last reason, I recommend getting experience with repairing other Macs before you tackle a Portable.
MY ATTEMPTS
I purchased three 5120 and two 5126 portables over the years. They all needed plastic repairs (done), new batteries (done), recaps (done), 4 new hard drives (SD card emulators done), and the 5120s needed hybrid modules (done). The 5126s came with decent memory cards (done). One of the 5120s came with a 5 MB memory card that just needed Deoxit and reseating the chips/SIMMs (done).
The 5126 backlit Portables are working perfectly now, except one has a screen with a dead (always on) pixel. No worries.
All three 5120 boards were dead even after the recap and hybrid replacement. I suspect I am at fault for at least one of the failures. The biggest mistake when repairing these machines is providing power during testing to only one of the +V inputs. I assumed they were tied together on the PCB. I have since created an adapter cut from an old hard drive cable and the top and bottom pair crimped. I use 6.3V with a 1 amp limit on my bench supply (I don't repair with the hard drive installed).
SCREEN
For bench testing, I used a proprietary VGA adapter created by @Androda and sold by Joe's computer museum:
Read the warnings on that page. ABSOLUTELY DO NOT CONNECT A VGA CABLE DIRECTLY TO THE BACK OF THE PORTABLE ITSELF. Also, while you're at Joe's computer museum, buy the BlueSCSI Portable Adapter and (if you own a 5120) a Hybrid module.
The adapter rules out issues with the Portable LCD screen and it is easier to work with a freestanding modern display, rather than propping up the panel. If you see nothing coming out of the VGA adapter, it is possible that this portion of the Portable is damaged. In that case, try the Portable's LCD screen to be sure.
KEYBOARD
I plugged in the Portable's keyboard and mouse for my tests. Pressing a key on the keyboard powers up the Portable.
DRIVES
I used both a FloppyEMU and ZuluSCSI during bench testing. It's nice to have both in case either the SCSI or SWIM chip is blown. I first power up without either drive attached. There is no reason to risk damage to them until you validate that the motherboard can reach the flashing question mark.
SPEAKER
I like to have a speaker plugged in, just in case it gives me a sign of life.
FIRST BOARD (Impossible)
My first 5120 board has a dead power manager chip. The current draw is 33 mA. Pressing the keyboard shows no sign of life and the current draw doesn't change. In a healthy computer, the current draw is 10 mA, going to 300 mA and up when the space bar is pressed.
Without power, I checked the resistance of both the reset and interrupt buttons when pressed (<5 ohm)/released (> 10 kilohm) to make sure they weren't stuck. With power, I tried pressing and holding the pair of buttons to 'reboot' the power manager. Nothing.
I checked for broken traces and created a pinout diagram.
Ultimately, I have thrown in the towel on this Portable. I swapped its best parts (a nice screen and some plastic elements) with one of the other Portables. I will keep the board for parts or in case someone comes up with the replacement power manager.
SECOND BOARD (Easy Peasy)
The second portable had two obvious issues that were easily fixed. The trace (right side of the image below) and the corroded leg on the 244 (left side of image). If you find any issues like this, look around to be sure you found them all. Also, resolder all the legs of nearby chips if any leg shows dullness or corrosion.
THIRD BOARD (Complicated Success)
This last Portable motherboard did not make a startup sound and shows vertical pinstripes. However, it begins with a low current draw (10 mA) and wakes (~300 mA) when the keyboard is pressed. So, the power manager is working.
The slots on the Portable have lots of valuable pins for testing. (Please note that the ROM and RAM slots are numbered from bottom to top on the motherboard but top to bottom on the schematic, whereas the PDS slot numbering matches the motherboard and schematic.)
Any pin with an asterisk '*' at the end of the name means it is activated when the signal goes low. For example, SYS_PWR* is 5V when the Portable is sleeping and 0V when the Portable is awake. Got it? Opposite day. SYS_PWR* = 0 = GOOD.
ROM_CS* 0V indicates the ROM is being accessed. ROM_CS*=0=GOOD.
BERR* 0V says a bad address was accessed. BERR*=0=BAD.
SYS_RST* 0V means the computer is halted waiting for power to stabilize or the computer will now restart. SYS_RST*=0 steady=BAD.
Get yourself some male-to-male jumper test leads and male-to-female jumper test leads for connecting an oscilloscope to the ports. I really like these:
In the image below, I am watching BERR* (bus error) and SYS_RST* (system reset).
On this board, I noticed that after power up, this computer would show bus error, then system reset (correct: it should reset after a bad address), followed by four ROM accesses, followed by quiet, and then repeat.
What's going on? Well, when the power manager tells the 68000 to proceed (SYS_RESET* 5V = GOOD, SYS_PWR* 0V = GOOD), the following happens:
1. The CPU sets the address lines to $00000000 to read the ROM.
2. The CPU GLU sees this and sets ROM_CS* (ROM chip select) to 0V. Remember, low signal is active on pins with an asterisk. ROM_CS*=0=GOOD
3. The ROM chips see the ROM_CS* signal on their pin 22. The LO ROM chip outputs 8 bits (D0-D7). The HI ROM chip outputs 8 bits (D8-D15). Why? This is 16-bits. Ever heard of a 16-bit data bus? That's what this is.
4. The CPU reads all 16 bits of data and sets the address to $00000002.
5. The CPU GLU disabled ROM_CS* (5V) when the CPU completed the read. But, it now sees the request for $00000002 and sets ROM_CS* to 0V again. ROM outputs.
6. The CPU reads those next 16 bits (32 so far) and stores that as the stack pointer. It then sets the address to $00000004.
7. CPU GLU, ROM supply the next 16 bits. CPU sets to address $00000006. CPU GLU etc ROM supply the next 16 bits.
8. The CPU jumps to the address specified in those most recent 32 bits.
To summarize, read the first 4 bytes of ROM (2 bytes at a time) for the stack pointer. Read the next 4 bytes of ROM (2 bytes at a time) for the address pointer.
The next step in a healthy Portable should be:
9. CPU sets the address to $0090002A because this was the most recent 32-bits sent from the ROM. If you disassemble the ROM (or a ROM file), you'll find these are the fourth through eighth bytes in the ROM.
10. A magical moment for the CPU GLU. It says "Wow! You found the final home for the ROM. I am remapping it to $009XXXXX from now on." Cool huh? ROM started at $000XXXXX at power up, but from now on will be $009XXXXX. The CPU GLU will also set the ROM_CS* active (0V) because it knows the CPU wants to read the next instruction from ROM at this new address.
On my Portable, however, ROM_CS* was not going low at this point. I got four good pulses (reads the first 8 bytes, 16 bits at a time) followed by this moment when ROM_CS* was not being activated by the CPU GLU. Why not?
Since the circuit was auto restarting over and over, I connected my oscilloscope to each data pin on the CPU and recorded the low/high pattern. In a spreadsheet, it looked like this:
The third+fourth row should be $0090002A, but instead the data from the ROM reads $00800022. D4 is always low.
What is address $00800022 on the Portable? Nothing. Bus error! Reset! The CPU is doing its job -- it is just being told the wrong information.
SWIM DROWNING D4
I checked the traces with a multimeter. They're good. Is the ROM faulty? Possible but unlikely.
@techknight advises people to replace the SWIM on their Portable. Why? On a hunch, I snipped D4 on the SWIM.
Chime! Good ROM data.
The SWIM can fail passively (no response) or actively (interfering with other signals). My SWIM failed actively on pin D4. Yours may differ.
The Portable now got to here (see image below). We see a valid pattern on the screen. This is really good news. It means video works, the CPU works, the ROM works (this pattern was read from ROM), etc, etc etc. But, look closely and you'll notice this isn't the normal every-other-pixel pattern. This is the 'I'm testing memory or other stuff' diagonal pattern. No cursor and no disk icon.
I removed the SWIM with hot air. Same diagonal patten. Some people think the Portable can boot with the SWIM removed. It cannot.
I substituted the SWIM from a dead PowerBook 170 and was greeted with:
Success.
This particular board also needed a sound crash fix which I will describe some other time. But, hopefully this demonstrates the start up sequence and a technique that you can use to hunt down problems in your Portable.
- David
