• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Quadra 950 ... Mostly Dead

bbraun

Well-known member
After the RAM tests come a series of other tests: SCC, VIAs, VRAM, Egret, PRAM, SCSI, and SONIC ethernet tests. Unfortunately it could be failing in any of these and there's not really a good way to differentiate.

On kind of a long shot, do you see anything on the Modem port if you connect at 9600 8n2?

There is a good chance the ROM knows what is failing, and can tell you over the Modem port, IF you can kick it into the right mode. There is a chance it's doing that automatically in this case. If not, the only way I know to force it into diagnostic mode is to ground the PA0 pin of VIA1. Unfortunately I don't have a 950 or even a high res picture of a logic board to help with that.

 

mcdermd

Well-known member
Very nice to know, bbraun. I'll have a look when I am back at it tomorrow. Just to be clear, I'd be putting a null modem cable between the 950 and my machine running terminal emulation. Set the connection to 9600 with 8 bits, no parity and TWO stop bits? I should see some sort of diagnostics sent over the serial cable?

Macdrone: thanks! I'll shoot you a PM

EDIT: Perfect - thanks for the tip, bbraun. I found your page outlining the diagnostic mode:

http://mac68k.info/wiki/display/mac68k/Diagnostic+Mode

 
Last edited by a moderator:

bbraun

Well-known member
Great, glad you found it. I'm pretty sure it's a null modem connection, and it's using 2 stop bits. A client set to 1 stop bit might still show most of it though.

 

uniserver

Well-known member
wow, the more i learn about these apple machines, the more i appreciate them.

i think that is a very nifty feature.

 

techknight

Well-known member
last ditch effort: hook a drive up that has its own termination power, and enable it along with its termination.

 

mcdermd

Well-known member
Well, Diag mode is interesting but without some sort of doc on the specifics, I'm not quite sure what to do with it. Here's what I did. Lines I typed are [in brackets]:

Code:
*APPLE*876543210000*
*APPLE*876543210000*
*APPLE*876543210000*
*APPLE*876543210000*
[*S]
*S
Version info:

Code:
[*V]
STM Version 2.1, Scott Smyers 
CTE Version 1.5.1 
ROM Version 7C 17F2
*V
Size Memory:

Code:
[*A]
*A
[*T000000010000]
*ERROR**T
[*R]
00FFFFD40000*R
Data Bus Test:

Code:
[*A]
*A
[*T000100010000]
*ERROR**T
[*R]
6E0708970000*R
Mod3 RAM Test:

Code:
[*A]
*A
[*T000200010000]
*ERROR**T
[*R]
FFF7BFFF0000*R
Address Line Test:

Code:
[*A]
*A
[*T000300010000]
*APPLE*00007FF40A00*
*APPLE*00007FF40A00*
*APPLE*00007FF40A00*
*APPLE*00007FF40A00*
[*S]
*S
ROM checksum:

Code:
[*A]
*A
[*T000400010000]
*T
[*R]
000000000000*R
RevMod3 RAM Test:

Code:
[*A]
*A
[*T000500010000]
*ERROR**T
[*R]
FFFFFFFB0000*R
Extra RAM Test:

Code:
[*A]
*A
[*T000600010000]
*ERROR**T
[*R]
080700160000*R
ModInv RAM Test:

Code:
[*A]
*A
[*T000700010000]
*APPLE*000025C40100*
*APPLE*000025C40100*
*APPLE*000025C40100*
*APPLE*000025C40100*
[*S]
*S
Size video RAM:

Code:
[*A]
*A
[*T000800010000]
*ERROR**T
[*R]
FFFFFFFF0000*R
 
Last edited by a moderator:

bbraun

Well-known member
Nice! Was the machine already in diagnostic mode, or did you have to do something to get it there?

Can you try to do the following:

*N008400010000

Then *R to get the return code.

This will run "non-critical" test 0x84 one time. I believe there are tests 0x84 through 0xA0 here, but some might be missing for specific machines. So if the above command seems to work, try running the other ones and seeing what happens.

 

mcdermd

Well-known member
I had to ground pin 2 of U44 (pin2 has a trace that runs to an edge connector J1 that conveniently has a ground point also).

photo-1.JPG

photo-2.JPG

I attached my MacBook to the Quadra 950's modem port with a Keyspan serial to USB adapter and used screen to access it via terminal

Code:
screen /dev/ttyUSB28x1d1P1.1 9800 8N2
photo.JPG

 

mcdermd

Well-known member
A lot of FFFFFFFF0000's and a few that came up with a "?" as a response

Code:
0x84 = 000000000000*R
0x85 = 000000000000*R
0x86 = 000000000000*R
0x87 = 000000000000*R
0x88 = *ERROR*  FFFFFFFF0000*R
0x89 = 000000000000*R
0x8A = *ERROR*  FFFFFFFF0000*R
0x8B = *ERROR*  FFFFFFFF0000*R
0x8C = *ERROR*  FFFFFFFF0000*R
0x8D = *ERROR*  FFFFFFFF0000*R
0x8E = *ERROR*  FFFFFFFF0000*R
0x8F = *ERROR*  FFFFFFFF0000*R
0x90 = *ERROR*  FFFFFFFF0000*R
0x91 = *ERROR*  FFFFFFFF0000*R
0x92 = *ERROR*  FFFFFFFF0000*R
0x93 = *ERROR*  FFFFFFFF0000*R
0x94 = 000000000000*R
0x95 = *ERROR*  00B080000000*R
0x96 = *ERROR* FFFFFFFF0000*R
0x97 = 000000000000*R
0x98 = *ERROR* FFFFFFFF0000*R
0x99 = *ERROR* FFFFFFFF0000*R
0x9A = *ERROR* 020004030000*R
0x9B = ?
0x9C = ?
0x9D = *ERROR* FFFFFFFF0000*R
0x9E = ?
0x9F = ?
0xA0 = ?
 

