SuperMac Spectrum/24 Series III Display Artifact Issue

[MacOSMonkey]

Good job. It could have been bad solder, debris or electrolytic corrosion. Unless you thoroughly clean the hole (and the pins -- to remove any oxidation/surface issues, there could be residual problems (and it might depend on the degree of via-trace dendrite invasion, etc.). If there is debris or corrosion at the trace end, then it might not matter how many times you solder it. If the traces were not resistive (perhaps implying little discontinuity or dendritic corrosion), then the heating impact may have been timing-related and adding a DIP socket may have added a very slight propagation delay (maybe ~30-40ps? -- it might not need much), plus an impedance and trace characteristic change -- possible reflections, reduced pin contact area -- maybe changed the signal propagation. You could scope a soldered vs. socketed part to see what the signals look like and if there is any significant difference. It could have also been something related to the package and wire bond connections. Using a DIP socket usually applies additional inward flex strain to the pins -- more than a PCB through-hole footprint would. Anyway -- glad it's working! And, it sounds like there is enough clearance for mounting the daughtercard with the DIP socket added -- so...great!

 

[croissantking]

I think the problem will come back soon

 

[Phipli]

Easily probed resistance for various traces, pins, etc, while the card was running, but did not find anything of consequence.

You don't want to be measuring resistance on something while it is powered, you might damage it or your meter, but will get weird readings regardless. Multimeters are not designed to measure resistance in powered circuits!

 

[jmacz]

You don't want to be measuring resistance on something while it is powered, you might damage it or your meter, but will get weird readings regardless. Multimeters are not designed to measure resistance in powered circuits!

Hmm, I'm actually not sure what I was writing there... I think I was trying to say more easily probed the voltage since the card was flat on my workbench, but I mentioned traces so maybe I meant to say "while the card was not running". Guess I was tired.. but no, did not test continuity nor the resistance while powered, only voltages.

I wish there was a permanent ability to edit posts here... kinda unfortunate that the edit option disappears after a little bit.

 

[jmacz]

And, it sounds like there is enough clearance for mounting the daughtercard with the DIP socket added -- so...great!

Yup, there was enough clearance luckily!

I think the problem will come back soon

LOL!

 

[jmacz]

I was able to get my hands on another Spectrum 24 Series III daughter card. This one actually did NOT have the labels on the ICs sanded off! Here it is for future reference.



10 of the 18 are Lattice GAL22V10s. 3 of the 18 look to be registers. And 3 of the 18 look to be SRAM. 2 of the 18 I can't tell as there are labels over them but are probably 2 more Lattice GAL22V10s.

I did try reading one of the Lattice GAL22V10s off my other daughter card (the one that had the issues) and unfortunately looks like the security fuse was set on it. It's returning high bits across the board. I think Bolle had a process to read these but probably beyond my skill level.

 

[MacOSMonkey]

Yep - GALs. That board was probably produced later after nobody cared about secrecy. You can compare the serial numbers to check. But, same hardware, later build.

 

[jmacz]

When I was mapping out the traces, I was completely confused by what I saw since the various chips were wired "differently". I had the wrong assumption that all of these were the same. This now explains a lot. Only 12 were GALs.

 

[MacOSMonkey]

Well...I told you they were GALs. Alas, I did my best. ^_^

 

[jmacz]

Well...I told you they were GALs. Alas, I did my best. ^_^

Yeah, and I did listen I just thought all 18 of the chips were GALs but looks like 6 of them are not, that was what I did not expect.

 

[MacOSMonkey]

No shame there - for either of us - hard to know anything about a 35-year-old de-identified build. But great that you now have a spare...and hopefully it works! You can retire the other one.

 

[jmacz]

No shame there - for either of us - hard to know anything about a 35-year-old de-identified build. But great that you now have a spare...and hopefully it works! You can retire the other one.

Haha, yes, the other one definitely works. But I was getting the urge to attempt to learn how to reverse engineer the GALs to be ready in case something else happens (knock on wood). But with the security fuse set, not sure if that's possible for me. Maybe someone with the proper skills.

 

[MacOSMonkey]

I don't think the reading trick is guaranteed -- but maybe Bolle could comment. .I think there's also a chance you might damage the part, whether or not it worked.

 

[Bolle]

I don't think the reading trick is guaranteed

Correct, especially not for 22V10s. I'd say it's still worth a try.
@jmacz want to send that board over so I can have a look?

 

[MacOSMonkey]

Send the bad one! But, if it worked, that would be pretty awesome!

 

[jmacz]

Ugh, well if I send one, it would have to be the good one. I went to put that problematic chip back into the dip socket and write the instructions down for repro this morning when I noticed acceleration was disabled. Tried reseating the chip but still no go. Then tried reading the chip again and now even the reader (t48 tl866-3g) is erroring while reading the chip. Either I did something wrong with the reader (it was just a default read - not sure what could go wrong - is there some tamper proof thing?) or the chip really was failing and it finally failed after all the mucking with it. I guess I have to decide whether to take a risk with the working one in order to restore the non working one.

 

[MacOSMonkey]

Yes - damage to the part is a possible outcome. Sorry to hear that happened. Maybe you should send the good one and only try to read that specific part. Then, if you can read it, program a new device, replace it into the old board and see if it works again. If so, then proceed using the old board with interim replacement tests after each device where the outcome will be a board populated with all new devices and the removed originals as spares. Good luck!

 

[Bolle]

Send them both and I’ll try to get as much as possible off the dead one and only touch the known working one when absolutely necessary.

It is possible that the T48 does something bad to the chip especially if it isn’t known if the part in question is actually a GAL and not a PALCE or other PAL variant. I figure the original board that’s been troublesome had them all sanded down?

 

[MacOSMonkey]

Yes - they are sanded on the original (probably earlier) board. But, now that I think of it, there is no guarantee that the original part is the same vendor as the newer-looking board with Lattice parts. I think the original design included National Semi (possibly PALs) that were then switched to Lattice GALs at a later date (probably cheaper). So, to the extent that it matters, you could see if there is a compatible NS profile...but still working in the dark.

Another way to go might be to match the known devices on the new board and not even bother trying to read the old ones with a generic profile. Then, if it works, just replace all the old ones with Lattice parts.

Since there is already 1 bad board, another good strategy would be to try to read a device OTHER than the failed one on the old board. If that one is damaged and not readable, then you would still have enough parts for 1 working board. This way might be the safest.

Also - one other detail -- the new one looks like the right board -- P/N#: 0006954 (so it is not a Calvin-ColorCard/24 accelerator). And it is 5540 boards after the older boards and 2 board revs later (G vs. E).

 

[jmacz]

It is possible that the T48 does something bad to the chip especially if it isn’t known if the part in question is actually a GAL and not a PALCE or other PAL variant.

Could be. The software allows you to select the device type and I had specifically selected GAL20v8 (I think that was the earliest guess as to what the chip could be -- now it looks more likely it's a GAL22v10). But how would a read damage a chip? I guess anything is possible? But note I did it read it 2 or 3 times without issue -- it's why I guessed the security fuse was set as all I was seeing is high bits in the dump. It was only a few days later after I tested the card again that I saw the accelerator was no longer detected, and then attempting to read the chip again gave me an error saying the chip wasn't readable.

I figure the original board that’s been troublesome had them all sanded down?

Yeah, the original board had all 18 chips sanded down and they all look basically the same.

Send them both and I’ll try to get as much as possible off the dead one and only touch the known working one when absolutely necessary.

Ok, I will consider that, if it's not too much trouble for you to take a look. I'm in the US so I'd have to take a look at shipping/customs costs to get these boards (daughtercards + mainboards for testing) to you in Europe and back. Need to figure out whether that cost is worth it for 1.) solving my curiosity and 2.) restoring the one daughtercard (I can still use the other card in non-accelerated mode).

FYI, I do have some other damage on the non-working daughterboard that I caused during experimentation putting it through all sorts of tests over the past 9 months. It's ugly but I patched them up best I could. None of that damage was causing the problems or new problems though.

I woke up this morning with an itch to do the following:

• Pull the working chip off the working board and slot it into the DIP socket I placed on the non-working board to confirm replacing that chip allows the non-working board to function properly. Just desoldering the chip, no biggie.
• Attempt to read the working chip to see if the ones on this new board don't have the security fuse set (given they were not sanded). But the issue with the other chip has totally spooked me and so I don't think I have the guts to try this.

Since there is already 1 bad board, another good strategy would be to try to read a device OTHER than the failed one on the old board. If that one is damaged and not readable, then you would still have enough parts for 1 working board. This way might be the safest.

Like I mentioned, so tempted to try and read one of the chips off the working board to see if those don't have the security bit set. That way I don't have to spend on shipping. Could reduce risk by trying this on a different chip (with the idea of harvesting that chip off the old board if I screw it up). But I probably shouldn't too spooked.