Mac SE video output compressed vertically (not tall enough / skipping rows)

wottle

Active Tinkerer
Oct 30, 2021
519
272
63
47
Fort Mill, SC
TLDR: Analog board adjustment has been made to no avail, compressed picture persists across multiple known good analog boards that show full picture with other logic boards. Confirming problem is on the logic board).

I recently picked up an SE/30 for a steal but it had a Simasimac screen with some distortion (also, although I didn't dig into it at the time, the simasimac screen was compressed vertically, meaning it did not take up the entire height of the screen). Here's the starting point:
IMG_9151.jpeg


I cleaned the board well (it was filthy and I suspect an animal or insects had been living in it, given the significant amount of debris / black stuff on the board). I replaced all the caps on the logic board, and the problem persisted.There appears to have been other work done on this SE/30 previously, so I decided to replace everything I could. I removed the RAM, ROM, Video ROM, all the chips at UC6/7. UE6/7, UG6/7, UI6 and replaced them with known good chips from another board. Problem remained. I traced the problem to the video RAM chips (which on this machine were generic chips with zero markings on them). Once I replaced those with new chips, the board would give me a boot chime and a gray screen (compressed vertically).

IMG_9153.jpeg


After troubleshooting some RAM problems, I was able to successfully boot into System 6, but the video was still compressed. No big deal, I thought. "I'll just adjust the screen height on the analog board". Sadly, the height adjustment was already almost at its highest. The video signal must not be sending the full width.

IMG_9156.jpeg


The traces on the board actually all look very good. I specifically checked around UE8 because I had another SE/30 that had issues with UE8 and it was due to corrosion of the legs of UE8 and replacing the chip solved that problem. I can replace it, but this problem feels different. Anyone seen this before or know what might control the horizontal video output for the SE/30. I looked through the Dead Mac Scrolls and didn't see anything that matches this problem.

PS. Here's a look at the board - it cleaned up pretty well.

IMG_9158.jpeg
 

wottle

Active Tinkerer
Oct 30, 2021
519
272
63
47
Fort Mill, SC
The more I look at it, it seems like it is drawing every other row on the screen. Would a VSYNC issue cause this?
 

YMK

Active Tinkerer
Nov 8, 2021
354
283
63
The "VERT DRIVE" section is worth checking out.

The vertical deflection coil resistance and wiring should be checked.

The four pin yoke connector is often burned as a result of poor contact.
 

wottle

Active Tinkerer
Oct 30, 2021
519
272
63
47
Fort Mill, SC
The "VERT DRIVE" section is worth checking out.

The vertical deflection coil resistance and wiring should be checked.

The four pin yoke connector is often burned as a result of poor contact.
The analog board has been ruled out, as I have tried a working board with this analog board and it displays fine. I also tried this logic board with a different analog board and it displayed improperly as well. If it was an analog board problem, wouldn't the image be drawn improperly. From the looks of things, the lines that are drawn, are rendered properly. It's just missing some lines. Feels like a logic board / video signal issue.

In all my searching, I haven't been able to find anyone else with these symptoms... I just hate to have to resort to something like a reloaded board to fix this. Seems excessive when almost everything else is working properly. I may try to see if I can get an RBG2HDMI set up on this thing to see how that signal looks.
 

YMK

Active Tinkerer
Nov 8, 2021
354
283
63
The analog board has been ruled out, as I have tried a working board with this analog board and it displays fine.

My mistake, I missed this part somehow. It could be a VSYNC or HSYNC problem, so I'd check the frequency of those signals. I'll take another look at the video section.

As an aside, how does one remove the pins from that connector?

A Molex pin extractor should work. It's basically a metal tube slightly bigger than the pin (male or female) that fits over it, pushing its latches inward.

Tweezers can work for this as well.
 
  • Like
Reactions: wottle

Paolo B

Tinkerer
Nov 27, 2021
258
143
43
Nagoya, Japan
As an aside, how does one remove the pins from that connector? I bought a replacement for my own machine, but haven't quite worked out how to release the pins so I can swap it.

The pins have dovetail latches. Either use an extractor, or with a needle gently bend each latch inward. You will have to bend them outward again and to restore the dovetail shape before inserting them back into the new connector body.
 

wottle

Active Tinkerer
Oct 30, 2021
519
272
63
47
Fort Mill, SC
The sync pins are all properly connected - no bad traces or pads. I don't have a scope to check signal (nor do I know what I'd be looking for). Is it possible its with the video multiplexors. Don't those break up processing of the video signals and then merge them together? If 2 of the 4 were bad, could it be why half of the lines are not being drawn?
 

YMK

Active Tinkerer
Nov 8, 2021
354
283
63
I don't have a scope to check signal (nor do I know what I'd be looking for).

You'd look for 60.15 Hz on VSYNC and 22.25 KHz on HSYNC. If you don't have a scope, a DMM with frequency function should work.

Pin 13 of UG7 is HSYNC (22.25 KHz)
Pin 12 of UG7 is TWOLINE and advances the UF8 counter every other line (11.125 KHz)

If there's a short between them, I could see the row counter advancing faster than it should.

The fact that the image is both compressed and missing every other line suggests a problem with row counter UF8 and the PAL it feeds (which generates VSYNC), UG6.

Is it possible its with the video multiplexors. Don't those break up processing of the video signals and then merge them together?

The video muxes operate on video addresses, but not the actual data.

They select between an address generated by the 030 and UF8.

They also split the linear input address into a row/column address the VRAMs can use.
 
  • Love
Reactions: wottle

wottle