bbraun

Well-known member
Nice! I'm going through the code, there's no real documentation on this AFAIK, so it's a bit time consuming to decode.

Here's my analysis of the tests as I understand them so far:

0x84-0x86 are SCC tests.

0x87 is a VIA test

0x88 is a general SCSI test

0x89 is Sound

0x8A is PRAM

0x8B is RBV

0x8C is SWIM

0x8D is FPU

0x8E is PGC (parity generator)

0x8F-0x90 is FMC (fast memory controller)

0x91-92 is OSS

0x94 is Egret (aka adb and other stuff)

0x95 more sound

0x96 CLUT

0x97 VRAM

0x9A 53C96 SCSI chip

0x9B-0D is SONIC

The first 4 bytes, or 8 hex digits, represents the status code of the test, and the second 2 bytes or 4 hex digits represents the number of test loops remaining (if multiple loops are specified, the test may exit early if an error is encountered).

0xFFFFFFFF or -1 seems to indicate the test was skipped for some reason. For instance the RBV test gets skipped because the machine doesn't have RBV. The SCSI test may have been skipped because it has the newer SCSI chip covered in a different test. I'm not sure why the individual tests would be skipped at the moment.

So that leaves 0x95 and 0x9A as tests that ran and failed.

0x95 is a sound test. the 0xB there indicates it detected the chip correctly. The 0x8 indicates a problem with recording audio. Perhaps it wants a looped cable between audio out and in to perform the test. I'm not really sure. But I'm not entirely concerned about this one.

0x9A is the 53C96 SCSI chip, and sounds related to your problems. It looks like the SCSI test needs a terminator installed to work correctly. Could you try rerunning that one with a terminator installed on each of the 2 SCSI busses? If not, just testing and moving the terminator between the two, to see if the code changes might work.

 

mcdermd

Well-known member
With:

internal terminator on the ribbon and no drives attached to the primaryExternal CD ROM drive with terminator attached to the secondary 25-pin

020002010000*R
internal terminator on the ribbon and one drive attached to the primaryExternal CD ROM drive with terminator attached to the secondary 25-pin

020002030000*R
internal terminator on the ribbon and no drives attached to the primarynothing on the secondary

020003020000*R
nothing attached to the primaryribbon cable with internal terminator attached to secondary 50-pin

020002010000*R
nothing attached to the primaryExternal CD ROM drive with terminator attached to the secondary 25-pin

020004030000*R
 

bbraun

Well-known member
As best I can tell, the leading 0x02 indicates this was a problem with the high byte of the 53C96's transfer count register.

From the 53C96 datasheet, the transfer count register is for DMA operations where you specify the number of bytes in a DMA transfer. The test loops, starting at 0 and incrementing by 5 until it reaches the maximum value, 0xFFFF. It puts the incrementing value into the config register, issues a DMA NOP command which should load the count into the register for reading. It then reads back the value and compares it.

The 0x02 says the problem was with the high byte, and the bottom word contains the actual and expected values. So 020002010000 indicates the expected value was 2, and the actual read value was 1. Since the high byte is the one with the problem, and it wasn't expecting 0, that implies to me that it made it through the first 255 count without error, and only had problems when it started onto the high byte.

I don't believe this would have been affected by the terminator situation, so it's possible it's just giving random values and that's the problem. Could you try running the test a couple times in a row with the same terminator configuration (doesn't matter what it is so long as it remains the same for the tests)?

This also indicates the problem is encountered on the first of the two SCSI busses. The same failure on the 2nd SCSI bus should have produced the error 0x8200... Since the test terminates on error, it never tested the 2nd SCSI bus, so we don't really have any information one way or another on that one.

Conclusions are a bit hard to draw. The data sheet documents the conditions under which the transfer count gets decremented, and notes there could be spurious signals. But since it is apparently making it through the first byte of the counter without problems, that seems less likely to me. If it's not external signaling causing the counter to decrement, that probably means the chip is bad I think.

 

mcdermd

Well-known member
Yes the same test over and over gives different results:

Code:
*ERROR**N
020003020000*R
*ERROR**N
020003020000*R
*ERROR**N
020003020000*R
*ERROR**N
020004030000*R
*ERROR**N
020001000000*R
*ERROR**N
020001000000*R
*ERROR**N
020001000000*R
*ERROR**N
020002010000*R
*ERROR**N
020001000000*R
*ERROR**N
020004030000*R
I guess I should be checking all the connections to that chip before I go floating one off an old Centris board.

 

bbraun

Well-known member
Yeah, with it varying on the MSB like that, I can't really think of anything else but the actual scsi controller for bus1. :/

 
Top