Recapped Mac II with NUBUS issue

[blturner]

I replaced the SMD electrolytics with tantalum caps on this Macintosh II board 820-0228-A. The board boots, and sound is good, but the video appears with a scrambled pattern. I can see the cursor move between the broken up columns. I'm using a known good Macintosh Display Card with correct DIP switch settings. I've tried booting with known good RAM SIMMs pulled from working earlier revision Mac II boards. I did find a broken trace from D5 to B1, I bodged that with some wire and ensured continuity. Nearby the broken trace, UC7 was the worst-looking chip on the board with highly visible corrosion. I removed it to clean it up and reinstalled but the issue persists. Looking around the NUCHIP, nothing looks visibly awry. I've checked more traces but I'm running up against the limit of my abilities.

Any suggestions on further troubleshooting would be appreciated!

 

[Hugotronics]

To me UC7 is bad, you'll need to replace it.

 

[DevyDevly]

I share your pain @blturner with a Macintosh II with similar problems (820-0228-A)
Occasionally I get an all grey screen and a reset (NMI) also gives me half a sad Mac.
After a recap I've gone cross-eyed trying to find broken traces but only the one found so far (even with lots of candidates).
Half a sad Mac led me to think one of the ROMs was bad, but they seem good as far as I've tested thus far.
If I had spare (A)LS651 chips I'd probably try swapping in some news ones but they seem to be as rare as hen's teeth (and stupid expensive), unless I'm missing something.

If I manage to solve I'll post back here.

BTW - I do feel great shame at my messy work environment but my defense it's a small house and all I have is the kitchen table.

 

[DevyDevly]

Sooo… turns out I had a broken trace (DSACK0 - data strobe acknowlege) from the NuChip (22) to the GLU (59). These data strobe signals seem to be quite important in getting NUBUS, SCSI, etc going - will definitely be a higher priority to check in future.
Took me a while to find but got there in the end - very happy now

 

[blturner]

Congrats on your success @DevyDevly!

I was working on my board last night, I ended up replacing every 74ALS651 with chips from a Mac II with working video and no change, so that doesn’t appear to be the root issue. I measured some of the replacement caps and noticed they were under voltage, some were 5V others were less than 1V. I guess I didn’t do a great job with those connections? I reflowed all the capacitors and re-measured and they all measure 5V now, with two (I think?) of the axials measuring 12V. After I reflowed the capacitors it did, for a second, have a slight change in behavior, there were no vertical bars and I could see the whole mouse. I didnt have a mouse attached so I couldn’t check how it looked if I moved it. The Missing Disk icon was still only partially showing. Unfortunately, after a reboot, it reverted to showing the vertical bars with missing video data.

I’ve also swapped the CPU, FPU, 68851 and all the ROM chips with the board that works just to rule any of those out.

 

[DevyDevly]

Congrats on your success @DevyDevly!

I was working on my board last night, I ended up replacing every 74ALS651 with chips from a Mac II with working video and no change, so that doesn’t appear to be the root issue. I measured some of the replacement caps and noticed they were under voltage, some were 5V others were less than 1V. I guess I didn’t do a great job with those connections? I reflowed all the capacitors and re-measured and they all measure 5V now, with two (I think?) of the axials measuring 12V. After I reflowed the capacitors it did, for a second, have a slight change in behavior, there were no vertical bars and I could see the whole mouse. I didnt have a mouse attached so I couldn’t check how it looked if I moved it. The Missing Disk icon was still only partially showing. Unfortunately, after a reboot, it reverted to showing the vertical bars with missing video data.

I’ve also swapped the CPU, FPU, 68851 and all the ROM chips with the board that works just to rule any of those out.

Thanks @blturner I'm quite chuffed.

If I had to bet on your issue I'd bet on another broken trace - to quote Wall Street Pros when reviewing a bad quarter "where there's one turd, there's many".
And trying to follow traces on the top side, under chips and slots, can be quite tricky. I found the Bomarc Mac II schematics very useful to identify what is going where (even though I'm still confused by parts of the schematics - but I'm not a Wizard either).

RE: Cap voltages. Remember those caps near the burn in edge connector are negative voltages, so measure the other side.

The two traces I fixed on my board were quite a long way from each other. But, my board is in quite bad shape so I'm surprised there was only two to fix.

I didn't mention that I had to stop using my 820-0198 video cards - I have two of them and neither would give me a prompt or good picture on my Dell 2405FPW monitor (or my other Samsung backup monitor). Either of those monitors (with 10pin adapter) handle my other vintage Macs and cards without issue (IIci, IIcx, Quada 700). But the 820-0198 just doesn't want to play nice.

Switching to a 820-0600 card helped sort my picture problems. I discovered this because I have a Rev A Macintosh II as well - it was an easy ROM fix but while fixing it I disovered the modern monitor/820-0198 issues.

Onto my next issue now... removing a LOT of rust from the internal frame and shielding.

GLUCK!

PS Here's what I started with... crimes were committed against this machine...

 

[blturner]

Some progress made. In a bout of frustration I started following some traces in other parts of the board I haven't scoured over yet. When I got to the barcode, I noticed it was covering the traces near C19 and it had some suspicious looking discoloring right near the edge of the label. I lifted it up and started scraping away at the mask and discovered two traces with hairline breaks. The label must have collected some of the electrolytic juice along it's border and made a clean cut, this was really not suspicious looking at all!

I was able to locate the related vias and ran some wire to connect them, the break was connected to pin 4 of the Apple Sound Chip. I booted the machine and for the first time got a completely clear video image!

