Jump to content

Attempted revival of Simasimac SE/30

Recommended Posts

Hi all,

It has been a long time since I have been on the forum but happy to be back! Not so happy about the state of my attempted repair of a Simasimac SE/30.

I recently acquired an SE/30 with some issues from a local seller, it sounded to me at first like it was going to be a problem with the analog board but turned out to be a Simasimac situation. It's in the vertical stripes stage, not the full on horizontal bars. 

Checking out the board, while it appeared in pretty good shape, I saw evidence of leaking electrolytic around the caps. In the audio section of the board, some of the SMT chips had dull legs and a bit of a greenish crust. Fortunately no battery damage that I could see, and removed the battery. Tried to clean that area with first vinegar, then IPA, but did not see much of a difference afterward. 

Last night I attempted a recap, and I didn't do the greatest job on it. While trying to be very careful not to lift any pads, I ended up ripping the positive pad of C5, and about half of the ground pad of the 1uF cap, forget the number on that one. 

While hanging my head in shame, I tried to clean things up as much as possible, used a little white vinegar,  and then some IPA. Got the new caps on and I'd say they look ok. For the ripped pad, I made a wire connection to pin 15 of the Sony chip that trace connects to, and verified continuity. Checked continuity on all of the cap pins, and everything looked ok. They all had the right polarity at least.

After that, simasimac symptoms continued, no startup bong or anything else. From reading up on a few other threads I gather that the no bong means that the CPU is not finding the ROM, so next I will verify continuity directly from the chips on the ROM Simm (not the socket) to the CPU pins. This one is a socketed 68030, so I could either remove the CPU and test on the pin holes, or on the solder joints on the bottom of the board. 

Any other advice on what to look for at this point? I do have a scope and logic analyzer so after the continuity checks I can test in greater detail. Thanks for the help.

Link to post
Share on other sites

Well, good (?) news, I could not resist testing out some of the connections between the SIMM and the cpu until evening, and so far it appears that both A0 and A1 are not getting continuity between the appropriate pins on the SIMM socket and the CPU socket on the bottom of the board. Was easier to test between the sockets first so starting with that. At first I thought I just had the pins all wrong but then I saw that A2 and other address lines were in fact connected. So, maybe some actual faults here. Will map out the whole thing as soon as I get some more time to do so.

Link to post
Share on other sites
  • 68kMLA Supporter

A0 and A1 are not present at the ROM SIMM, so everything is correct there.

Still makes sense to check A2-A22 between ROM and CPU and see if one is missing.

Also check all the data lines and the chip select signal for the ROMs.


Another way to check if the CPU starts doing anything is to watch the address lines with your scope.

If no ROM is there at all the CPU will act as a 32bit counter and cycle through all possible address line combinations to look for code to execute.

If it doesn’t do this it either started to execute some ROM code but hangs really early in the code or your CPU is having issues.

Edited by Bolle
Link to post
Share on other sites

A bit more information - I tested all the address and data connections between the ROM socket (bottom board pins) and the CPU bottom board pins, and I got continuity on all of them. There was a momentary bit of excitement when I thought that D8 and D9 were not connected, but it turned out that the pinout of the 68030 I was looking out was incorrect. Unfortunately the top search result for that had some errors - there were 2 different D19 pins, no D17 pin, and D8 and D9 were reversed. 

I attempted to check the ROM_CS and ROM_OE pins as well. Looking at the schematic these were connected to pin 27 on UI8 (glue chip), so I tried to find that pin on the chip and realized I wasn't sure where pin 1 was. I checked the corners, found the pin connected to +5V, and then then counted to what I thought was pin 9, which should be connected to the NMI switch, and it was. So, kept counting to pin 27, and did not get continuity to pins 11 and 12 on the ROM Simm socket. But I am not very confident I was checking the right pin. If anyone can verify the numbering on UI8 I'll check again.

After that, I decided to remove the ROM Simm, powered up the Mac, and observed the address lines on the scope. There was definitely activity on each, and it appeared that with each increasing address pin the pulse width changed. So at first glance it did indeed look like the CPU was running and was counting up through address space. ROM_CS and ROM_OE were just at 0v, no activity. Not sure if that is typical or not.

That's as far as I've gotten so far, will poke around more later.

Link to post
Share on other sites

I eventually figured out which pin on the glue chip was connected to the ROM_CS and ROM_OE pins, and they had continuity.

Did a bit more testing, tried running the board both with and without the ROM Simm. 

Without the ROM, all address lines were pulsing, and did appear to be counting up through the full address space. ROM_CS and ROM_OE were at ground, no activity.

With the ROM, address lines had activity, and ROM_CS/ROM_OE had activity as well. 

So far no obvious broken traces or shorts that I could find. No more ideas for tonight, maybe more tomorrow. Any suggestions for things to test or look for are welcomed, thanks.

Link to post
Share on other sites

One other bit of information, 

I checked all of the address lines between the CPU and the UI8 glue chip, and got good continuity on all of them. Was kinda hoping I might find something there, as I happened to see another simasimac thread where one of those traces was bad. But, no luck this time.

Only other thing I can think of at the moment is to directly test continuity between  address/data/cs and the chips on the ROM SIMM itself, not the socket pins on the bottom of the board. May try that later today. Also can take a look at what's happening on the data lines during a run, since I haven't done that yet. Any other ideas?


While working on this I was wondering if anyone had made some sort of debug ROM Simm for the SE/30, maybe something that would watch the bus for the first few interactions on startup and then allow you to read back the results, or possibly output a specific pattern on the data lines to help detect shorts or disconnected pins, that kind of thing. Could be an interesting tool for mac repair.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...