SE/30 with Micron Xceed Grayscale & Socketed Daystar Acceler

[JDW]

Well, I fixed the PCB trace that had been rated by leaked fluid (in the vicinity of the battery). Unfortunately, I get the same exact response -- horizontal lines and a sad Mac chime, both exactly as they were before (and as they appear and sound in my video). So obviously, this is not the only broken trace and/or there could be a bad chip on the board.

I spent a lot of time last night checking points with the aid of my schematic. I checked all the pins on UK6 (video ROM), D0-31 (Data pins) leading from the ROM to the RAM SIMMs and to D4 - D19, I reverified that pin 45 of the ROM (Address A22) properly connected to all the points I could find on my schematics (proving my fix was good). So far, I've not found anything else bad, but there are hundreds of other places that would need to be checked, and even then one cannot know if a chip is bad. Further, I am still concerned about resurrecting vias in light of this being a multi-layered board. I could easily spend another 5-10 hours checking points and still may not come up with a remedy. I just don't have 5-10 hours or the desire to commit so much time. I will keep testing the board when I have spare time, as I am not to not sleep well at night until a problem is solved. But I must admit I am rather frustrated with this board.

Had I another socketed board, I would be content with just putting this board out of its misery. But I wanted to test the Daystar accelerator in another socketed motherboard to see if that resolved the lock-up problem I had with it. I did test the CPU of the Daystar accelerator last night. I pulled the 68030 chip from the Daystar board and put it into my known-good socketed SE/30 logic board, then I fired up the machine and ran Norton System Info (benchmark utility), followed by running extensive Norton Disk Utility tests on my 4.5GB hard drive's 3 partitions -- all of which put a good deal of stress on RAM, CPU and Disk. I left the machine on all last night (with screen brightness turned down to avoid burn-in), and the machine never locked up once. I then used it a little while this morning and it worked fine. So the CPU of the Daystar upgrade is not the reason why that upgrade is locking up. That's a fact.

 

[JDW]

After spending some additional hours testing and finding nothing wrong, I then came across something new. J12 is the main connector on the motherboard, which pulls power from the analog board. Within J12, pins 12 and 13 are connected together (as per my schematics) and route +5v throughout the logic board. The problem part is that when touching my DMM in Continuity Check mode between pins 12 or 13 and Ground, I get a short. So the +5v line is being shorted to ground somewhere on the board. The problem is, where?

I checked the polarity of all my replacement caps. They are facing the right way. They were all brand new caps (well, new when I bought them from Trag a few years ago), so I doubt they are bad. So now I need to find the short.

For good measure I put my DMM across pin 12 and Ground on a known-good logic board. It does not short to ground. So that proves that this short on my other board is indeed a problem short that needs to be fixed.

Interestingly, despite the +5v line being shorted to Ground, I get the horizontal lines and chimes of death at startup. I would think that with a short on the logic board, I certainly should not get any sound. Yet, the sound works fine, and is quite loud too.

Thoughts?

 

[trag]

Interestingly, despite the +5v line being shorted to Ground, I get the horizontal lines and chimes of death at startup. I would think that with a short on the logic board, I certainly should not get any sound. Yet, the sound works fine, and is quite loud too.

Thoughts?

It does seem like with a short that you should not be getting anything from the logic board.

Are you using a continuity meter or an ohmmeter for the testing?

If the former, try setting your DMM to ohmmeter and measure the actual resistance between the connector pins. Use the most sensitive setting which gives you a useful reading.

Do the same thing across each of the bypass capacitors. As you get closer to the short, the resistance should fall -- although that effect could be overwhelmed by simple differences in how well the probes make contact with the various test points.

I would also check across the battery holder pins. There's a lot of space under the battery holder for problems.

Do you have access to an adjustable power supply? If so, adjust it to 5V. Turn it off, connect it to the GND and 5V pins on the logic board and turn it on. How much current does it report? Try increasing the voltage a few tens of millivolts. Does the voltage increase or is too much current drawn from the supply?

