SE/30 video issue that has ME stumped!

[techknight]

I have an SE/30 motherboard here that belongs to someone else. 

It had a strange issue. it had black lines jumping around coming and going. UE8 was already changed and some other ICs swapped around by someone else. 

All the PALS are soldered in place, NO sockets! which that sucked. 

So, I decided to heat the PCB up and the jumping stopped, but it gave me a black line every 8th video bit. So i decided to buzz out all the connections to UE8, the PALs, and the VRAM muxes, all are OK. 

Then I decided to try the freeze spray approach. Hitting UG7 with freeze spray snapped the picture back in with no lines, no jittering. Perfect. 

But, it was a 341-0633 and all my SE/30 parts boards had the 341-0746 

So I swapped out the pair, the 0633 and 0635 with the 0746 and 0747. 

Well, that stopped the raster from jumping around and the lines from flashing and going. But, my 8th video bit horizontally (like a UE8 failure) is still black and gone. 

So I thought, well since the other 2 PALs were the 6XX ones I went ahead and changed those out too so all 4 matched. 

Same thing. Its not UE8 because I can remove the ROM and I get zebra stripes with NO black line every 8th bit. So the scanning circuit works. Also towards the end of me screwing with it, I noticed the floppy disk ? icon was showing perfectly fine through the black line, as well as the mouse cursor outline. So its almost like an old arcade machine where the sprites are perfect, but the background has lines! 

That tells me its a VRAM write issue. maybe? I tried another ROM, another video ROM, and I sucked out and changed the VRAM and no difference. Even tried a different set of RAM, and tried my dougg3 ROM SIMM and same deal. 

This one is definitely got me stumped! 

 

[BadGoldEagle]

It's rare when the master gets stumped. 

When UE8 was replaced it was really rusty underneath, so that board was definitely exposed to the elements at some point in its life. But it was fully working not so long ago, right after the UE8 swap (not for a long time though).

 

[apm]

With the caveat that you've got a lot more experience and so have probably been over all this: it sure sounds like a VRAM write issue.

I might check the traces between the PALs and VRAM, especially the ones other than the address or data lines: UC6/UC7 pin 1 (SC), pin 4 (DT/-OE/), pin 7 (WB/-WE/), pin 8 (RAS/), pin 18 (CAS/), pin 21 (SOE/) -- especially the first three of those.

Say, for example, that the trace connecting SC (serial control) on the VRAM to UG7 pin 15 was corroded, making a high-impedance connection. Maybe the signal is rising too slowly and missing some timing cutoff for the VRAM to switch between parallel and serial access. Or conversely, suppose there was a short somewhere so one of those signals was not reaching a full 5V logic level (some of the lines do have 22 ohm resistors in series). In either case, freezing the PALs might change their output impedance or speed which could push the whole system just barely back into a working state.

Since those 22 ohm resistors are on the bottom layer of the board it might be worth checking for any rot or breaks underneath as well.

Why would the floppy icon and cursor be different? At first I was wondering if the bus writes to VRAM would have been a different width (e.g. 32-bit access to write the checkboard pattern, 8-bit to draw the cursor) but it looks like all access to VRAM are only 8 bits wide. Perhaps a better theory: the VRAM IC is a complicated part that has a lot of different access modes. Maybe drawing the cursor or floppy icon is using some kind of read-modify-write cycle which has different timings on the various strobes, so the problem doesn't show up there. In fact, I guess the cursor at minimum would have to involve some kind of read to VRAM to retrieve whatever data is behind the cursor.

 

[techknight]

Well after replacing the PALs, the freeze trick doesnt work anymore. its stable in all conditions. Stably broken that is... 

Its definitely an access or write issue of some sort, because when the VRAM is in a random state, those "lines" arnt there. When ROM boots and re-inits the video hardware and clears/writes RAM, thats when they show up. 

To make it even more crazy, If I press-hold the NMI button, the raster fills with scrolling dot crawl until I let off. Never seen that happen before. When I let off, it goes to sad mac like normal, and it looks good. no lines. 

 

[apm]

Even so, the fact that the temperature of UG7 ever made a different suggests there's something borderline on the board. The SC line seems like a place to start since it goes from UG7 to the VRAM (by way of a 22 ohm resistor). Does the resistance check out? Any unusual impedance to ground, power, or neighbouring pins?

Then same idea with the other VRAM signals. If it's not the chips, it must be the traces, right? It's almost certainly not the address circuits (UA8-UD8) or it would be a different set of problems -- stripes 8 pixels wide etc. And it's fairly unlikely to be the data lines either, or it would never be able to write that column, even for the cursor.

 

[techknight]

All those lines tested within 22 ohms, and no abnormalities to VCC or GND. 

 

[apm]

When you say the picture and lines were jumping around, was the whole raster moving back and forth, or just the lines on top of it? Were the lines in any random vertical slot, or always on the same 8-pixel boundaries?

 