Active Tinkerer
Oct 30, 2021
519
272
63
47
Fort Mill, SC
You'd look for 60.15 Hz on VSYNC and 22.25 KHz on HSYNC. If you don't have a scope, a DMM with frequency function should work.

Pin 13 of UG7 is HSYNC (22.25 KHz)
Pin 12 of UG7 is TWOLINE and advances the UF8 counter every other line (11.125 KHz)

If there's a short between them, I could see the row counter advancing faster than it should.

The fact that the image is both compressed and missing every other line suggests a problem with row counter UF8 and the PAL it feeds (which generates VSYNC), UG6.



The video muxes operate on video addresses, but not the actual data.

They select between an address generated by the 030 and UF8.

They also split the linear input address into a row/column address the VRAMs can use.
OK, thank you so much for the insight.

I tested and HSYNC is 22.25 and the TWOLINE is 11.125.

BUUUUT, the VSYNC is 119.6KHz, which sounds like the reason for my problem (VSYNC being 2x what it should means HSYNC is relatively half of what it needs to be to keep them in sync. What drives the VSYNC? Does it come from the RTC? I thought maybe Y1 is the culprit. However, I replaced it and the Y1 is still reading 60Hz and the VZYNC is still 119.6KHz. I feel like we may be getting close though! Thanks again for all your help!
 
  • Like
Reactions: YMK

YMK

Active Tinkerer
Nov 8, 2021
354
283
63
Good, that's progress!

VSYNC comes from pin 14 of UG6. I assume you measured 119.6 Hz, not KHz.

TWOLINE feeds the UF8 counter (VADR lines), which in turn feeds UG6.

Check the frequency on UG6 pins 2 through 8.

Pin 2 should measure 5.5625 KHz (half of TWOLINE). Pin 3 should be half the frequency of pin 2 and so on.
 
  • Like
Reactions: wottle

wottle

Active Tinkerer
Oct 30, 2021
519
272
63
47
Fort Mill, SC
Good, that's progress!

VSYNC comes from pin 14 of UG6. I assume you measured 119.6 Hz, not KHz.

TWOLINE feeds the UF8 counter (VADR lines), which in turn feeds UG6.

Check the frequency on UG6 pins 2 through 8.

Pin 2 should measure 5.5625 KHz (half of TWOLINE). Pin 3 should be half the frequency of pin 2 and so on.

Yes, I meant 119.6Hz.

Pin 2 was 11.13KHz (same as TWOLINE). I show 11.13 (my multimeter isn't great) on pin 12 of UC7, confirmed that's what I see on pin 1 of UF8. Pin 3 on UF8 also read 11.13, as does pin 2 on UG6. On UG6, all the pins cut the frequency in half from 2-7, but pin 8 seemed to drop off too much, at 120Hz vs 174 (expected). However, I think I should have seen pin 2 be 5.5625Hz down to 86.9Hz on pin 8, correct?
 

YMK

Active Tinkerer
Nov 8, 2021
354
283
63
Pin 2 was 11.13KHz (same as TWOLINE). I show 11.13 (my multimeter isn't great) on pin 12 of UC7, confirmed that's what I see on pin 1 of UF8. Pin 3 on UF8 also read 11.13, as does pin 2 on UG6. On UG6, all the pins cut the frequency in half from 2-7, but pin 8 seemed to drop off too much, at 120Hz vs 174 (expected). However, I think I should have seen pin 2 be 5.5625Hz down to 86.9Hz on pin 8, correct?

I measured:

Pin 2: 5.55 KHz
Pin 7: 172 Hz
Pin 8: 60 Hz

I missed a detail: Pins 2-7 do indeed map to VADR0-VADR5. However, pin 8 is VADR7. VADR6 is not fed to UG6.

pin 8 of UG6 would be 43.46 Hz (1/4 the frequency of pin 7) if the counter was allowed to roll over. However, it's reset by pin 15 of UG6 before then, raising the frequency to 60.15 Hz.

You should have 60.15 Hz on UG6 pin 8.

The root problem appears to be UF8 pin 3 isn't half the frequency of pin 1, as it should be. I'd try swapping UF8.
 
  • Love
Reactions: wottle

wottle

Active Tinkerer
Oct 30, 2021
519
272
63
47
Fort Mill, SC
OK, so we have a winner! It seems like the UF8 chip was not behaving properly. I swapped it out and the frequencies look good and the screen image is whole now!


SOLUTION: I swapped out the malfunctioning chip at UF8 for one from a parts board.


Thank you so much for your help!!!
IMG_9202.jpeg


Edit: Corrected the IC location in the post above to clarify it was the UF8 chip and not UG6 that was the problem.
 
Last edited:
  • Like
Reactions: YMK

YMK

Active Tinkerer
Nov 8, 2021
354
283
63
That's great news!

So you swapped UG6, the socketed DIP?

That's an interesting failure. I'm not sure how the TWOLINE signal would find its way to VADR0 through UG6.
 

wottle

Active Tinkerer
Oct 30, 2021
519
272
63
47
Fort Mill, SC
That's great news!

So you swapped UG6, the socketed DIP?

That's an interesting failure. I'm not sure how the TWOLINE signal would find its way to VADR0 through UG6.
No, I mis-typed. It was the UG8 chip... Too many chips and schematics rattling around in my head. I updated my post to correct it.
 

YMK

Active Tinkerer
Nov 8, 2021
354
283
63
No, I mis-typed. It was the UG8 chip... Too many chips and schematics rattling around in my head. I updated my post to correct it.

Now I'm really confused... UG8 is the column counter. UF8 is the row counter that had the wrong frequency on pin 3.

They're both surface mount LS393s.