getting rid of the jailbar pattern

[sbreit]

Hi together!

I just recently bought a SE/30 that suffered from the occasional checkered flag at startup, no bong and a jailbar pattern (and a few other flaws that ain't topic here for now). Recapping helped with the bong and checkered flag, but it still has the jailbar pattern.

In order to have that fixed, I'd like to gain a better understanding of the inner workings of the SE/30's video interface. Altough it might have been true that it was a RAM related problem when the machine was new, it might be anything today, like toast ICs, faulty capacitors, corroded wiring... you name it.

I have a few questions/statements about it that I'll list below, maybe you can confirm/negate or comment them? Most of my statements are somewhat simplified, so don't be nit-picky about them Anyway, here they are:

• The only RAM SIMM directly involved in video output, according to the data lines used, is the second SIMM of bank 0, "SIM2" (if you look at the PCB, the ROM SIMM in the upper left corner, this should be the lowermost of the SIMMs in bank 0).
  
• somewhat oversimplified, each vsync for every line, while in every line the hsync draws the pixels.
  

Let me rephrase that (still somewhat oversimplified): vsync controls the electron beam vertically while hsync controls is horizontally. vsync moves the beam to the next line, hsync starts and moves the electron beam from the left to right. While moving, vidout turns the electon beam on and off, thus "painting" the pixels.

• I suppose that there are two distinct video rams and the contents of the main RAM is copied to the video ram so video won't interfere with CPU and RAM operations (this isn't a Commodore 64)
  
• A blank line every 4 pixels does mean that there are two bits missing each byte. As this pattern is quite reular, this might imply a problem with addressing the video RAM.
  

Given those thougts, those might be the source of the problem:

• Bad connection between SIM2 and the video RAM UC6, UC7 or a problem with the video RAMs themselves
  
• Problem with one of the multiplexers UA8, UB8, UC8 or UD8
  
• Problem with the 8bit shift register UE8
  

Somehow, I don't think that one of the "magic" PALs UE6/7 UG6/7 are involved, but I'm not sure about that.

Are there candidates for failing that are somewhat common? Something I should have a look at first?

Regards

Steffen

 

[zuiko21]

Hi!

·Unlike the remaining compact Macs (SE included), the SE/30 has separate VRAM, thus the regular DRAM SIMMs shouldn't be related in any way to your video issues. The VRAM contents could be copied from DRAM sometimes, but also from ROM, from other sections of the VRAM itself, or even directly computed.

·To be precise about sync signals: the electron beam keeps moving because of the deflection sweep signals coming from the analog board... the HSYNC signal only forces the beam to return quickly to the left after a line has been drawn; in the meanwhile, the vertical deflection coil has lowered the beam just a bit in order to draw the next line just below the previous one. Once the whole 342 lines are drawn, the VSYNC signal comes up and forces the beam to go back to the top of the screen as soon as possible -- while the much faster horizontal deflection keeps swinging the "emerging" beam between left and right in a funny, but invisible fashion. Even if the sync signals are missing, these movements will keep going, although at a somewhat erratic rate. You're right about the VIDOUT signal cutting the electron beam in order to "draw" the black pixels and keeping it on during the white ones.

·The SE/30 has 64 K of VRAM, over twice the required amount for the screen (about 22 K). This is in order to implement double buffering so the screen updates cause no flickering -- the computer draws in one buffer while the video circuits show the other one on the screen. Once finished, the hardware switches quickly to the other buffer and displays the completed image, while further updates can be made on the previous one. But I think there are two VRAM chips for bandwidth reasons: each one gets the same address and supplies 4 bits a time so both in parallel can give 8 bits within the same timeframe -- otherwise it would need VRAM chips twice the speed.

·I don't think there is an issue with address lines, since each address get 8 bits (or pixels; 4+4) a time, so the flaws should be at least 8 pixels wide... the UC6 chip supplies the leftmost four pixels of a "byte", and UC7 the rightmost four.

That said, I think we can rule out a SIMM problem or any issue with the multiplexers, which just put the PAL-generated address on the VRAM chips' address lines. Defective VRAM is a possiblilty, but it looks odd to me that both chips could have the same output bit flaky...

Thus, the culprit is likely to be the UE8 shift register -- OR the lines connecting its inputs to the VRAM output lines. I'd check these for continuity:

UC7 pin 2 = UE8 pin 2

UC7 pin 3 = UE8 pin 3

UC7 pin 22 = UE8 pin 4

UC7 pin 23 = UE8 pin 5

UC6 pin 2 = UE8 pin 10

UC6 pin 3 = UE8 pin 11

UC6 pin 22 = UE8 pin 12

UC6 pin 23 = UE8 pin 14

About the "magic" PAL chips... I can't rule them out since they may do some obscure, complex tasks; but it's worth to check the aforementioned connections first.

Hope this helps,

 

[sbreit]

Hi zuiko21 and thanks for your reply!

The VRAM contents could be copied from DRAM sometimes, but also from ROM, from other sections of the VRAM itself, or even directly computed.

That's interesting... thanks for the info!

·To be precise about sync signals: [...]