Alternatively, or in addition to the above, connect the logic board outside of its frame so you have access to all of it. Power the machine up normally. Run your fingers just above the board looking for a hot sport. Touch each chip and capacitor and see if any of them are particularly warm.

Finding a short is a pain. If it was a dead short, you could try the old trick of running the voltage up until the short burns out. However, you seem to have a rather resistive short, since the machine is still getting enough voltage to kind of boot up. So the old over-voltage trick would probably fry the components on the logic board.

 

[JDW]

Thanks for the advice, Trag.

My Digital Multimeter (DMM) can measure Volts, Amps, Ohms, and also check diodes and continuity. When in Continuity/Diode check mode, the DMM beeps at me when both probes are touched together or when I touch each probe at the end of a single wire (i.e., when I get a short). It also gives me a number on the LCD when in Continuity check mode, which shows resistivity. It beeps at me when that number is about 20 or less.

I just tested the board with the DMM set to measure resistance (Ohms). And during my test I saw the resistance between Pins 12/13 (+5v) and Ground slowly increase to about 34.9-ohms. After it increased beyond 20-ohms, I switched back to Continuity check mode and put the probes across pins 12/13 (+5v) and Pin 1 (Ground), and the DMM would not longer beep at me (obviously, because resistance had increased so much it was no longer a dead short).

But if the resistance slowly increased, that would indicate a capacitor at the heart of this problem, would it not?

I also put my DMM probes across a 10k-ohm resistor, set the DMM to read voltage, and then I put the resistor across Pins 12/13 (+5v) and Pin 1 (Ground). I didn't see anything on the DMM screen, but when I put the DMM back into Continuity check mode and then put the probes directly across Pin 12/13 (+5v) and Pin 1 (Ground), it was back to beeping at me again (showing me signs of a short). And this test too would indicate a capacitor problem, with the 10k resistor having discharged the capacitance.

Thoughts?

 

[JDW]

When putting a 3A capable 5v power supply across Pin 12 (+5v) and Pin 1 (Ground), the voltage drops to 4.83v and the current is 1.51A. Checking the same power supply when no load is applied shows 5.01v on my DMM (i.e., the voltage drops from 5.01v to 4.83v when I connect the power supply to the SE/30 logic board).

I left the power supply connected and powered ON for three minutes. During that time, 5 chips got warm, all of them the PALs: UI6, UG6, UG7, UE6 & UE7. I physically touched all the chips and capacitors with my fingers. Not even the CPU got warm. Only those 5 socketed PAL chips. I would classify it has "hot" but not so burning hot I could not keep my fingers on the PALs.

After removing power and waiting about 3 minutes, I put my DMM in Continuity Check mode across Pin 12 (+5v) and Pin 1 (Ground). This time it did not beep at me. I then switched to check resistance on my DMM and measured 43.9-ohms across those same pins. But while keeping my eye on the DMM's LCD, I could see the resistance value slowing going down. I then removed all 5 PALs from their sockets, checking the resistance as I pulled each one. The resistance continued to drop at the same pace, unaffected by my removal of the PALs.

Each of the PALs were correctly socketed. I know this based on the Apple part numbers on the chips in comparison to what is written on my schematics. I also know how they were installed the first time I looked at the board, before I ever pulled the chips to clean the board.

After all this, I reconnected my power supply again, this time using 4 alligator-clip jumper wires instead the 2 that I used before. I was thinking that two wires alone may be limiting the current a bit. So I connected Pins 1 and 4 (both board Ground) to my PSU Ground, and I connected Pins 12 and 13 (both board +5v) to my PSU's Positive line, then put my DMM on to check voltage. This time I read 4.90v at 1.56A. I then slowly increased the voltage on my PSU. I saw a proportional increase in voltage on my DMM and the current increased too. And as before, the PALs got warm, but nothing else.

I would appreciate hearing your thoughts in light of this.

Thank you.

 

[trag]

PALs get hot. I was surprised by this when I learned it. I was fiddling with a GAL from an Outbound Floppy Controller board and thought something was wrong with it because it got so hot. But back in the circuit it worked fine. And info requested on sci.electronics.repair resulted in folks saying that PALs get hot.

