Thread
Quadra 950 ... Mostly Dead
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.
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.
/so you jumnper J - 1 + 2 together and that enables diagnostic output over serial?
With:
Yep. Jump J1's 1 + 2 and it enables output over serial.
how nice of apple to make it so convenient. 
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.
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.
Yes the same test over and over gives different results:
I guess I should be checking all the connections to that chip before I go floating one off an old Centris board.
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
Yeah, with it varying on the MSB like that, I can't really think of anything else but the actual scsi controller for bus1. :/
screw the diagnostics, just fly by the seat of your pants and float a new one on that bad boy! :-D
either the IC is bad, or there is noise on the bus. And that can be EITHER side of the bus, internal system bus, or external bus.
but it sounds like the chip itself is bad, or the decoupling capacitor on that IC is bad.
but it sounds like the chip itself is bad, or the decoupling capacitor on that IC is bad.
The IC is fine - I swapped it with the same results. All of the capacitors are tantalum or ceramic (no electrolytics) and none look burnt.
It's times like this I wish I had schematics.
It's times like this I wish I had schematics.
it doesnt matter if it looks burnt or not. it can still be open ;-)
You have a bus problem. either one of the ASICs is bad, or the decoupling/termination on the bus interconnect is bad.
Look at the datasheet of the IC, from there you can find out what the address/data lines are. and see if they tie together between the two SCSI ICs (they should), and see if they tie to any other IC. the chip selection should be done by the chip enable which i wouldn't worry about that.
if your having failure from one IC, and not the other. measure the address/data connection between both, they should be in parallel and the chip/output enable selection lines should be the only thing that differentiate the two on the main bus.
You have a bus problem. either one of the ASICs is bad, or the decoupling/termination on the bus interconnect is bad.
Look at the datasheet of the IC, from there you can find out what the address/data lines are. and see if they tie together between the two SCSI ICs (they should), and see if they tie to any other IC. the chip selection should be done by the chip enable which i wouldn't worry about that.
if your having failure from one IC, and not the other. measure the address/data connection between both, they should be in parallel and the chip/output enable selection lines should be the only thing that differentiate the two on the main bus.
Does anyone know how to achieve this "diagnostic test" on a Quadra 840?
Also, is it possible to connect it to another old Mac with serial ports, like, say, a Beige G3 running OS X 10.1 (for Terminal), and do the tests without an adapter?
It looks quite interesting, and I hope it allows you to get the board working!
c
Also, is it possible to connect it to another old Mac with serial ports, like, say, a Beige G3 running OS X 10.1 (for Terminal), and do the tests without an adapter?
It looks quite interesting, and I hope it allows you to get the board working!
c
You could use zterm or any other terminal emulator you can read from the serial port on. I used Terminal because it was already there on my 10.6 MacBook. just remember to set it to 9600 baud, 8 bits, no party and 2 stop bits.
As bbraun said, check which is the PA0 pin of your VIA1 chip (mine was pin 2). Use a continuity tester to see if it goes to an edge connection on the logic board that you can send to ground. If not, you may try grounding it from the chip itself.
As bbraun said, check which is the PA0 pin of your VIA1 chip (mine was pin 2). Use a continuity tester to see if it goes to an edge connection on the logic board that you can send to ground. If not, you may try grounding it from the chip itself.
OK, so I can probably figure out where VIA1 is, but how do I determine its PA0 pin?
c
c
Look up the datasheet online.
I don't get continuity on the address or data lines between the chips themselves, only the Vss lines.
that woudl tell me that either they are buffered independantly (using 74 series logic, or an ASIC), or they are on completely separate databusses (i doubt it)
I'm traveling for a couple days, so I apologize for the infrequency of my posts.
The test is loading the loop count, then issuing a DMA NOP command to load the count and read it back. Since the DMA is a NOP, there should have been no bytes DMA'd, so the count should be the same. The DACK/ and/or ACKO/ lines of the 53C96 will decrement the count. These aren't 68040 signals, so I'm going to guess they go to the memory controller.
The part I'm still hung up on is it's supposedly the high byte of the 2 byte count. Since it increments by 5, and none of the expected values reported by the error code are multiples of 5, this makes some sense. At least it indicates to me I'm not confusing the LSB and MSB failure codes. The 0x03 test case is a FIFO reset error, and doesn't have the expected/actual value codes, so I don't think I'm off by one on the test code.
The count is also loaded 8bits at a time, so it shouldn't even be a problem with the higher data lines. It's using the same data lines to load both the high and low bytes.
So, if it is a DACK/ or ACKO/ signal problem, I'm at a loss as to why it seems to only be happening when the count gets fairly high.
The test is loading the loop count, then issuing a DMA NOP command to load the count and read it back. Since the DMA is a NOP, there should have been no bytes DMA'd, so the count should be the same. The DACK/ and/or ACKO/ lines of the 53C96 will decrement the count. These aren't 68040 signals, so I'm going to guess they go to the memory controller.
The part I'm still hung up on is it's supposedly the high byte of the 2 byte count. Since it increments by 5, and none of the expected values reported by the error code are multiples of 5, this makes some sense. At least it indicates to me I'm not confusing the LSB and MSB failure codes. The 0x03 test case is a FIFO reset error, and doesn't have the expected/actual value codes, so I don't think I'm off by one on the test code.
The count is also loaded 8bits at a time, so it shouldn't even be a problem with the higher data lines. It's using the same data lines to load both the high and low bytes.
So, if it is a DACK/ or ACKO/ signal problem, I'm at a loss as to why it seems to only be happening when the count gets fairly high.
maybe a bus controller? glu? DMA controller?
Here is your not so cheap, but easy way out:
http://www.ebay.com/itm/Vintage-Apple-System-Board-Macintosh-QUADRA-950-P-N-820-0331-/271231491962?pt=US_Vintage_Computers_Mainframes&hash=item3f26a81f7a
http://www.ebay.com/itm/Vintage-Apple-System-Board-Macintosh-QUADRA-950-P-N-820-0331-/271231491962?pt=US_Vintage_Computers_Mainframes&hash=item3f26a81f7a
Here's a cheaper one:
http://www.ebay.com/itm/Quadra-950-motherboard-/200946975310?pt=US_Vintage_Computing_Parts_Accessories&hash=item2ec95f824e
$36 with free shipping.
c
EDIT: Mistake: $36 BIN (not $38), $25 starting bid.
http://www.ebay.com/itm/Quadra-950-motherboard-/200946975310?pt=US_Vintage_Computing_Parts_Accessories&hash=item2ec95f824e
$36 with free shipping.
c
EDIT: Mistake: $36 BIN (not $38), $25 starting bid.
Thanks guys but macdrone has me covered for a backup plan.
Maybe so, but its nice to keep the options open JUST in case