Mac SE Restoration - Unable to access SCC chip error

[kris]

Hello fellow tinkerers!

Resurrecting a battery bombed SE, a tale as old as time. What I thought might be straight forward turned out, as often is the case, was't. That's why I’m coming to the experts

To make a long story somewhat short, I have an SE that suffered some battery damage, and after a long trudge of deep cleaning, replacing components, reflowing others, grinding oxidation from the ROMs, and bodging a few connections, I finally got a chime (or in this case, the beep) and a picture, but that’s about all I get.

The SE at least is attempting startup procedures now and I do get a mouse cursor, but never advances to looking for a boot device. When pressing the interrupt button, I get a sad Mac with the error $000D, which from some research, indicates an issue accessing the SCC chip. I was a little skeptical of that chip as it was, so I removed I and replaced it with a presumably good chip from a spare SE board. New chip, same result.

I then went poking around the Bomarc schematics for the serial controller and checking continuity and voltage everywhere that I could interpret. Everything appears to be connected properly from the select line, address bus, the data bus, connections to 26LS30, and MC3488, with all three chips reading proper voltages on the corresponding pins.

The only part of this that I'm not really confident in is this area of the circuitry:

Admittedly, I don’t understand this part but I did replace C4 capacitor and was to verify that the parallel pins on the filters did have continuity and verified ground.

At this point, I’m scratching my head for what else I can do. I feel like I’m just playing whack-a-mole if I were to swap more chips. Hopefully someone out there has come across this issue or can point me in the right direction.

I feel like the finish line is so close, but so far away. Any guidance this group can give would be much appreciated. Thanks!

 

[kris]

Hi All. Figure I'd provide a bit of an update in case there's anyone following along still.

After doing a bit more research, I'm now to believe that the error message previously stated was actually normal behavior when pressing the interrupt button.

I then turned to trying to trace back other connections and they all checked out: floppy controller, GLU, VIA, BBU, and Processor. All seemingly relevant connections had continuity: data and address lines, IWM select.

Below are some additional screenshots. Perhaps I'm missing something small but critical here. Unfortunately I don't have an oscilloscope to do any in-depth testing, but if there are any other suggestions, I'm open to them.

Screenshot of the initial boot progress. Mouse cursor appears, and functions when mouse is plugged in, but never moves past this state:

Sad mac code thrown then interrupt button is pressed:

 

[rikerjoe]

Out of curiosity, which version of MacOS are you using? I has a similar problem on my SE/30 when booting with any of the System 7 variants but booted fine under 6.0.8. This pointed to a serial line problem which I missed in my initial troubleshooting.

 

[kris]

Out of curiosity, which version of MacOS are you using? I has a similar problem on my SE/30 when booting with any of the System 7 variants but booted fine under 6.0.8. This pointed to a serial line problem which I missed in my initial troubleshooting.

On the test bench I use a bluescsi with a generic 7.1 install, and I've stuck a system 6.0.8 disk in the drive, but I don't even get to the point of seeking a boot device. For what its worth, the bluescsi does receive power and I do hear the floppy drive initial power up.

 

[Kai Robinson]

One issue you'll find in the SE is that if the SCC isn't playing nice, System 6 works fine. System 7 borks out as it checks the SCC for proper operation. Check the SCC is working correctly and you don't have any trace damage to any of the pins.

 

[kris]

One issue you'll find in the SE is that if the SCC isn't playing nice, System 6 works fine. System 7 borks out as it checks the SCC for proper operation. Check the SCC is working correctly and you don't have any trace damage to any of the pins.

Thanks @Kai Robinson, I have verified the connections from the the SCC chip, except for the pins 14/18 (CTSA), 22/26 (CTSB), 13 (RxDA), and 27 (RxDB). These pins appear to go to the area in the schematics from my first post that I don't quite understand. I even swapped in a new filter at U4B for good measure and no change in result. Could you help guide me on what should be expected for these four connections?

 

[kris]

Thanks @Kai Robinson, I have verified the connections from the the SCC chip, except for the pins 14/18 (CTSA), 22/26 (CTSB), 13 (RxDA), and 27 (RxDB). These pins appear to go to the area in the schematics from my first post that I don't quite understand. I even swapped in a new filter at U4B for good measure and no change in result. Could you help guide me on what should be expected for these four connections?

