STFM VIDEO SYNC FAULT

[exxos]

I might have mentioned this before. It seems to be a common problem , but I have not had much time to investigate this. So wondering if anyone has any ideas on this.

Fault only seems to happen on totally white screen. Once it gets to the desktop, the fault stops. Its NOT the cable, or monitor, PSU etc, its the STFM itself.

I've changed the shifter & GLUE already as they were easy to change. Though thought I would post this as likely whatever the problem is, could be some other type of degenerative fault with the machines age. I will add more caps to the shifter area later, but I have a feeling I have tried that before.

[siriushardware]

As mentioned in another nearby thread, a similar fault on my STFM was caused by failure of one of the gates in U51 - its input is connected to Hsync and if that gate gets damaged it breaks the hsync signal which should be forwarded (through a 74LS86, used as a sync combiner) to the RGB-Composite converter IC.

This is the one I mean.

SyncFault.png

In my case, failure of this gate was caused by my (only momentarily) plugging the 13-pin monitor plug into the ST monitor socket upside down when both the ST and the monitor were on. The surprising thing (to me) was that it was this chip which took the bullet, while the exotic, expensive Glue chip which is also exposed to the outside world on exactly the same monitor socket pin was completely undamaged.

In the end I was glad I had done it because replacing U51 to fix the sync fault also fixed a DMA port problem I had been having on the same machine (the HDD _DRQ line comes in through one of the other gates in the same chip).

[exxos]

Interesting, I didnt look at the circuit, but didn't realise Hsync went though a buffer. I will scope that out and see whats going on.

[troed]

Interesting. I have the exact same symptoms as in your video exxos, on one of my STFMs. Thought it was the TV that didn't "lock" onto the signal as it should and needed the "help" of the screen edges.

/Troed

[siriushardware]

Interesting, I didnt look at the circuit, but didn't realise Hsync went though a buffer. I will scope that out and see whats going on.

Hsync only goes through a buffer to the 74LS86 sync combiner then on to the MC1377 RGB-composite encoder IC. Depending on the model version, the 74LS86 and MC1377 may or may not both be inside the modulator can, or they may be on the main board.

Hsync goes direct from GLUE to the Hsync output on the monitor socket without going through the 74LS04 buffer so one possible telltale for this fault is that sync is OK in RGB mode but broken in composite mode.

Of course, it's possible for the U51 gate to be blown / damaged in such a way that it places a heavy load on the Hsync line, in which case it could break Hsync for RGB mode as well.

All that said, it appears that on some versions of the ST the Hsync and Vsync signals not only go directly to the monitor socket, but directly to the modulator as well. Whether this means there is an equivalent inverter INSIDE the modulator on those versions, I don't yet know.

[exxos]

Interesting. I have the exact same symptoms as in your video exxos, on one of my STFMs. Thought it was the TV that didn't "lock" onto the signal as it should and needed the "help" of the screen edges.

/Troed

We all know the video is a bit "iffy" to start with, but I have several machines which work fine, and several having that video fault. I literally have 2 identical motherboards, one works the other does not.

Odd thing is, now the machine has been on most of the day, the problem seems to be slowing going away.. So that makes debugging a bit harder

[exxos]

Of course, it's possible for the U51 gate to be blown / damaged in such a way that it places a heavy load on the Hsync line, in which case it could break Hsync for RGB mode as well.

There is a slight voltage drop at random on the input of the inverters, other than that, clean signals. I'm going to add a pullup on there to see if helps. Though as said above, the problem seems to be getting less and less as the machine warms up it seems.

EDIT1: Adding a pull on on the input of the inverters with the addition of the scope probe seem to make matters worse. Interesting the type is a 74AHCT04. Normally find LS chips in general.

[siriushardware]

Mine was originally also a 74HCT04, but replacing it with a 74LS04 as marked on the diagram works OK for all the functions of U51 including DMA _DRQ.

I think it's worth putting that chip in a socket anyway since at least two of its gates are directly exposed on rear panel socket pins and prone to being damaged.

[exxos]