You're absolutely right, thanks for the clarification. I've put it very simple, that's why I said "oversimplified"

·The SE/30 has 64 K of VRAM, over twice the required amount for the screen (about 22 K). This is in order to implement double buffering so the screen updates cause no flickering [...] But I think there are two VRAM chips for bandwidth reasons

Okay, now I consider the mystery of the 2 VRAM chips solved I've puzzled over this with a friend of mine... we couldn't quite figure it out.

Thus, the culprit is likely to be the UE8 shift register -- OR the lines connecting its inputs to the VRAM output lines.

This also is what said frend and I came up with... Should be the most likely source of error in the overall picture - at least so far.

Hope this helps,

Sure will! Thanks!

Regards

Steffen

 

[sbreit]

I'd check these for continuity:
UC7 pin 2 = UE8 pin 2

UC7 pin 3 = UE8 pin 3

UC7 pin 22 = UE8 pin 4

UC7 pin 23 = UE8 pin 5

UC6 pin 2 = UE8 pin 10

UC6 pin 3 = UE8 pin 11

UC6 pin 22 = UE8 pin 12

UC6 pin 23 = UE8 pin 14

Well, I checked virtually any line involved in video output and couldn't find any continuity problems or shorts. However, I checked the exact pattern on the screen and found out that there are 6 pixels working, 2 pixels dead. I reckon that the first column on the screen also is the first bit in the video RAM, so the problem might be with the two highest bits somewhere. Given this, it leaves two possibilities:

• The dual multiplexer UA8 is dead, as it triggers RA(6) and RA(7) in both video RAMs (UE6/UE7)
  
• The UE8 shift register has some issues

Somehow, I find it somewhat more likely that the UA8 is dead as this would leat to 2 missing bits somewhere rather than the UE8 having issues with the uppermost 2 bits only.

Now I have to find out where to get 74F253, they seem to be somewhat rare :-/

I'll keep you posted!

Steffen

 

[techknight]

You need a good logic analyzer, or at the bare minimum, an oscilloscope to troubleshoot that issue easily. itll take you right to the fault.

 

[Mk.558]

Does the SE/30 still maintain the double-buffer method when used with an external color display?

 

[sbreit]

You need a good logic analyzer, or at the bare minimum, an oscilloscope to troubleshoot that issue easily. itll take you right to the fault.

Said friend of mine fortunately has both an oscilloscope and a logic analyzer.

For now, I fear that the worst part will be acquiring the spare parts

 

[zuiko21]

However, I checked the exact pattern on the screen and found out that there are 6 pixels working, 2 pixels dead.

So, do you mean the pattern is like 00111111, where '0' means a faulty bit and '1' a working one? I was assuming it was something like 01110111...

That makes things totally different! That would be VID(6) and VID(7) signals, coming exclusively from one of the VRAM chips: UC6. The shift register could be at fault, anyway.

Once again, the highest bits of the address lines have a totally different task: first of all, they are multiplexed (as usual on dynamic RAMs) thus RA(6) and RA(7) (the outputs of UA8) will carry A6/A7 and A14/A15 from the CPU, alternatively. But they also put the values from other video related signals: VADR(0), VADR(7), ALTVID and TWOLINE. Amongh other issues, problems with this multiplexer may imply artifacts like misplaced things on screen, by factors of 8 horizontal pixels and/or one, two or 256 vertical lines. Since you didn't mention such a scrambled display (other than the jailbar pattern) I think the multiplexer is just fine.

On the other hand, the output from the shift register goes thru one of the PALs (UG6, pin 9 to 13) so we can't rule it out, either...

 

[sbreit]

Hi!

We just hooked up a logic analyzer to te PCB, turns out the shift register seems to be toast. The inputs VID(0) to VID(7) are all fine, while the output lacks 2 bits. Also, the IC itself looked a bit battered. I'll have it replaced, we'll see then...

The pattern is 11111100 by the way. I also thought it was 11101110 at first

Regards

Steffen

 

[trag]

Now I have to find out where to get 74F253, they seem to be somewhat rare :-/

Mouser has them:

http://www.mouser.com/ProductDetail/Texas-Instruments/SN74F253N/?qs=mE33ZKBHyE7IP7mBS4SId9FcAC2SzyMAP4b1f40%2fTO4%3d

Digikey does not have them. I looked for something compatible in a CMOS part, Digikey didn't have anything fast enough in a DIP package.

 

[sbreit]

Mouser has them:

[...]

Digikey does not have them. I looked for something compatible in a CMOS part, Digikey didn't have anything fast enough in a DIP package.

Thanks for the pointer to Mouser, didn't know that yet. The ICs are SOIC packages, not DIP. I found them at Farnell and already ordered them.

 

[trag]

Thanks for the pointer to Mouser, didn't know that yet. The ICs are SOIC packages, not DIP. I found them at Farnell and already ordered them.

Pshah! I didn't realize they are SOIC packaged chips. Those are vastly easier to find than the DIP variety.

 

[sbreit]

Yay!

I just successfully fixed the SE/30. It was the shift register in question. Now the SE/30 is all jailbar-free!