So, I suspect that warm/hot PALs is not a problem.

Which doesn't help with finding your short problem.

Capacitors in a circuit, especially bypass capacitors, will look like a short until the capacitors charge. That's because the caps are a place for current to flow into while the caps are charging. A DMM does not supply much current, so it takes a noticeable amount of time for them to charge. So I do not think that your slowly increasing resistance is a suggestion of a capacitor problem. Doesn't mean it isn't, though.

One of the results you had where the resistance was still about 35 ohms when you checked it again, probably just means that the caps charged up during the first measurement and hadn't discharged before the second test.

The question is, is ~35 - 40 ohms the proper resistance for your board with all the current paths on it?

At this point, I would get out a working SE/30 board, preferably also one you have recapped. And take the same measurements on it as you have taken on this one. In other words, is its static resistance about 40 ohms from 5V to GND. Does it draw about 1.5 amps when supplied with 5V. Etc.

 

[JDW]

Trag, thanks for the info and advice.

I tested my known-good socketed motherboard, using the same known-good RAM SIMMs as I used on the bad board. My known-good board was also recapped in exactly the same way and with exactly the same replacement caps (your kit of SMD tantalums and axials). I used two alligator-clip jumper wires on this board as I did in my final test on the bad board. I tested my power supply with a DMM before I connected it, and it measured 5.00v. When I connected the 4 jumpers and then switched the power supply on again (on my known-good board), I measured: 4.88v @ 1.41A. That reading is a tad lower than the reading I got on my bad board, but it is not substantial difference. The two motherboards are different revisions though, with the location of C12 being a little different, so perhaps that also contributes to the slight difference in voltage and current.

I also noted this time that, in addition to the PALs, the following components also got noticeably warm to the touch:

Y2 (OSC)

UH7

UG12

They might have also gotten warm on my bad board too -- I don't remember.

I also tested the resistance between Pin12 (+5v) and Pin1 (Ground) very quickly after I turned off my power supply. For a brief instant I measured 100-ohms. But I could see on the DMM's LCD that the resistance dropped rather quickly down after that. It took only a few seconds to go down to 63-ohms. I then removed all the jumpers and my DMM, and began typing this post for a few minutes. Then when I tested resistance again, it was down to about 28-ohms and dropping.

Before I did any of these tests on my known-good board, I put my DMM in Continuity Check mode and put the probes between Pin12 (+5v) and board Ground. It immediately beeped at me, indicating a dead short, just as it did with my bad board. So this confirms that the bypass caps show a dead short to my DMM when it is set to Continuity mode (when the caps are fully discharged).

My next test will be to remove the PALs from the known-good board and put them in the bad board to see if that resolves the problem. Hopefully, the problem with my bad board is not so such that it will fry my known-good PAL chips. If that test fails, I will then put the PALs back in the good board and test it to confirm the PALs are still good. I will then continue the painful process of checking every via and every pin, in accordance to my schematics. But I must say this is not an enjoyable process in light of the time it takes.

 

[bigmessowires]

I reviewed this thread from the beginning, and was reminded that it actually makes the startup sound "bong" when powered on. That means it's actually running and getting at least part-way into the boot sequence code in ROM. Have you tried actually booting the machine, inserting a floppy? If it is purely a video problem, then maybe the computer itself is working fine. I'm not sure what that would prove, but might help narrow down the problem.

 

[JDW]

it actually makes the startup sound "bong" when powered on.

No it doesn't make a "bong." As a part of my video, you can clearly hear that it only makes the "chimes of death" which are always a part of a Sad Mac Error Code screen. And of course you unfortunately cannot see that Sad Mac Error Code due to those horizontal lines:

Because it is a Sad Mac error/fault, it will not boot. No Macs boot when the Sad Mac "chimes of death" sound. The problem that causes those chimes must be fixed first. And that is what all my recent posts have been about. Trying to find that elusive logic board fault!

 