Mine was originally also a 74HCT04, but replacing it with a 74LS04 as marked on the diagram works OK for all the functions of U51 including DMA _DRQ.

I think it's worth putting that chip in a socket anyway since at least two of its gates are directly exposed on rear panel socket pins and prone to being damaged.

Yeah might put a socket there , then can try LS chips also. Though loading with the scope probe would make the timing a fraction slower. So assuming LS is a slower device, the problem should get worse.

[exxos]

I've checked VSYNC, HSYNC, BLANK. I can't see any difference between when the video is going mental to when its stable.

Only small thing I did notice, is when I hold down the reset button (which also gives same effect) that BLANK pulse goes a fraction shorter. But it doesn't vary in normal running. I did wonder if it was some blanking timing error, rather than a sync fault. Even so, I don't understand why it only happens on a plain white screen and not on the desktop. It really has me stumped

[siriushardware]

I think... that during the reset phase (ie, when reset is held down) the ST video hardware runs at 60Hz, so it would be logical for everything to get a little bit faster / shorter during that phase.

On a PAL machine, it reverts to 50Hz once the desktop appears (Edit: more accurately, it reverts to 50Hz once the reset button is released AND the reset circuit allows the system to come out of reset - so for most of the brilliant white screen between releasing reset and the appearance of the desktop, the video hardware will be running at 50Hz.)

You haven't actually said - is this happening in RGB mode / composite mode / both? If you've only been trying one mode so far, what happens when you try it the other way?

[exxos]

I think... that during the reset phase (ie, when reset is held down) the ST video hardware runs at 60Hz, so it would be logical for everything to get a little bit faster / shorter during that phase.

On a PAL machine, it reverts to 50Hz once the desktop appears.

hmmm, so I wonder if somehow its switching between 50hz and 60hz after reset..

[siriushardware]

Oops... we cross posted and I edited while you were replying. What was the answer to the question about RGB / Composite? Any difference when using either of those modes?

[exxos]

Oops... we cross posted and I edited while you were replying. What was the answer to the question about RGB / Composite? Any difference when using either of those modes?

Oh, im using RGB/scart , I can try RF.. dont think I ever used composite cable, think I had one somewhere about 15 years ago

[exxos]

This is what it does with RF.

I see the sync pulses get shorter when reset is held down. They do not vary when I release the button. so both syncs seem stable to me.

[siriushardware]

Looks like you're using an LCD flatscreen?

If so, those things do a kind of realtime analysis of the incoming video signal and try to work out what size and shape they should make the picture and how they should position it, based on frame rate, apparent aspect ratio and so on.

In your video you can see it making rapid changes to these settings when the one or two lines of black text appear as the text gets stretched and repositioned several times just prior to the appearance of the desktop, when it finally has enough of a picture to work with. I think Sync's (sorry, Troed's) idea that the TV / Monitor just doesn't know what to make of a brilliant white raster with no detail may not be far off the mark.

Have you got a real monitor, by which I mean an analogue, CRT, RGB monitor (Philips CM8833, Commodore 1084, etc) to repeat this experiment with?

[exxos]

Looks like you're using an LCD flatscreen?

If so, those things do a kind of realtime analysis of the incoming video signal and try to work out what size and shape they should make the picture and how they should position it, based on frame rate, apparent aspect ratio and so on.

In your video you can see it making rapid changes to these settings when the one or two lines of black text appear as the text gets stretched and repositioned several times just prior to the appearance of the desktop, when it finally has enough of a picture to work with. I think Sync's idea that the TV / Monitor just doesn't know what to make of a brilliant white raster with no detail may not be far off the mark.

Have you got a real monitor, by which I mean an analogue, CRT, RGB monitor (Philips CM8833, Commodore 1084, etc) to repeat this experiment with?

I don't have a real monitor no Though most motherboards I try work fine. So its finding out whats different and causing the issue.

The motherboard I am using now was one I had been using years, at my girlfriends playing supercars mostly. Though about a year ago it just started doing that crazy video thing on her TV. Does the same on my little LCD also. It never used to. So somethings changed somewhere.

