Mac IIsi with no address or data bus activity. Strange signal on all ram data pins

[JohnR]

So I picked up another Mac IIsi (this brings the total to 3!) but I can't get it to work. I have it and another working IIsi sitting side by side on the bench and have been checking the signals on a scope and comparing between the two. Both have a good 20mhz clock signal at the cpu. The working system has activity on the data and address lines, the other system has none. The working system has activity on the ram data lines, whereas the other system has a strange low frequency signal on all 32 ram data lines. If I force the working system to crash (by bridging w1 briefly) all its data and address activity stops also, however it does not show the same low frequency signal on the ram data lines. I have tried a gglabs rom simm from my se30 that works fine in the working system but doesn't help the broken system. Ive beep tested all ram and rom pins. All oscillator signals seem correct. Anyone have any ideas what to test next? I'll happily test whatever is suggested and post my results!

John


-Strange low frequency signal on ram data lines-

-Good cpu clock signal input-

 

[David Cook]

That waveform suggests something other than the CPU has control of the bus, but is not outputting its signal. Check the reset pin of the CPU to make sure it isn't being held. Given where capacitor and power supply juice deposits on the IIsi, I'm going to guess that a trace related to the transceivers for the RAM is disconnected.

 

[JohnR]

Thanks for your reply David, on both boards the CPU reset pin 64 is approx 4.8v

pdf

 

[Melkhior]

on both boards the CPU reset pin 64 is approx 4.8v

Checl also /HALT, it will also prevent the CPU from doing anything if stuck low.

 

[JohnR]

Checl also /HALT, it will also prevent the CPU from doing anything if stuck low.

Thanks, I'll check that tomorrow

 

[JohnR]

Checl also /HALT, it will also prevent the CPU from doing anything if stuck low.

the HALT pin on both boards is testing around 5.0v

 

[Melkhior]

the HALT pin on both boards is testing around 5.0v

Then you will need to check what is really going on the bus, which is more complex. There's a couple of situations
(a) there's an ongoing transaction that is neither failing nor succeeding, so nobody is doing anything
(b) someone has the control of the bus (either the CPU or another bus master), but isn't doing anything with it, and nobody can do anything with it

for (a) you can check /AS, if low then something is going on, otherwise not - there's other signals from the CPU for ongoing transaction but they are less useful than /AS. /AS is bussed so it's the same everywhere. if /AS is low, then the A lines will tell you what is requested and therefore who is failing to respond. You might still need to check /BR, /BG and /BGACK to figure out who is requesting, it might not be the CPU, but at first it's less critical. Of course is /AS is alternating between high and low, there's actual 'traffic' going on.

for (b) you need to check the /BR, /BG and /BGACK in the system. I'm not sure how the IIsi is built and how the MDU handle the bus mastering request from the PDS slot, if there's just the one set of /BR, /BG and /BGACK (rather than some intermediate buffering and filtering), but if you see /BR active (so low) and /BG active (also low), then the CPU has relinquished the bus to some peripherals and waiting to get it back. If /BGACK is also low then the peripherals has taken over and doing nothing, otherwise something's really stuck.

 

[JohnR]

Thanks Melkhior, I've tested all those pins and here are my findings:

/AS is held at 5v on the faulty board, and has a pulse on the good board.
/BR is held at 5v on both boards.
/BG is held at 3.9v on faulty board, 3.8v on good board.
/BGACK is held at 5v on both boards.

so does that mean 'somethings really stuck'?

 

[Melkhior]

Thanks Melkhior, I've tested all those pins and here are my findings:
/AS is held at 5v on the faulty board, and has a pulse on the good board.
/BR is held at 5v on both boards.
/BG is held at 3.9v on faulty board, 3.8v on good board.
/BGACK is held at 5v on both boards.
so does that mean 'somethings really stuck'?

It means on the good board things are working (restating the obvious there ;-) ) but you did not observe bus mastering activity - which might very well be normal. Weak signal on /BG but if it works it's OK.

On the faulty board, nothing is happening on the bus. Which means the CPU isn't doing anything, despite not being in reset and not being halted... It could be faulty, it could be in a infinite loop, etc.

Thinking about it, you might want to check /IPL[0..2] (set of three) to the CPU, should be on the PDS also, as an interrupt issue could also prevent the CPU from doing anything. If they are all high (unasserted), then I don't see what external cause would stop the CPU from working.

 

[JohnR]

Ok so I've just been checking the /IPL pins on the cpu.

/IPL0 is constant 4.9v on the faulty board, and has a 6mhz (approx) pulse on the good board.
/IPL1 is constant 4.9v on both boards, as is /IPL2

if I force the good board to crash, its /IPL0 pin tests at a constant 0 volts, versus the faulty board's 4.9v

 

[Melkhior]

RTC and TBL interrupts (maybe others) running normally means some activity on /IPL. But nothing happening on the faulty one, so devices aren't running so presumably they weren't set up.

I've run out of ideas for external causes to the CPU. Seems like the CPU is faulty or trapped in a software problem fairly early on - did you look at the signals at power-on or just in steady-state? If there's an issue with the ROM <-> CPU connection (e.g. damaged traces) the CPU could have crashed or gone in an infinite loop with no bus activity before enabling any devices, but you seem to have beep-tested that...

You could look at the non-CPU signals from the MDU to the RAM to see if there's activity there explaining the data ram signals you observe. A fault in the MDU and/or to other devices would also make the system look pretty dead.

Also for the critical bus signals mentioned before - e.g. /AS, maybe check the resistance between them and the +5V line? A short to +5V on /AS or some other critical signals like /DSACK, /STERM, etc. would prevent the machine from doing much as well.

 

[JohnR]

You could look at the non-CPU signals from the MDU to the RAM to see if there's activity there explaining the data ram signals you observe.

So I made a small discovery.. and I feel a little silly..
The system is still broken but I found out what was causing the strange signal on the ram data lines. During testing I've had the monitor only plugged into the troublesome board, and no monitor plugged into the good board.. If I swap the monitor to the good board, the signal swaps too .. So I guess it's the onboard ram being used for the video system, which doesn't have activity when no monitor is plugged in.