[bigmessowires]

Ah sorry, I re-read it too fast and misinterpreted the startup sound.

 

[bigmessowires]

BTW, there's an SE/30 motherboard up on eBay for $1. I'm not sure what the socketed type looks like... is this one? http://www.ebay.com/itm/Vintage-Apple-Macintosh-SE-30-Motherboard-/120773451571?pt=LH_DefaultDomain_0&hash=item1c1ea89f33

 

[JDW]

...there's an SE/30 motherboard up on eBay for

It's does not have a socketed CPU. You can spot the difference right away using this as a guide:

Gold-topped CPUs are socketed:




No Gold means soldered:




In addition, the EBAY listing for that board on EBAY says it won't produce video, which on some level is the same situation I am in now with my bad socketed board. Also, that EBAY board would need to be recapped too.

 

[trag]

Going back to issue #1, the memory chips are actually available on Ebay. Overpriced, but available.

http://www.ebay.com/itm/SRAM-MT42C4255DJ-10-MICRON-28-SOIC-SOJ-42C4255DJ-/370296183601?pt=LH_DefaultDomain_0&hash=item56375f5b31

 

[JDW]

Going back to issue #1...

Trag, that would in fact be "Issue #3":

viewtopic.php?p=157345#p157345

)

What you are speaking of is replacing the SRAMS on my Xceed video card in an attempt to resolve the vertical line problem. And since we have not determine which specific SRAM is the culprit, I technically would need to replace all 16. Thank you for the EBAY listing. But at $10 each, it would cost me $160 in parts, plus shipping to Japan, plus my time to properly desolder those SMD components without harming the board. And without the proper tools to desolder 16 SMD chips (28-pins each), the likelihood of harm coming to the board is high. As such, I may be worse off (dead board) than where I started (1px wide vertical line).

Since I could not so easily and quickly resolve Issue #3, I turned my focus (for now) onto fixing Issue#1 (simasimac board), in hopes that by testing the Daystar card (Issue#2) in another socketed logic board, I might see something different that would help me explain why the Daystar board locks up.

Thanks to Trag, Bigmessowires and everyone else who has participated in this thread thus far. Keep the advice and thoughts flowing!

 

[trag]

Yes, #3, not #1. Leaky memory in my skull. Fall Baseball just started and my head is full of kids' names, matching them with their parents and trying to make sense of who needs some fundamental work on what....

No, I wouldn't recommend replacing all of them. Identifying the culprit will be a pain, so probably best to do what you are doing, and focus on one issue at a time.

 

[Gorgonops]

You could probably determine which is the bad memory chip on the card if you're willing to do some programming. (or possibly by being scientific with a paint program) If you could poke some bit patterns into the framebuffer at various color depths and determine exactly which pixel is being affected (and in what way) it shouldn't be too hard to figure out which chip in a row it is. The problem is that we're not looking at something like a Commodore 64 where's it's relatively trivial to write a program to do that.

Stupid question: If when running a paint program you "select" an area of the screen and drag it around/zoom in (or if you just drag a window around in any program) do the miscolored pixels come along for the ride? If they don't the problem is almost definitely a bad cell in the output buffer of those RAM chips, not a bad line in the main DRAM.

 

[JDW]

Well, the PALs from the BAD logic board are good. I removed the PALs from my good board and put the PALs from the bad board into the good board and booted. No problems. I then ran a full suite of Norton System Info benchmarks and there were no problems. So the socketted PALs are not the source of problems on my bad board. It's a real bear to find the root problem on that bad board!

If when running a paint program you "select" an area of the screen and drag it around/zoom in (or if you just drag a window around in any program) do the miscolored pixels come along for the ride? If they don't the problem is almost definitely a bad cell in the output buffer of those RAM chips, not a bad line in the main DRAM.

Ah, but not every paint program causes those colored pixels you see at the right side of my screen shot and photo. It seems that CANVAS 3.5 is the only app in which I can get the problem to surface, and that seems linked to the fact that Canvas is trying to use its own color palette instead of the system palette, which explains the difference in gradation among the grays/colors shown in the Monitors Control Panel.