I have tried slowing down the H-sync, all it seems to do is start making the video go to the left. Oddly, if I leave the H-sync disconnected, the picture seems somewhat stable on desktop. If I touch the pin, then the desktop jumps downwards about half way down the screen and stops there. Wouldn't have thought it would work at all with H-sync disconnected.. I will have a fiddle with V-sync next..

EDIT1: Soldered a resistor on VSYNC and now the ST doesn't boot at all, just a white screen. I've changed the GLUE & MMU and ROMS, still no boot. So looks like i've managed to kill this board somehow

[siriushardware]

Maybe the TV's decoder logic is clever enough to deduce the existence and likely timing of the missing Hsync pulses based purely on the presence and timing of 50Hz Vsync pulses. If so, that's just showing off.

I agree (now that we have the whole story) that something must have changed. We look forward to hearing what it turned out to be, now that you seem sufficiently motivated to get to the bottom of it.

[siriushardware]

Ah. I see from your last edit that things just got more interesting. I know you'll be thinking it must be due to whatever you did with Vsync, but impartially, it sounds more like it's stuck in reset somehow.

[exxos]

Maybe the TV's decoder logic is clever enough to deduce the existence and likely timing of the missing Hsync pulses based purely on the presence and timing of 50Hz Vsync pulses. If so, that's just showing off.

I agree (now that we have the whole story) that something must have changed. We look forward to hearing what it turned out to be, now that you seem sufficiently motivated to get to the bottom of it.

Well as edited in my previous post, seems ive killed this board. So thats that then. I know I have other boards that have had the same problem, but no idea what I did with those, likely got used for spares.. Debugging dead boards is just a huge time sink, so this investigation will just have to go on hold until i come across another board with the same problem.

[troed]

For posterity: HBLANK is indeed 4 cycles shorter in 60Hz (508 cycle lines) than 50 (512).

[redhawk668]

My 1040 STFM does this too on my LCD, but I think the reason it does that is that I have replaced the TOS roms. I went from 1.02 to 1.04. I bought the roms on eBay from an American seller... Yep, US TOS version in a Dutch STFM, it works perfectly though, only the video starts a bit funky... When it boots to the Desktop my LCD synchronises at 60 Hz, as it is US TOS version, it starts at 60 Hz... lol.

[exxos]

I had my STFM for years. It just started doing that for no reason at all. I suspected some bad caps in the video circuit, but after much work I didn't find a cause for it. I've had several other motherboards do exactly the same. I can have 2 identical boards, one works, other does not. I've tried swapping IC's around without success. I think someone suggested the ST might be trying to sync at 60hz on boot, but my TV will work in 50hz or 60hz anyway, so I am not so sure thats the issue.

There could be some odd noise issues relating to the control lines around the shifter, or even some odd noise on the 32mhz clock itself. Something has drifted over time spec wise causing the fault. Its just finding out what.

I may investigate this again in the future. But with so many other projects in motions right now, its just not something worthwhile to invest time in currently.

[redhawk668]

Well, if I put back the TOS 1.02 roms it behaves normally. But, I'll keep the 1.04 roms in. It's not really a problem. As a side effect, the 60 Hz gives a better picture. I might change the PSU on my STFM too, as the picture starts to wobble when running certain programs in low or medium resolution...

[exxos]

Well, if I put back the TOS 1.02 roms it behaves normally. But, I'll keep the 1.04 roms in. It's not really a problem. As a side effect, the 60 Hz gives a better picture. I might change the PSU on my STFM too, as the picture starts to wobble when running certain programs in low or medium resolution...

Strange. I've not found any link to TOS and the video fault I have so far. Though I have documented before that some ROM's don't tend to work very well because of noise & bus loading related issues. I doubt TOS itself would cause video issues across versions, at least not this fault I am seeing. Though a different IC could generate additional problems.

You could try changing the bus resistors from 10K to 2.2k (think theres 5 arrays to change) that seems to be a huge problem on STFM machines and generates all kinds of crazy faults.