Jump to content
techknight

SE/30 video issue that has ME stumped!

Recommended Posts

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! 

Edited by techknight

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 

Edited by techknight

Share this post


Link to post
Share on other sites

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.

Edited by apm

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Edited by apm

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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. 

Edited by techknight

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 

Edited by techknight

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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? 

Share this post


Link to post
Share on other sites

I'm not sure you need anything beyond a stock system (so yes, I suspect Disk Tools would be fine if there's enough free space for the image). Cmd-Shift-3, and then you get a PICT file.

Edited by apm

Share this post


Link to post
Share on other sites

I'm really interested in this one since it's come up twice, and defies the usual explanations. Some things we know:

 

* Probably not an addressing problem, since it affects single bits and not whole bytes of data.

* It must come from the serial data side of the circuit (VRAM/UE8/PALs) since the last bit of each byte is affected by the first bit of the next byte, and because the problem doesn't happen at the end of each video row.

* From the other thread, it must be affected by load on some signal attached to the PDS slot.

* From your experiments, it must be related to some signal that goes in or near UG7 (even though the new PALs don't show that anymore).

* Doesn't seem to be the data lines from VRAM to UE8.

 

That doesn't seem to leave all that many options. Bad connection on the clock (C16M) line to one of the chips? Problem with the timing signals controlling the VRAM? Even something weirder like a bad resistor network RP9 which is responsible for several "pulldown" signals in this circuit?

 

It might be worth scoping the various control signals to the VRAM and to UE8 (excluding data and address), especially if a side-by-side comparison with a working logic board could be done. And I'm curious about the screen shot -- I'm guessing it will come out clean (no lines), but it'll be a clue either way.

Edited by apm

Share this post


Link to post
Share on other sites

Yea, I need to do more checking. I didnt get time today because I fought all day with a Mac Portable board. it was one of the worst ones I have ever run into. I had to change a handful of fried logic ICs, the PMU, as well as the ROMs were bad, that was a first... 

 

But the bastard fired over afterwords. lol. Cant hide from me! haha 

 

Anyways, I need to reorder some ICs anyways (the portables seem to keep consuming all my 74AC02, 74AC10, and 74LS244s regularly), so I will tack on some LS393s, and some other ones to play the swap-out game to figure out which one cures the lines. I hope. That, and I am out of LS166s anyway. 

Edited by techknight

Share this post


Link to post
Share on other sites

Its gonna be a bit before I get back to this board, But how about, lets have an open discussion for a sec. 

 

I am sitting here thinking, UG8, the 74LS393's 8th bit isnt used. so I assume its handled elsewhere. 

 

Since you understand this video circuit much better than I do to be honest, What would happen if UG8 didnt, or couldnt get reset? so it runs past the 8th unused bit and goes back to 0 again. 

 

Would that create the missing "line" of information? 

Share this post


Link to post
Share on other sites

Interesting thought. A similar problem with UF8 was responsible for that bizarre "hidden menu bar" situation that came up on a different thread here last year.

 

UG8 is clocked from C2M (2MHz) so it's counting bytes. I think it's used for generating the HSYNC and TWOLINE signals among other things. One line is 512 pixels plus 192 pixels worth of horizontal blanking = 704 bits = 88 bytes. So two lines is 176 bytes, which explains why only 7 lines of UG8 are needed.

 

Anyway, I think if the reset on UG8 was broken, the HSYNC frequency would be wrong and the CRT wouldn't come up with a stable picture at all. But it's not impossible that it's the culprit.

 

I keep coming back to that SREGLO signal on UE8. What if it were activating one cycle too early? The last bit of every byte (VID(0) or "A" on UE8) would get overwritten with the first bit (VID(7) or "H") of the next byte. That's similar, but not identical, to what we see. But if the VRAM output hadn't finished settling by the time SREGLO changed, then maybe that would produce this result?

 

If that theory has any truth, then the question would be why SREGLO is wrong. This requires a better understanding of how UG7 works, and possibly also what the VIDTIME signal does, since that appears to be a feedback loop from UG6 back to UG7. I'm not sure about any of that, but it does seem like some subtle timing issue between UE8 and VRAM might produce what we see.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×