In any case, I did the test you asked for, within Canvas. When I move the window in Canvas, the pixels move with it. However, new pixels appear in place of the old. Furthermore, I have Windowshade installed, which means a simple double-click of the window's title bar will "roll up" the window, so to speak. When I double-click (window vanishes, leaving only the title bar), and then when I double-click a second time (to display the window body again), the stray pixels at right vanish entirely. But then if I move the window around again, they reappear in pretty much the same place. And if I move the window around more, those pixels move around with the window, and new pixels take their place (in the original positions). So it appears to be some kind of refresh problem associated with any apps that switches the gray/color palette around, rather than using the standard system palette.

 

[trag]

Well, the PALs from the BAD logic board are good.

Good news.

In any case, I did the test you asked for, within Canvas. When I move the window in Canvas, the pixels move with it. However, new pixels appear in place of the old. Furthermore, I have Windowshade installed, which means a simple double-click of the window's title bar will "roll up" the window, so to speak. When I double-click (window vanishes, leaving only the title bar), and then when I double-click a second time (to display the window body again), the stray pixels at right vanish entirely. But then if I move the window around again, they reappear in pretty much the same place. And if I move the window around more, those pixels move around with the window, and new pixels take their place (in the original positions). So it appears to be some kind of refresh problem associated with any apps that switches the gray/color palette around, rather than using the standard system palette.

Keep in mind that there are two kinds of operations on the screen, for our purposes.

There are screen draws where the information for the image comes from the CPU or from system memory. These should lead to only the orignal corrupted line, caused by VRAM.

And there are screen draws where the information for the image comes from video memory. In this case, when the computer copies the image with the bad line in it, it's going to copy the bad bits that cause the line and write them to a new location.

That's why the bad line appears to move, and why certain refreshes will cause the copied image to go away, but the bad image always manifests in the original place.

The bad memory locations cause the original bad line. When the system copies an image from the bad memory locations, it gets bad information and writes it in a new memory location. The new memory location works properly, but it's just been written with bad data, and faithfully reproduces it.

 

[Gorgonops]

There are screen draws where the information for the image comes from the CPU or from system memory. These should lead to only the orignal corrupted line, caused by VRAM...

I have to admit I'm really curious whether read/write operations to and from the main bus pass through the SRAM cache on the memory chips on the way into/out of DRAM ,or if they hit the bulk DRAM directly. My eyes glazed over reading it but it seemed to me looking at the data sheet that either was an option.

I'm almost rethinking whether it's *definitely* strictly the VRAM at all. Since the line seems to land on annoyingly-convenient-from-a-binary-standpoint 96/192/384(ish) word boundaries I'd place a small side bet on the possibility that it's something wrong with the RAM controller or address generation circuitry that's causing corrupt values to be placed into VRAM in the first place. Unlikely, but not impossible. (Or even, remotely possible, a software bug. Are you running the appropriate system software versions for the driver?)

 

[JDW]

That's why the bad line appears to move, and why certain refreshes will cause the copied image to go away, but the bad image always manifests in the original place.

To clarify, the "pixels" I spoke of in my previous post were not the vertical line pixels. I was speaking of the stray color pixels that you can see in the following screen shot:

https://docs.google.com/leaf?id=0B3mQLg8d1xThM2MzNmQ5YTctZDdiMi00NTk4LWI3ZjUtNTU3M2JmNjg2ZTU2&hl=en_US

Note the vertical "line" at left. I was not speaking about that vertical line in my previous post. I was speaking of the 8 or 9 or so stray colored pixels that are difficult to see yet appear toward the right side of the screen. Look to the immediate left of the "CC" menubar icon to see them. They do go down the screen in a vertical fashion, but they are not the same as the vertical line you see at left. The vertical line at left does not have colored pixels, and it is a continuous line from top to bottom. But the stray pixels at right are colored and not a continuous line, even though they are vertical and extend from top to bottom "with gaps."