[techknight]

it was the vertical lines coming and going, and they would flash on and off so rapidly you would only see the black line for half the screen before it went away and came back. They were flickering. losing signal. 

Heating that PAL snapped it back inline and everything was perfect. Until I replaced the PAL set and the 8th video line went and never came back. under any condition. 

But I can see the floppy icon right smack in the middle of one of those lines. Well, its off to the side. 

I will take a picture, BRB. 

 

[techknight]

Here is the picture. I made some annotations of what I saw. 

 

[apm]

Maybe it could be a scanning circuit issue after all. Two observations:

1. The last column, right edge of screen, is a full 8 pixels wide. No missing column.

2. That abnormality on the floppy icon. It looks like there's a clear pattern with the stripes:

pixel should be black --> pixel is black

pixel should be white --> if NEXT pixel (to right) is white, pixel is white, otherwise pixel is black

That would explain the black stripes. Every white pixel within them has a black pixel to its right. The test with no ROM would hide the problem since it would be a series of solid black and white bars.

I'm pretty sure I saw this one on a different thread here some months back, but I can't remember if we ever resolved what it was. Maybe check the SREGLO signal if you didn't just do that? (UG7 to UE8). Or even the counter on UG8?

One other test to tell whether it's a VRAM write problem is to boot the machine and take a screenshot. If the screenshot shows the bars, it's VRAM write. Otherwise it's the scanning circuit.

 

[apm]

Another reason to suspect the scanning circuit after all: the bars used to jump around. I don't think the checkerboard gets rewritten all the time, though I could be wrong. If the bars were jumping around even within a single frame, it's probably coming from reading back the contents, since a write would put the bars in place and leave them there.

 

[techknight]

Ok, now you have me lost. Why is the floppy icon not striped through? 

 

[apm]

For every pixel in the stripe, think of it like an AND gate. If the pixel should be white AND the pixel to its right should be white, you get a white pixel. Any other combination (should be black, or should be white, with its right neighbour black), you get black.

The floppy isn't striped through because most of the icon is solid white. Where the stripes would be, the pixels to the right are also white. But that one part you highlighted, near the top of the icon, you've got a few black pixels just to the right of the stripe. As a result, the stripe reappears for just those rows.

I saw something like this once before. Even though I don't (yet) know why it happens, I think that may be the pattern. What happens if you move the cursor so that its white outline is one pixel to the right of the stripe (i.e. two pixels to the right of where it starts out)? Does a little bit of the checkerboard pattern show up, just to the left of the cursor? That's what this theory would predict.

In any case, it's definitely different than the usual UE8 problem where you get a black stripe regardless of what should be there.

 

[techknight]

But what I dont understand is why is the circuit operating like an AND gate? I always thought its a 1-bit-per-pixel machine. each pixel representing a bit inside a byte in the VRAM...

 

[techknight]

Now im gonna have to go find that other thread. lol. 

the only other thing I can think of is the two 74 series counter ICs that are attached to the PALs that generate the vertical and horizontal scanning... but I metered all those out too. Maybe one is bad. 

 

[apm]

Absolutely no idea! But I've seen this pattern before so there must be some way for it to happen.

It should absolutely be 1 bit per pixel, 1 pixel per clock cycle. It might be some kind of timing problem with loading the data into the shift register. Maybe some clock or signal arrives too early, or too late, and the data that's supposed to be there gets overwritten in some way. The SREGLO line is worth a look for that.

Another thought would be to put a scope probe on UE8 pin 13 (the video out) and then another probe on the video signal that ultimately goes to the analog board. The signal from UE8 goes through a few PALs before it finally leaves the logic board -- maybe there's some problem in that whole signal path.

 

[techknight]

No, because I can ground VID(7) at the VRAM IC, and I can turn all those black lines solid white, and it does not affect any adjacent pixels left or right. 

So its getting through, I checked for that to try and eliminate the scanning circuit. At this point I cant be sure where the problem is, but without knowing whats inside those PALs its extraordinarily difficult to troubleshoot. 

 

[apm]

Ah, here's the thread with the similar problem. That one only showed up when an ethernet card was in the PDS slot. There never was any solution.

Can you see if the problem turns up in a screen shot (to see what's actually in VRAM)? Might be worth looking at the D31 line on UC6 too, maybe even with a scope to see if there are any bus conflicts. But it's still weird that the last column is fine. If it was a problem writing data to VRAM you wouldn't think the last column of each row would be special; you'd see the same thing every 8 pixels no matter what.

 

[techknight]

I chased D31 earlier today and didnt see any breaks or shorts anywhere. I even checked the address lines, and all the lines going to the mux ICs. Nothing. 

At this point only thing I can do is start swapping ICs and hoping for the best. 

I have never taken a screenshot on Mac OS before. Can I do that with a simple disk tools disk?