Mac SE/30 Silent no start-up bong

[ironborn65]

I’m currently working on a heavily damaged Macintosh SE/30. The original post on the repair process can be found here: Salvaging bombed SE/30.

I've restored continuity in the address lines between the RAM multiplexer (MUX), ROM SIMM, VROM, and CPU, and verified the data lines from the ROM SIMM to both the VROM and CPU. The acid damage affected the area surrounding the RAM MUX and the RTC, which I have since replaced with an ATTiny85.

The caps were replaced but there were no signs of corrosion or leaks.
The board was washed, rinsed, soaked and rinsed in IPA.

After confirming that there were no shorts on the power rails or in the newly added bodges, I powered up the system using a verified working PSU extension cable. Sadly, the machine remains silent.

The RAM is populated with four 1MB SIMMs of 60ns RAM in the first bank. The ROM is the original, stock version, and continuity from the SIMM to the ROM chip on the PCB has been verified to avoid contact issues, even if the socket is the one with the metal clips. All major chips are warming up, indicating they are receiving power. Pressing the reset button triggers a faint “tick” from the speaker.

The +5V lines measure approximately 4.9V.

I observed that pin 1 (CK) on the UG7 clock generator shows a sinusoidal waveform at 14.7 MHz and around +2V, while I expected a square wave. Is this right?
Pins 2 through 8 display square waves as expected.

Could you advise on additional checks or diagnostic steps I should take?"

 

[slaanesh]

Check the -12V line from the analog board. I found that it wasn't making it passed the cable on mine. I cleaned up the plug area and reflowed the solder. It gets damaged if the nearby caps leak.
Also try using the external speaker socket to see if you get sound. If you do, then it looks like the mechanism inside is stuck.

 

[ironborn65]

"It seems that the clock signal from pin 1 of the UG7 PAL16R8B should be a square wave.

What could be causing this issue? A grounding issue maybe?
Could the testing from outside the case lacks a proper grounding? Should I also connect the ground of the board to the case? Even if don't see this wire in the videos from JDW

 

[ironborn65]

please help, I'm now clueless​

Current Observations:​

1. Power Supply:
   • +12V reaches the Sony chips. @slaanesh
   • +5V is present where expected.
   • The grounds are fine and show no shorts.
   • The chips warm up as expected.
2. Clock Signals:
   • Inspected the UG7 clock generator using an oscilloscope:
     • Signals on CNT0 to CNT6 display a proper square waveform, halving sequentially from CNT0 to CNT6.
     • The binary counter seems functional
     • A 2MHz clock is correctly generated be further processed for video purposes (C2M)
   • The C16M trace (16MHz signa I believel):
     • Observed as a sine wave on both the problem board and a functional SE/30 logic board.
     • Question: Is it normal for C16M to appear as a sine wave? Could this anomaly stem from the oscilloscope’s bandwidth or settings?
3. Board Condition:
   • Previous damage from a leaking Maxwell battery.
   • Electrolytic capacitors were replaced despite no visible leakage. Polarity was rechecked multiple times.
   • The speaker is connected, but the Mac remains silent at boot—no startup chime or death chime.
4. Configuration Details:
   • RAM installed in Bank 1.
   • Stock ROM and metal-pin ROM SIMM were installed correctly.

---

Questions and Next Steps:​

1. C16M Signal:
   • Is a sine wave output expected for the 16MHz signal on the SE/30 logic board, or is this an indication of a fault?
   • Could the observed sine wave result from the oscilloscope's limitations (e.g., insufficient bandwidth)?
2. Boot Silence:
   • Are there other components to recommend checking?
3. Further Diagnostics:
   • Would swapping out the clock generator (UG7) or testing with alternative compatible RAM/ROM modules help narrow down the issue?
   • Are there any known SE/30 board-specific quirks related to this scenario?
   • Can the RTC be involved?

 

[djc6]

I am troubleshooting an SE/30 logic board (normal boot chime but no video) and two comments that might be helpful:

• I noticed I get no startup chime via the speaker, but I do get startup chime via headphone jack. Have you tried headphones? I am using apple 3.5mm earbuds that came with an old iPhone.
  • In my case, the speaker tests fine. It seems related to issue with analog board - if I use a modern replacement of analog board, the speaker works.
