I bought a Macintosh Portable backlight model a while ago and I finally got around to working on it. The case and screen were in almost perfect condition. No scratches or cracks. The motherboard was in decent shape too but obviously it needed recapping.
I washed it in soapy water, rinsed it in isopropyl alcohol by dipping it in for a while and recapped it. I rebuilt the battery with a new 6V one. I saw a trace on the back that looked to be broken from capacitor leakage so I fixed that, or so I thought. This was a mistake. More on this later.
With great hope, I assembled the machine and pressed the space bar. To my disappointment, nothing happened. I could hear a slight click in the speaker so I knew it was powering on. I checked the voltage regulator output and it was good at 5.2V. I checked the CPU clock, VCC and reset line and they were all fine, too. I checked the address and data bus and they all seem to be doing something. I read that sometimes the SWIM chip would go bad so I desoldered it but it made no difference.
So I used a cheap 8-ch logic analyser to look into what was going on. This post was very helpful in understanding what goes on at the power on time. https://tinkerdifferent.com/threads/fixing-a-macintosh-portable-what-worked-for-me.4990/
And I did find something interesting. The first four ROM access cycles looked fine. The CPU was accessing address 0, 2, 4, and 6 to get the stack pointer and ROM address to jump to, which is $0090002A. But after that, I noticed that the ROM OE (output enable) line would go very strange from there, a couple of very short ROM enable cycles (compared to the previous four cycles) and then no ROM access after that. I checked what was being read out of ROM in the first four ROM accesses, and they were fine.
It didn't feel like the CPU GLU chip was broken, as it was enabling the ROM OE correctly in the first four ROM access cycles. SWIM chip was not there so it couldn't be that. I checked all connections between ROM, RAM, CPU and CPU GLU and they were all fine. What could it be? Then, when I was staring at the logic analyser output, it occurred to me the issue coincided with ADDR23 being set high. It was supposed to be set high, since the next ROM access is at $0090002A, and the binary format of this number has ADDR23 set to high.
On the backlight model, there is a bodge wire going from CPU's ADDR23 pin to the backlight circuit. Out of ideas at this point, I desoldered that wire to see what would happen. I didn't expect anything to be different but to my amazement, it passed all tests and booted correctly! Why? I didn't understand.
I had to understand why that bodge wire was there and how the backlight circuit was designed. While there is non-backlight model schematic available, I couldn't find any schematic for the backlight circuit of the backlight model, so I started checking wiring on the board and drawing it myself.
The bodge wire was going to a NAND gate input (pin 5) along with SLOT_CS(0) line from CPU GLU (explained below) going to the other input at pin 4. The trace that I "fixed" was connecting these two input lines, so either ADDR23 or SLOT_CS(0) going high would set the NAND output to low. This in turn enables 74AC244. This webpage I found helped me understand what the backlight circuit was supposed to be doing. https://macintoshportable.info/M5126-9MB/
Then I realised that the "broken" trace was in fact a factory mod, along with the bodge wire. I was not supposed to bridge that.
The backlight circuit is made up of two parts, one part for letting Mac OS figure out whether it's running on a backlight model or non-backlight model; and the other part to set the backlight brightness. The first part (74AC00 pin 4,5,& 6; and 74AC244) puts the backlight identifier on the data bus, which is read by Mac OS and it would go "Ah, I am running on a backlight model, I'd better turn on the backlight and enable backlight brightness control panel". When a read happens at $FC0200, SLOT_CS(0) line is set to high by the CPU GLU chip. It looks like the original board design was to use only SLOT_CS(0) line for putting the backlight identifier on the data bus, because it was connected to both pin 4 and 5 of the NAND gate on the board (becoming a NOT gate). Setting SLOT_CS(0) high would set the NAND output to low, and this would enable 74AC244 to put 10100101 ($A5) onto D15-D8 data lines. But the problem was that SLOT_CS(0) was initially designed for the never-released Slim Cards (PC Card style memory cards, from what I understand), so any access to memory expansion address range $500000 - $8FFFFF would also cause the CPU GLU chip to set SLOT_CS(0) to high; this in turn would put 10100101 on the data bus and cause a bus conflict.
Apple's solution was to put backlight identifier on the data bus only when "both SLOT_CS(0) AND ADDR23 are high", which now required a cut trace and a bodge wire. That way, a read at $FC0200 works fine as before (since ADDR23 is set). Also read at memory space between $500000 and $7FFFFF would not cause backlight identifier to be put on the data bus, since ADDR23 is not set for those addresses. Only the memory access to $800000-$8FFFFF (1MB range) had to be sacrificed since ADDR23 is set to high for that. This is the reason why the backlight model's maximum memory is only 8MB, as opposed to 9MB of the non-backlight model. You can't access the last 1MB of expansion memory between $800000-$8FFFFF, as that would cause the backlight circuit to put the backlight identifier on the data bus while the expansion memory is also putting data there, causing a bus conflict.
So by bridging what I thought was a broken trace, I made the backlight identifier to be put on the data bus as soon as ADDR23 was set to high for ROM access, since SLOT_CS(0) was no longer needed to set the output of NAND gate to low; and inadvertently caused a bus conflict.
I undid my "fix" and everything is working fine now!
I washed it in soapy water, rinsed it in isopropyl alcohol by dipping it in for a while and recapped it. I rebuilt the battery with a new 6V one. I saw a trace on the back that looked to be broken from capacitor leakage so I fixed that, or so I thought. This was a mistake. More on this later.
With great hope, I assembled the machine and pressed the space bar. To my disappointment, nothing happened. I could hear a slight click in the speaker so I knew it was powering on. I checked the voltage regulator output and it was good at 5.2V. I checked the CPU clock, VCC and reset line and they were all fine, too. I checked the address and data bus and they all seem to be doing something. I read that sometimes the SWIM chip would go bad so I desoldered it but it made no difference.
So I used a cheap 8-ch logic analyser to look into what was going on. This post was very helpful in understanding what goes on at the power on time. https://tinkerdifferent.com/threads/fixing-a-macintosh-portable-what-worked-for-me.4990/
And I did find something interesting. The first four ROM access cycles looked fine. The CPU was accessing address 0, 2, 4, and 6 to get the stack pointer and ROM address to jump to, which is $0090002A. But after that, I noticed that the ROM OE (output enable) line would go very strange from there, a couple of very short ROM enable cycles (compared to the previous four cycles) and then no ROM access after that. I checked what was being read out of ROM in the first four ROM accesses, and they were fine.
It didn't feel like the CPU GLU chip was broken, as it was enabling the ROM OE correctly in the first four ROM access cycles. SWIM chip was not there so it couldn't be that. I checked all connections between ROM, RAM, CPU and CPU GLU and they were all fine. What could it be? Then, when I was staring at the logic analyser output, it occurred to me the issue coincided with ADDR23 being set high. It was supposed to be set high, since the next ROM access is at $0090002A, and the binary format of this number has ADDR23 set to high.
On the backlight model, there is a bodge wire going from CPU's ADDR23 pin to the backlight circuit. Out of ideas at this point, I desoldered that wire to see what would happen. I didn't expect anything to be different but to my amazement, it passed all tests and booted correctly! Why? I didn't understand.
I had to understand why that bodge wire was there and how the backlight circuit was designed. While there is non-backlight model schematic available, I couldn't find any schematic for the backlight circuit of the backlight model, so I started checking wiring on the board and drawing it myself.
The bodge wire was going to a NAND gate input (pin 5) along with SLOT_CS(0) line from CPU GLU (explained below) going to the other input at pin 4. The trace that I "fixed" was connecting these two input lines, so either ADDR23 or SLOT_CS(0) going high would set the NAND output to low. This in turn enables 74AC244. This webpage I found helped me understand what the backlight circuit was supposed to be doing. https://macintoshportable.info/M5126-9MB/
Then I realised that the "broken" trace was in fact a factory mod, along with the bodge wire. I was not supposed to bridge that.
The backlight circuit is made up of two parts, one part for letting Mac OS figure out whether it's running on a backlight model or non-backlight model; and the other part to set the backlight brightness. The first part (74AC00 pin 4,5,& 6; and 74AC244) puts the backlight identifier on the data bus, which is read by Mac OS and it would go "Ah, I am running on a backlight model, I'd better turn on the backlight and enable backlight brightness control panel". When a read happens at $FC0200, SLOT_CS(0) line is set to high by the CPU GLU chip. It looks like the original board design was to use only SLOT_CS(0) line for putting the backlight identifier on the data bus, because it was connected to both pin 4 and 5 of the NAND gate on the board (becoming a NOT gate). Setting SLOT_CS(0) high would set the NAND output to low, and this would enable 74AC244 to put 10100101 ($A5) onto D15-D8 data lines. But the problem was that SLOT_CS(0) was initially designed for the never-released Slim Cards (PC Card style memory cards, from what I understand), so any access to memory expansion address range $500000 - $8FFFFF would also cause the CPU GLU chip to set SLOT_CS(0) to high; this in turn would put 10100101 on the data bus and cause a bus conflict.
Apple's solution was to put backlight identifier on the data bus only when "both SLOT_CS(0) AND ADDR23 are high", which now required a cut trace and a bodge wire. That way, a read at $FC0200 works fine as before (since ADDR23 is set). Also read at memory space between $500000 and $7FFFFF would not cause backlight identifier to be put on the data bus, since ADDR23 is not set for those addresses. Only the memory access to $800000-$8FFFFF (1MB range) had to be sacrificed since ADDR23 is set to high for that. This is the reason why the backlight model's maximum memory is only 8MB, as opposed to 9MB of the non-backlight model. You can't access the last 1MB of expansion memory between $800000-$8FFFFF, as that would cause the backlight circuit to put the backlight identifier on the data bus while the expansion memory is also putting data there, causing a bus conflict.
So by bridging what I thought was a broken trace, I made the backlight identifier to be put on the data bus as soon as ADDR23 was set to high for ROM access, since SLOT_CS(0) was no longer needed to set the output of NAND gate to low; and inadvertently caused a bus conflict.
I undid my "fix" and everything is working fine now!
Last edited:
