DJ68K
Member
Disclaimer: I can read schematics but I’m not skilled in theory of operation. Therefore I spend way too much time toning out traces and not enough time reading data sheets and knowing how chips do what they do. I learn how things operate as I go. It’s decently entertaining, but not necessarily efficient and when the entertainment wears off, it’s a mix of frustration and spinning of wheels.
Forum member and friend KefkaFloyd came into town for VCFMW this year and brought along his once-working SE/30 logic board. When he got it a while ago, he’d cleaned up some cap goo and recapped it. During some of his troubleshooting after the recap he found it needed a single bodge wire. After upgrading the ROM to a 2mb module and the RAM with 4x16mb SIMMs, it was working fine for a while after. Trouble started when the computer began randomly losing video during use, never to come back until a power cycle. Sometimes the power cycle would bring it back, sometimes not. Over time, sometimes turned into never. Current state: No video, no chime, but fans and power were fine. He swapped the board into a working Mac SE and verified the problem traveled with the board.
I did a visual inspection and other than the new bodge wire everything looked mostly fine. Voltages all checked out okay on his board compared to mine, although his board’s 5v rail was a bit lower (4.92 vs 4.97 on mine). I attributed that to the massive amounts of RAM he was running, variants in the board’s construction, and a million other possibilities.
I looked through the schematics and found where the reset circuit was. I used my logic probe to verify the circuit worked: When releasing reset, the tone went low for a quarter of a second and then went high again. I verified reset worked from the sound chip, the glue chip, the FPU, and a few other places I could reach from the top of the board. The reset is generated from UB10. I also noted there was a separate “test” reset on UB11 that doesn’t wait the 0.25 seconds to go back high when releasing reset. This line goes only to the Glue Chip (UI8, labeled “test”) and doesn’t go to the other chips. Perhaps it’s something to note for another repair.
I then used the probe to scan a few address/data lines on the ROM SIMM and found there was absolutely zero activity on either address bus or data bus. I wasn’t sure what I should hear on the address bus but I knew the data bus should be doing something if the CPU was running. Data lines were at a constant state which means there's probably no CPU activity.
I looked over the board a bit more but admitted I don’t know enough about it and I’d ask some people at VCFMW for some advice.
Fast forward to that night after dinner. I told my buddy I wanted to take another crack at the board, and if I can’t fix it while he’s here, I’ll keep it if he’s okay with that and work on it when I have time. I reconnected the logic probe, verified we were where we were before, and continued on. I drew a simple map of the PAL layout and whether I was toning high or low. While investigating, UE7 had three no connect signals. I got excited because it might’ve indicated a broken trace. However, the schematics on those pins went nowhere which means they were probably supposed to be No Connects. Darn.
I swapped to my working board and retoned all the PALs (noting mine also had three NCs on that chip). I was able to confirm that pin 1 on many of the PALs was indeed a rhythmic high-low indicating a clock signal (C16M), which was my teaching moment on what the clock signal looks like/sounds like to the logic probe.
My next target was to find out why his board didn’t have the clock. I looked through the schematics and verified there’s no clock on anything: CPU, Glue, FPU, PALs, etc. Since the connections on UA8 through UG8 looked gnarly, I cleaned, fluxed, and reflowed all the pins thoroughly. It didn’t restore the clock, but now they’re very pretty. That’s something.
I located the clock generator on the board (chip UH7) and found a steady tone going out of pin 12, (C32M) and on both sides of resistor R28 on the underside of the board. I wasn’t sure how the clock signal was actually generated from the crystal itself (line C32G, pin 8), but when I measured it, I was getting nothing at all. WTF?
I looked around for the +5v signal again and realized there was no continuity from 5v to the VCC pin on the crystal. Eureka! On the underside of the board, I worked backwards until I found there was very intermittent continuity through one of the ferrite beads (L13) that separate 5v from the VCC pin on the crystal. Sure enough, even though it looked visually perfect, when I put my iron on one side of it to wick the solder away, the entire component stuck to the iron with the broken off end staying embedded in the solder.
I pulled a ferrite bead from my donor board, cleaned the pads, soldered it in place, hooked it up, and turned it on.
Boom: Good video, good boot, proper data bus activity, perfectly working clock. A ferrite bead on the underside of the board that the 5v rail goes through on its way to powering the crystal had cracked, causing an open line and no clock signal. While I was in there, I also removed, cleaned, and replaced the bodge wire with a shorter one that connected directly to a via.
How’d it break? My guess is the board was flexed enough times while plugging in the 14-pin connector that it cracked.
Takeaways for the future: Do the simple stuff first (check for power, check for reset, check for clock, check for data bus activity). Read the 680X0’s data sheet to get a working knowledge of what all the lines do so I have some idea of what to look for. Spend time probing working systems to know what a good state looks/sounds like. Even though I didn’t need it for this repair, I need to buy an oscilloscope and learn how to use it because some day it’s going to come in handy.
Reset worked, voltages were fine, but no data signal and no clock. Talked to a bunch of people at VCFMW, got some good ideas. Went home, retraced my steps. Mapped out the PLAs and compared to a known good board. Investigated where the clock is created and found the crystal wasn't even running. Checked for voltages and found an open circuit. A ferrite bead on the underside of the board that the 5v rail goes through on its way to powering the clock crystal had cracked, causing the open line and resulting in no clock signal. It was also just past midnight when I finished the project so some of these exact details are fuzzy.
Forum member and friend KefkaFloyd came into town for VCFMW this year and brought along his once-working SE/30 logic board. When he got it a while ago, he’d cleaned up some cap goo and recapped it. During some of his troubleshooting after the recap he found it needed a single bodge wire. After upgrading the ROM to a 2mb module and the RAM with 4x16mb SIMMs, it was working fine for a while after. Trouble started when the computer began randomly losing video during use, never to come back until a power cycle. Sometimes the power cycle would bring it back, sometimes not. Over time, sometimes turned into never. Current state: No video, no chime, but fans and power were fine. He swapped the board into a working Mac SE and verified the problem traveled with the board.
I did a visual inspection and other than the new bodge wire everything looked mostly fine. Voltages all checked out okay on his board compared to mine, although his board’s 5v rail was a bit lower (4.92 vs 4.97 on mine). I attributed that to the massive amounts of RAM he was running, variants in the board’s construction, and a million other possibilities.
I looked through the schematics and found where the reset circuit was. I used my logic probe to verify the circuit worked: When releasing reset, the tone went low for a quarter of a second and then went high again. I verified reset worked from the sound chip, the glue chip, the FPU, and a few other places I could reach from the top of the board. The reset is generated from UB10. I also noted there was a separate “test” reset on UB11 that doesn’t wait the 0.25 seconds to go back high when releasing reset. This line goes only to the Glue Chip (UI8, labeled “test”) and doesn’t go to the other chips. Perhaps it’s something to note for another repair.
I then used the probe to scan a few address/data lines on the ROM SIMM and found there was absolutely zero activity on either address bus or data bus. I wasn’t sure what I should hear on the address bus but I knew the data bus should be doing something if the CPU was running. Data lines were at a constant state which means there's probably no CPU activity.
I looked over the board a bit more but admitted I don’t know enough about it and I’d ask some people at VCFMW for some advice.
I talked to a bunch of great people at VCF but the guy I really wanted to see was Adrian Black. I popped by the small silver table for a few minutes while he was talking to a couple of people and he actually waved me over. I re-introduced myself from last year, and mentioned I was the guy who used one of his videos to identify the reset circuit problem in a Mac Classic I’d been struggling with for a few months prior. I don’t think he remembered the conversation but when you have thousands of conversations with random people every year, I’m certain I wouldn’t remember me.
I inquired about “theory of operation” and “theory of repair,” asking how he performs each of his repairs based on the symptoms he's seeing, and wanted to know the basic “must check” things that apply to every single initial board investigation. Y'know, easy things, low hanging fruit. I mentioned that I verified the reset circuit is working properly but that I had no data or address activity. Because the 68030 is a very complicated chip with interrupts, DMA, and all sorts of other features, Adrian suggested I pore over the 68030’s data sheet to learn what all the various extra signal lines do and how they work, and that I really should get myself an oscilloscope. I admitted that an oscilloscope would be an essential addition to my toolkit. He, and another gentleman standing there at the table (Matt, I think?) also suggested looking for the clock generation circuit and making sure that’s all buttoned up. Both also suggested speaking to someone from Amiga of Rochester, who was doing live board repairs at his booth.
Near the end of the show, my buddy with the board was already talking to the people at AoR’s booth when I got over to it. I listened in on what was being said, added my two cents on what I saw, and Tom, who was working on a Mac Plus at the time, suggested a bunch of steps and checks that, frankly, went in one ear and out the other. I was amazed that he was giving me individual pins from memory to check on a bunch of the chips. Pin 1 on the PALs was the clock signal, for example, and there’s multiple clocks to know about. My takeaway was to do a thorough visual inspection, tone out any traces that might look suspect in areas of corrosion, and check for reset, clock, data activity, verify activity going to the PALs, and a lot of other things that I don’t necessarily remember.
I inquired about “theory of operation” and “theory of repair,” asking how he performs each of his repairs based on the symptoms he's seeing, and wanted to know the basic “must check” things that apply to every single initial board investigation. Y'know, easy things, low hanging fruit. I mentioned that I verified the reset circuit is working properly but that I had no data or address activity. Because the 68030 is a very complicated chip with interrupts, DMA, and all sorts of other features, Adrian suggested I pore over the 68030’s data sheet to learn what all the various extra signal lines do and how they work, and that I really should get myself an oscilloscope. I admitted that an oscilloscope would be an essential addition to my toolkit. He, and another gentleman standing there at the table (Matt, I think?) also suggested looking for the clock generation circuit and making sure that’s all buttoned up. Both also suggested speaking to someone from Amiga of Rochester, who was doing live board repairs at his booth.
Near the end of the show, my buddy with the board was already talking to the people at AoR’s booth when I got over to it. I listened in on what was being said, added my two cents on what I saw, and Tom, who was working on a Mac Plus at the time, suggested a bunch of steps and checks that, frankly, went in one ear and out the other. I was amazed that he was giving me individual pins from memory to check on a bunch of the chips. Pin 1 on the PALs was the clock signal, for example, and there’s multiple clocks to know about. My takeaway was to do a thorough visual inspection, tone out any traces that might look suspect in areas of corrosion, and check for reset, clock, data activity, verify activity going to the PALs, and a lot of other things that I don’t necessarily remember.
Fast forward to that night after dinner. I told my buddy I wanted to take another crack at the board, and if I can’t fix it while he’s here, I’ll keep it if he’s okay with that and work on it when I have time. I reconnected the logic probe, verified we were where we were before, and continued on. I drew a simple map of the PAL layout and whether I was toning high or low. While investigating, UE7 had three no connect signals. I got excited because it might’ve indicated a broken trace. However, the schematics on those pins went nowhere which means they were probably supposed to be No Connects. Darn.
I swapped to my working board and retoned all the PALs (noting mine also had three NCs on that chip). I was able to confirm that pin 1 on many of the PALs was indeed a rhythmic high-low indicating a clock signal (C16M), which was my teaching moment on what the clock signal looks like/sounds like to the logic probe.
My next target was to find out why his board didn’t have the clock. I looked through the schematics and verified there’s no clock on anything: CPU, Glue, FPU, PALs, etc. Since the connections on UA8 through UG8 looked gnarly, I cleaned, fluxed, and reflowed all the pins thoroughly. It didn’t restore the clock, but now they’re very pretty. That’s something.
I located the clock generator on the board (chip UH7) and found a steady tone going out of pin 12, (C32M) and on both sides of resistor R28 on the underside of the board. I wasn’t sure how the clock signal was actually generated from the crystal itself (line C32G, pin 8), but when I measured it, I was getting nothing at all. WTF?
I looked around for the +5v signal again and realized there was no continuity from 5v to the VCC pin on the crystal. Eureka! On the underside of the board, I worked backwards until I found there was very intermittent continuity through one of the ferrite beads (L13) that separate 5v from the VCC pin on the crystal. Sure enough, even though it looked visually perfect, when I put my iron on one side of it to wick the solder away, the entire component stuck to the iron with the broken off end staying embedded in the solder.
I pulled a ferrite bead from my donor board, cleaned the pads, soldered it in place, hooked it up, and turned it on.
Boom: Good video, good boot, proper data bus activity, perfectly working clock. A ferrite bead on the underside of the board that the 5v rail goes through on its way to powering the crystal had cracked, causing an open line and no clock signal. While I was in there, I also removed, cleaned, and replaced the bodge wire with a shorter one that connected directly to a via.
How’d it break? My guess is the board was flexed enough times while plugging in the 14-pin connector that it cracked.
Takeaways for the future: Do the simple stuff first (check for power, check for reset, check for clock, check for data bus activity). Read the 680X0’s data sheet to get a working knowledge of what all the lines do so I have some idea of what to look for. Spend time probing working systems to know what a good state looks/sounds like. Even though I didn’t need it for this repair, I need to buy an oscilloscope and learn how to use it because some day it’s going to come in handy.