• Check out this video from Adrian Black - there is a diagnostic mode via serial port you can try to see if the CPU is at least executing code:
  • I needed to use a null modem serial cable which I made (because I'm inpatient) using diagram halfway down this page: https://adtpro.com/connectionsserial.html
  • I had to use programmer's switch to get into debug mode because my board has normal boot chime but no video, but my programmer's switch was broken. Spraying some DeoxIT D5 into the switch fixed it.

 

[ironborn65]

@djc6 Thanks for your reply and the ideas you shared.

Yesterday, I finally got a sign of life from the speaker, so the headphones are no longer necessary.
As for the serial connection, it’s on my to-do list, but only after I’m certain the traces have been repaired. From there, I’ll focus on diagnosing the chips.
The journey has been incredibly long—it's astonishing how a small leak in one part of the board caused such widespread issues throughout

 

[ironborn65]

I have some good news—finally, it’s starting to show signs of life! However, there’s a behaviour that varies depending on the ROM image installed

It plays the chime of death, but the response differs based on the ROM:

• With the stock ROM, it displays a pattern on the screen.
• With the 32-bit clean ROM SIMM (BMOW Rominator II) the screen shows the usual pattern, I can even see the cursor, though it’s frozen

 

[cheesestraws]

Check out this video from Adrian Black - there is a diagnostic mode via serial port you can try to see if the CPU is at least executing code:

is that diagnostic mode the 'amazing discovery' mentioned in the thumbnail because seriously this is pretty well documented

 

[djc6]

I have some good news—finally, it’s starting to show signs of life! However, there’s a behaviour that varies depending on the ROM image installed

It plays the chime of death, but the response differs based on the ROM:

• With the stock ROM, it displays a pattern on the screen.
• With the 32-bit clean ROM SIMM (BMOW Rominator II) the screen shows the usual pattern, I can even see the cursor, though it’s frozen

I think the Rominator II skips the RAM test - because it would take forever if you have 64, 128MB installed. Is skipping RAM test related to different pattern on the screen?

 

[Callan]

is that diagnostic mode the 'amazing discovery' mentioned in the thumbnail because seriously, this is pretty well documented

Lol. I'm sure if someone banged their head against a wall a number of times when trying to fix an se/30, and then found out about the built-in diagnostics... it would be an amazing discovery. Saying that... I'm pretty sure that is click bait. Gotta get them views. Adrian is fun to watch. He has this 'everything's new' excitement to him, which is fun to watch. He's like a kid in a candy store (literally with all the Haribo he receives)

 

[ironborn65]

the pattern is not affected by the RAM size
AFAIK the video RAM is not in the RAM SIMM modules but is in the 41264 chips
the mouse pointer does not always appear, but if it does it's only with 4MBx1 RAM modules

The rominator II plays two sounds, the happy chime and then the sad Mac ... I believe
the custom one is just the sad Mac

BTW, the pattern I have with the stock ROM is exactly the one in Adrian's Video
but I can get the mouse and the standard grey pattern with the rominator II
it means that when skipping the RAM test it can initialize the video RAM, and I can even see the mouse, but when code is running and the RAM is loaded it freezes
also, if the mouse does not appear with RAM >4MB it means that maybe a higher RAM address line is faulty
I believe that with the stock ROM the RAM fails and the typical VRAM pattern is shown
does it make sense?
if it does I should focus on the RAM SIMM section, correct?

Is there a specific behaviour if a RAM MUX fails?

and ... do we know if the diagnostic code is the same for the stock and rominator II ?

 

[croissantking]

The rominator II plays two sounds, the happy chime and then the sad Mac ... I believe
the custom one is just the sad Mac

On your video with the Rominator II, I can only hear one sound and it’s the happy chime (which is a custom sound).

Are you sure the mouse is frozen and that there’s not something wrong with the ADB circuitry? Can you leave it running for a minute or two and see if the BMOW splash screen comes up?

With the Rominator fitted (not the stock ROM), can you try installing the 1MB SIMMs in Bank B instead of Bank A and see if there’s any change in behaviour?

 

[ironborn65]

I did some more tests

bank0	bank1	ROM	sound	screen
-	-	BMOW	happy	pattern
4MB	-	BMOW	happy or happy + death	pattern/cursor
-	4MB	BMOW	happy	pattern/cursor
16MB	-	BMOW	happy + death	pattern/cursor
-	16MB	BMOW	2 death sounds	pattern

the cases with the stock ROM is always the death of chime + pattern
the results with BMOM ROM with RAM in bank0 changes, sometimes pattern or initialized screen + cursor or just the initialized screen without the cursor
when resetting I always get the initialized screen

what I get is that there is something wrong with the RAM circuitry, if the test is skipped it proceeds initializing the VRAM, so the CPU can run code, the video circuitry is ok, VRAM can be initiated, and the VROM code is executed until it gets to a point where when the RAM is accessed, maybe when code is copied from the ROM, and it gets stuck. The diagnostic works because it's run from the ROM.
What is unclear is why the result is not deterministic, the result varies. Timing issue? Else..?

I'll triple-check the address lines RAAF RABF, the Data, the CAS and the RAMRWA/B traces. I don't know how to identify the issue with more details. Still a good improvement from a completely silent Mac.
I have been staring at the initialized grey screen with the cursor on the left, hoping for the miracle Mac face and the '?'

 

[croissantking]

I did some more tests

bank0	bank1	ROM	sound	screen
-	-	BMOW	happy	pattern
4MB	-	BMOW	happy or happy + death	pattern/cursor
-	4MB	BMOW	happy	pattern/cursor
16MB	-	BMOW	happy + death	pattern/cursor
-	16MB	BMOW	2 death sounds	pattern

the cases with the stock ROM is always the death of chime + pattern
the results with BMOM ROM with RAM in bank0 changes, sometimes pattern or initialized screen + cursor or just the initialized screen without the cursor
when resetting I always get the initialized screen

what I get is that there is something wrong with the RAM circuitry, if the test is skipped it proceeds initializing the VRAM, so the CPU can run code, the video circuitry is ok, VRAM can be initiated, and the VROM code is executed until it gets to a point where when the RAM is accessed, maybe when code is copied from the ROM, and it gets stuck. The diagnostic works because it's run from the ROM.
What is unclear is why the result is not deterministic, the result varies. Timing issue? Else..?

I'll triple-check the address lines RAAF RABF, the Data, the CAS and the RAMRWA/B traces. I don't know how to identify the issue with more details. Still a good improvement from a completely silent Mac.
I have been staring at the initialized grey screen with the cursor on the left, hoping for the miracle Mac face and the '?'

I would probably triple check everything in the RAM Mux area as that has been hit hard by battery acid.

 

[ironborn65]

I discovered that A9 and A8 are shorted. I initially noticed this issue, but it seemed to disappear, so I assumed it had been resolved after isolating some of the traces. I couldn't find the source of the short at the time, and since it was no longer present, I decided to proceed. However, the short has now reappeared.

To investigate further, I removed the MUX (UI2) to check for any shorts beneath it but found none. A8 runs directly under the ROM SIMM, while A9 travels slightly upward into a via. I cut the trace just before the via, but the short persisted. Frustrating!

I drilled a small hole in the via, and voilà—the short disappeared. Measurements on the ROM SIMM confirmed it was gone. I assume that some residual acid had deeped into the via, creating a short between A9 and the nearby A8 trace, which connects to the CPU. This is speculative, as I don't have access to the original PCB design.

After reinstalling the MUX, I added yet another bodge wire to connect A9 to the ROM SIMM. Thankfully, A8 was fine, and there were no further shorts at this stage.

I booted the system, but the situation worsened, silence, video pattern, and the diagnostic was not running. I realized that in drilling the via and reconnecting the MUX to the ROM SIMM, I had forgotten to address the trace leading to the CPU. To fix this, I added another bodge wire from the SIMM to the CPU.

And then I had the chime of death and the shorts reappeared. I confirmed this by removing the bodge wire from the CPU; the short vanished. #%$@!

This may mark the end of the project. I suspect the bridge is buried somewhere within the PCB, and I can't isolate the affected CPU pin. While I could remove the CPU, install a socket, and isolate the pin before adding a new bodge wire, the board is already in terrible shape. Moreover, I can't be certain this would finally revive it.

What puzzles me is that just the other day, the CPU was running the ROM code, indicating the short wasn’t present at the time. I can’t understand how a short can behave so unpredictably, almost like a ghost.

The Bolle's reloaded board could be the next thing to do... damn, I was so close.

 

[cheesestraws]

I can’t understand how a short can behave so unpredictably, almost like a ghost.

Is it something thermal / temperature dependent?

 

[ironborn65]

I can’t say for sure—it could be, but all the chips are gently warm.
In any case, I must locate the short; otherwise, this will be a dead end.
Since I’ll need to desolder the CPU for the reloaded board anyway, I might as well give it a try.
If the original PCB design were available, I could determine where A8 and A9 run close to each other.