SE/30 power-on self test

[cmjones01]

Hi,

I've been reading this forum with interest for a while before getting round to reviving an SE/30 that I was given last year. I finally had a go at it last week and have made some progress, but it's not happy yet.

Story so far:

The machine came to me unexpectedly with some other equipment. No keyboard or mouse but in good shape.

Inside I find no hard drive, and a clean motherboard with no Pram battery (yay!). The ROM SIMM was propped up with cocktail sticks, though. First power up got a very faint chimes of death and nothing on screen.

Working through with the schematic and a scope, I found a faulty 74393 in the video clock divider which meant there was no horizontal drive to the monitor. Fixing that got me working monitor but blank screen. Then the 74166 video shift register turned out to be faulty. Now I have action on the screen - a sort of rug pattern which looks like uninitialised memory to me. It's not the horizontal simasimac stripes.

I've replaced all the horrible surface mount electrolytics. That brought the chimes of death up to full volume. I gave the PCB a good wash and dry and gave all the SIMMs a cleaning with DeoxIT. Now the cocktail stick is not required.

I later found that two of the 74F258 RAM address multiplexers had stuck outputs, so I've replaced those. The outputs are no longer stuck but there's no change in the symptoms.

I could spend hours looking for broken traces and vias, but I prefer to go at these things systematically. Can anyone tell me what the tests performed before the chimes of death actually are? I'd like to figure out where it's failing. I'm fully equipped with logic analyser, scope and a whole vintage computing workshop.

The machine currently has no keyboard or mouse or floppy or hard drive connected. It should still start up and ask for a disc in that state, shouldn't it?

Thank you

Chris

Warsaw, Poland

 

[tjjq44]

Yes, no peripherals at all doesn't prevent the mac from booting to the "question mark"

Is your PSU in good shape? What output voltage do you read?

 

[techknight]

Slow chimes? RAM... Muxes are a known problem in these when it does that. they get damaged from using bad RAM, or mismatched RAM, or if the RAM was inserted/forced in backwards or ajar. You mentioned you found 2, you need to change them all. 

There is also a buffer IC and resistor pack that sits below the RAM sockets, right next to a leaky cap. check all those connections as sometimes when that cap leaks, it corrodes the traces between that IC and RAM sockets, or the RAM socket pins themselves = slow chime. 

Out of all Slow chime boards I had, I fixed 1, maybe 2. success isnt great as I never did find the ULTIMATE cause. Last thing I needed to look at was the little PAL (depending on what board revision) that sits below the main crystal, it generates the read/writing timing for the RAM. 

if the address/data bus was stuck in any way, you wouldnt get chimes at all. The fact that we get a chime, indicates the bus is good between the SWIM, ASC, SCC, SCSI, and VIA, as the traces run from the CPU through the VIA, the SWIM, then it gets tapped off from the bus path to the SCC/SCSI which sometimes break but it wont hold the bus. But it wont cause death chimes either unless the IRQ is held, and triggers an unimplemented or unexpected exception fault. 

To make sure you dont have any noisy ICs that could be flogging the bus, is to take the ROM out. and either use a logic analyzer or an oscilloscope and probe the databus. The CPU will walk the bus when RESET without the ROM inserted, so youll have a big 32 bit counter. Look for ringing or glitches. there should be none. 

 

[cmjones01]

Thank you for the tips. My power supply seems to be in good shape. The voltages are:

+5 +5.05V

+12 +12.7V

-5 -5.07V

-12 -11.7V

which seems plenty good enough given that there's no hard drive connected, so the load on +12V is going to be lower than it should be. There's no noticeable ripple or noise on any of the power supply rails.

I've just buzzed out the tracks from the RAM address multiplexers and buffer UD1 via their respective resistor packs to the SIMM slots, and it all checks out fine.

I'm going to try removing the ROM and seeing if I can observe the walking address. If that's OK, then I'll have to wade in with the soldering station and replace the other RAM address multiplexers, I guess.

Chris

 

[cmjones01]

OK, with the ROM removed, I do indeed get nice healthy counting on all the address lines. The only oddity is that as soon as A31 goes high, all the address lines go high and then stop counting. At the same time, the nROM line on pins 11/12 of the SIMM goes high, so I guess this is just an artefact of the address decoding and mapping.

I realised that the walking addresses also provide a great opportunity to look at what the 74F258 multiplexers were doing. While

the addresses are counting, nRCMUX is sitting high, which surprises me a bit - I'd have thought it should toggle during a bus cycle to get the addresses into the RAMs, but that's just a guess. Given that, all the mux outputs look fine, though the rise time from the 74F258s is a bit poor at nearly 30ns even on the shiny new ones.

My next move may be to remove L15 so I can drive nRCMUX manually and check that the muxes do the right thing in the opposite state, but I'm out of time for tonight.

Chris

 

[techknight]

That mux signal needs to switch when accessing certain addresses, because the bus sees a linear address, but RAM wants column/row addressing so the RCMUX control lines responsibility is to fetch the proper addresses. If this line isnt switching, i would start there... If it switches only on write, or both read/write I dont remember. 

But the bus walk is a read only state. never a write instruction is counted. The reason for the walk is the CPU is seeing a NOP on each fetch. 

Change the muxes because it can cause this line to stick in a state if its shorted. If that doesnt work, then I would take a look at the little tiny PAL right under the 31Mhz crystal oscillator. 

 

[cmjones01]

Progress! Thanks for the hint, techknight. Having checked that all the F258 muxes were doing the right thing with nRCMUX high, I removed L15 and grounded nRCMUX and powered up with no ROM inserted in order to test the muxes in the other state. Lo and behold, UI3 had one output stuck low. Swapped it out and...we have a desktop, a mouse pointer and a floppy disc question mark!

I think this is a good method of finding bad muxes: remove ROM SIMM, power up, check for activity at all mux outputs (pins 4, 7, 9 and 12) bearing in mind that some of them are at frequencies of <1Hz. Remove L15 from the bottom of the board (needs hot air, a talon or two irons because it's glued) and ground pin 1 of one of the muxes. Power up and check for activity at all mux outputs again.

I didn't have any more 74F258s so I used a 74HC258. It'll probably be OK, given the way logic has moved on in the last 30 years.

Now to conjure up a boot floppy and see if the drive works.

Chris

 

[techknight]

I think this is a good method of finding bad muxes: remove ROM SIMM, power up, check for activity at all mux outputs (pins 4, 7, 9 and 12) bearing in mind that some of them are at frequencies of <1Hz. Remove L15 from the bottom of the board (needs hot air, a talon or two irons because it's glued) and ground pin 1 of one of the muxes. Power up and check for activity at all mux outputs again.

Yep, thats what I have been doing over the last couple years or so. Not about the L15 but testing muxes. I change them all though, just because. 

But my luck streak its been about 1 of 3 boards this works on. 

Cause? Probably shit RAM someone tried to install in the past and fail.