-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
SE/30 video issue that has ME stumped!
- Thread starter techknight
- Start date
techknight
Well-known member
Yikes! I remember that thread. And I dont have an expansion card. But its the exact same identical problem.
apm
Well-known member
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.
* 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.
Last edited by a moderator:
techknight
Well-known member
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.
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.
Last edited by a moderator:
techknight
Well-known member
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?
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?
apm
Well-known member
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.
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.
techknight
Well-known member
Well the PALs have been changed. UE8 has not been by me yet.. the trace is good, and no shorts between it to the rails. So unless the substrate capacitance is too large, i am unsure.
apm
Well-known member
UE8 may be worth a replacement, but it could also be the inputs to the PALs: garbage in, garbage out. In that other thread, whether or not there was a card in the PDS slot caused the problem to come and go. That would seem to suggest that at least one signal connected to the PDS is somehow involved, though I'm still not sure how.
techknight
Well-known member
I think the PDS card thing was a fluke, because in my case its consistent.
Only other thing I can do is monitor the data bus coming from the CPU, because I have seen 1 case, and ONLY 1 case that the CPU was bad. the CPU would run through the addressing without the ROM in.
But as soon as I stuck the ROM in, the data signals fell down from 5V to more like 3V, and no boot. Swapped the CPU, and presto.
Only other thing I can do is monitor the data bus coming from the CPU, because I have seen 1 case, and ONLY 1 case that the CPU was bad. the CPU would run through the addressing without the ROM in.
But as soon as I stuck the ROM in, the data signals fell down from 5V to more like 3V, and no boot. Swapped the CPU, and presto.
Last edited by a moderator:
bibilit
Well-known member
I have a similar issue with one of my boards.
New caps all around, the board chimed but got a black screen.
I removed and replaced UE8 UF8 and UG8, this time the screen lit up and got the question mark, but the left screen side had rounded borders while the right side square ones, while testing the board a little further i got those vertical lines coming and going also, more or less the same pattern.
The pattern is not present at startup, only after a while.
Any solution found on your side ?
New caps all around, the board chimed but got a black screen.
I removed and replaced UE8 UF8 and UG8, this time the screen lit up and got the question mark, but the left screen side had rounded borders while the right side square ones, while testing the board a little further i got those vertical lines coming and going also, more or less the same pattern.
The pattern is not present at startup, only after a while.
Any solution found on your side ?
techknight
Well-known member
Never did get back around to it. Work is ramping up again.
bibilit
Well-known member
@Techknight
The symptom i have but you didn't is the right side of the screen having square angles while the left side are correct, have you ever seen this before ?
I am thinking both troubles are probably linked together, and solving one will probably solve the other;
What part is responsible from turning the square screen at bootup to rounded ?
The symptom i have but you didn't is the right side of the screen having square angles while the left side are correct, have you ever seen this before ?
I am thinking both troubles are probably linked together, and solving one will probably solve the other;
What part is responsible from turning the square screen at bootup to rounded ?
bibilit
Well-known member
If i change the background, lines are not there, i can see some flickering, but nothing else.
Oh, yes, booting from a Jaz, don't know if something related, but the SE/30 is not able to boot from a good HD... will a bad SCSI chip be able to boot from a SCSI external drive and not internal one ?
Oh, yes, booting from a Jaz, don't know if something related, but the SE/30 is not able to boot from a good HD... will a bad SCSI chip be able to boot from a SCSI external drive and not internal one ?
Last edited by a moderator:
techknight
Well-known member
that... is weird. But its right up the same alley.
I am wondering if it isnt an address or data wire that has "resistance" instead of a full break, or full short (like it should).
I am wondering if it isnt an address or data wire that has "resistance" instead of a full break, or full short (like it should).
bibilit
Well-known member
Hi,
some questions.
Made some progress, the board is booting from the hard drive once again and the lines have gone.
Concerning the square problem, i think this is related with the screen not been properly built a 100 %.
I explain it, the mouse cursor goes to the left and bumps to the left side, but doing the same thing on the right side, the cursor goes further and get hidden in the process..
Looks more or less the same problem here:
https://68kmla.org/forums/index.php?/topic/26542-hidden-menu-bar/page-6
But this time on the vertical side, where the right side goes too early and have no time to finish the curved side.
Any idea ?
some questions.
Made some progress, the board is booting from the hard drive once again and the lines have gone.
Concerning the square problem, i think this is related with the screen not been properly built a 100 %.
I explain it, the mouse cursor goes to the left and bumps to the left side, but doing the same thing on the right side, the cursor goes further and get hidden in the process..
Looks more or less the same problem here:
https://68kmla.org/forums/index.php?/topic/26542-hidden-menu-bar/page-6
But this time on the vertical side, where the right side goes too early and have no time to finish the curved side.
Any idea ?
Similar threads