My luck didn't last, unfotunately. When I came back to the machine later in the day, the bars were back, albeit, not as bad as before. This is the second time during this repair that the vertical bars have disappeared and returned after a reboot. I've been following the schematics as best I can and have been beeping everything out, especially related to data lines and address lines. Tonight I checked the rest of the pins on the ASC and SWIM chips but didn't find anything. The work continues, but the ASC pin repair seems to have restored more of the video data if you compare to the image from my first post.

 

[DevyDevly]

Gah - You’re so close!
Great find on those broken traces.
Maybe there’s just one other little wee bad connection - flexing or pushing on parts of the board might help you find it quickly.

 

[vtgearhead]

You may have a fractured or digested pin on one of the ICs.

 

[Melkhior]

If I had spare (A)LS651 chips I'd probably try swapping in some news ones but they seem to be as rare as hen's teeth (and stupid expensive), unless I'm missing something.

74ABT651 should be an adequate substitute, though they are faster and with stronger drive. They are still available as new from Mouser, but only in SOIC-24 package (I have no idea what package the 74ALS651 in the Mac II uses).

Sooo… turns out I had a broken trace (DSACK0 - data strobe acknowlege) from the NuChip (22) to the GLU (59). These data strobe signals seem to be quite important in getting NUBUS, SCSI, etc going - will definitely be a higher priority to check in future.

/DS is the Data Strobe, and is occasionally ignored (/AS, the Address Strobe, is the really mandatory one). Whatever master on the bus (but on a Mac, almost only the CPU) is doing the request use them to signal the data (resp. the address) is valid and ready.

/DSACK0 and /DSACK1 are used to signal that whatever was accessed has done the job (captured the CPU data for a write, and put the requested data on the bus for a read), and how much data is acknowledged (from byte to double-word, to support the 68k bus sizing feature). When they are broken, the CPU (or other master) doesn't know the transaction is complete, and either is stuck or is freed by some watchdog hardware signaling a bus error (via /BERR). So yes, they are very important.

 

[blturner]

You may have a fractured or digested pin on one of the ICs.

Yeah, the cap goo on C7 made me extremely suspicious of all the 74ALS651's, especially after @Hugotronics comment. I swapped all of them with chips from a board that I know has working video and I haven't found any broken traces between those chips and the NUCHIP, RAM SIMMs, etc.

It does seem likely there's a remaining broken trace somewhere as each of those carry 8 bits of data and when I began the video was showing only 8 bits correctly whereas now it's only missing 8 bits of data (if i'm interpreting this right). But it's been surprising that it occasionally has shown a perfect picture, maybe a dying chip elsewhere were the data passes through?

 

[DevyDevly]

74ABT651 should be an adequate substitute, though they are faster and with stronger drive. They are still available as new from Mouser, but only in SOIC-24 package (I have no idea what package the 74ALS651 in the Mac II uses).

/DS is the Data Strobe, and is occasionally ignored (/AS, the Address Strobe, is the really mandatory one). Whatever master on the bus (but on a Mac, almost only the CPU) is doing the request use them to signal the data (resp. the address) is valid and ready.

/DSACK0 and /DSACK1 are used to signal that whatever was accessed has done the job (captured the CPU data for a write, and put the requested data on the bus for a read), and how much data is acknowledged (from byte to double-word, to support the 68k bus sizing feature). When they are broken, the CPU (or other master) doesn't know the transaction is complete, and either is stuck or is freed by some watchdog hardware signaling a bus error (via /BERR). So yes, they are very important.

Many thanks for the info @Melkhior,
Saving has started saving for some 74ABT651 spares - Mouser has them, but not cheap.

I relatively new to the game so tend to focus of power, reset, address, and data lines. But thanks for helping me understand the importance of the DS and AS - another tool in the belt

 

[blturner]

After failing to find any further broken traces, I decided to soak the board in IPA yesterday for about 8 hours. There was starting to be a fair amount of flux residue left over so I wanted to rule out that a dirty board was exacerbating things. I let it dry over night and booted it this morning with (mostly) working video. The issue now is any highlighted text displays with some strange artifacts. This happens on the Desktop or any dialog window.

I ran Apple Personal Diagnostics which reported no issues. Snooper 2.0 seems to think there's a problem with the Bank A, SIMM 2 slots, though it's been inconsistent about which slot is the problem. I've also tried swapping in a different set of SIMMs, but it still gets angry about SIMM 2. I didn't find any continuity issues when I was testing the RAM slots, but I'll probably go over them again in case I missed something. It's also possible I just have bad RAM SIMMs?

When I've configured the RAM tests to try 20 patterns, I've gotten some interesting bombs (FPU tests pass, fwiw):

Getting closer, but still not there. We'll see if the video holds out this time!

 

[blturner]

Small update: I've been booting from a BlueSCSI V2 and I setup a new image with a minimal install of 7.1 to try out. There are no video artifacts afaict and Snooper has been running the 20 pattern RAM tests all afternoon with no errors. I'll have to try a full install of 7.1 and maybe a reinstall of 6.08 on a new image. Perhaps something was just messed up with the image I was booting from this morning.

 

[DevyDevly]

Wahooo! Sounds like you're home and hosed!
I'm not familiar with Snooper - I'll have to check it out.

 

[DevyDevly]

Oooh - I like Snooper, particularly how it shows the RAM test patterns and banks.
And the benchmark tests are nifty too.
And “BlueSCSI” is actually reported on the SCSI Bus Info.
Thanks for the tipoff