sorry, meant to add the other two. Pins 19 (DCDA) and 21 (DCDB) are also in the same area

 

[Kai Robinson]

Thanks @Kai Robinson, I have verified the connections from the the SCC chip, except for the pins 14/18 (CTSA), 22/26 (CTSB), 13 (RxDA), and 27 (RxDB). These pins appear to go to the area in the schematics from my first post that I don't quite understand. I even swapped in a new filter at U4B for good measure and no change in result. Could you help guide me on what should be expected for these four connections?

You can use the 'test' function in Sprint Layout, and the .lay6 file from the SE Reloaded GitHub here https://github.com/kr239/Macintosh-SE-Reloaded

to find out where each pin connects to, and to use as a guide to see if you're missing any connections.

 

[kris]

You can use the 'test' function in Sprint Layout, and the .lay6 file from the SE Reloaded GitHub here https://github.com/kr239/Macintosh-SE-Reloaded

to find out where each pin connects to, and to use as a guide to see if you're missing any connections.

Awesome, thanks @Kai Robinson, I'll check it out and report back with my findings.

 

[kris]

Awesome, thanks @Kai Robinson, I'll check it out and report back with my findings.

@Kai Robinson, Welp, it's not the SCC chip. Every single connection matched. While I'm here, might as well go and test the others. I suppose it could be anything at this point...

 

[Kai Robinson]

Yes, check the 26LS chips as well - not just the trace continuity but perhaps there's a failure somewhere. Did you check all the GND and VCC connections?

 

[kris]

Yes, check the 26LS chips as well - not just the trace continuity but perhaps there's a failure somewhere. Did you check all the GND and VCC connections?

Will do. Initially I only checked 26LS30 since I was going off the bomarc schematic and suspected the SCC chip. That one at least checked out ok and reading proper voltage as well. Without a scope my testing is somewhat limited. If there was a suspect component that didn't quite pass the eye test, I just outright replaced it (like the SCC chip, which in hindsight could have been fine...)

 

[kris]

Hi All,

Update time again. So since the last post, I went through everything to make absolutely sure that each component in the suspect areas were making the proper connections. After the latest round, the 26LS chips were good; surrounding chips like sound chip, also good. For sanity, I checked related items in the mix like ADB, VIA, ROMs, Floppy controller, all good and double and probably triple checked at this point..

Frustrated, I set the project aside for a bit, and during that time I happened to get another SE logic board that was having the exact same symptoms I'd been chasing with the project in this tread. So now there's two boards that are in the same state.

Not being fully convinced with the SCSI chip from my previous component musical chairs experiments, I decided to pull it from both boards, and out of curiosity, tested both boards with the chip removed. The end result was no change in result in that I got a chime, and then right to the raster screen and mouse cursor, and then nothing else. I was happy because I knew it was the SCSI controller at that point.

The final test was to drop in a known good SCSI chip. I cracked open a working SE that I have, de-soldered the SCSI chip and transplanted it to one of the sort of dead boards. I then powered it up, crossed my fingers, and.....success! It got past the initial raster screen and started seeking boot devices. After shutting it down and connecting a BlueSCSI, I was able to boot right into a System 7 image. My curiosity got me thinking again so I also tried putting one of the old SCSI chips back in the second board, and it was right back to the same behavior as it was when it was removed, so this was definitely something up with the SCSI controller.

As it stands right now, I'm waiting on new SCSI chips to fix both 'dead' boards for good, but we can effectively call this one case closed. It's been a bit of all over the place troubleshooting, but I wanted to document the experiments here because I don't think this behavior with the SCSI controller and result with the boot process is documented anywhere.

To recap: A Bad SCSI controller (or even absent entirely from the board) doesn't necessarily throw a boot error and certainly doesn't prevent you from getting a picture. You'll still get a chime, raster screen, and a mouse cursor, so check to make sure you have a working component (preferably with better tools than what I had ).

Anyways, I'll end it here. Thanks again for folks chiming in and reading along. Here's to more old Macs being resurrected!