exxos's Atari, Amiga & retro forum

I've reflowed everything of interest on the bus, with no change in behaviour. But I think this is something else anyway, because of the loss of sync on the monitor output. If it were just a crap connection on the bus somewhere, the system would be crashing, but it shouldn't take the entire video output down with it.

I checked the 555 on the reset circuit vs the working STE and behaviour is identical.

Just now I hooked the scope up to the vsync on the monitor port, and sure enough, if I power it up cold, I can see a clear 60 Hz sync pulse, and then in a few seconds, it starts to get spotty--sometimes present--often not, and then it goes away entirely. This comports with the display on my OSSC, which finds sync, loses it, finds it, loses it, and loses it forever. If I power up warm, there's never any sync at all.

I have verified the CPU has both VCC and CLK present even after the system crashes. I'm going to check the expected inputs and outputs on the other chips shortly. Just wanted to drop an update here.

@derkom check the clocks from shifter and into the glue as the vsync and hysnc are generated my the glue.

"I believe you have placed something in my spot."

(It's still not even my cat!)

derkom wrote: 20 May 2020 10:00 "I believe you have placed something in my spot."

(It's still not even my cat!)

:lolbig: :goodpost:

Ok, the RAM/Data line error shows the test sent in the left 16 bits and the test result in the right hand 16 bits. 000008 suggests bank 0 if memory serves.

Have you tried switching the RAM out yet? Apologies if you already have. Also worth tweaking the PLCC socket springs and chip contacts where they are fitted.

I'd also suggest checking out the data lines at the MMU to see if they are pulsing. I recently had a similar problem and D2 & D4 were somehow disconnected (I plugged something in and the board flexed, something broke, go figure) but no visible problem with the board.

I found the problem with a logic probe at the MMU and the data lines were not pulsing, but they were at the CPU.

Also, not sure if you are using Hi Res, but I found for this sort of thing Lo Res is better. Hi Res will just give a black screen, but Lo Res in my case gave a white border and mostly black screen with corruption along the bottom, so much more helpful.

Great cat BTW.

PhilC wrote: 20 May 2020 09:35 @derkom check the clocks from shifter and into the glue as the vsync and hysnc are generated my the glue.

Glue has 16 MHz on pin 2, and is producing 8, 4, and 2 MHz on pins 3-5, and VCC is present on 36, 72, 108, 120, and 144. Pins 142 (vsync) and 143 (hsync) have nothing.

Of course, there is obviously more amiss here than simply missing sync, because if that were the only problem, I would still be able to interact with the diag software on serial, so the sync vanishing is probably downstream of the actual problem, but that doesn't mean it's not still internal to the glue.

Anything else to look at here, or is this a (partially) dead glue? Replacements are inexpensive, but naturally this would be the one surface mount chip with a million legs. :D

rubber_jonnie wrote: 20 May 2020 10:43 Ok, the RAM/Data line error shows the test sent in the left 16 bits and the test result in the right hand 16 bits. 000008 suggests bank 0 if memory serves.

Have you tried switching the RAM out yet? Apologies if you already have. Also worth tweaking the PLCC socket springs and chip contacts where they are fitted.

Yeah, swapping out the RAM from the working STE was one of the first things I tried. No difference there. Also checked on the PLCC springs.

I'd also suggest checking out the data lines at the MMU to see if they are pulsing. I recently had a similar problem and D2 & D4 were somehow disconnected (I plugged something in and the board flexed, something broke, go figure) but no visible problem with the board.

I can certainly check these things (already checked a few last night, but not systematically), but I can't help but feel that the errors the diag software is showing are all symptoms, not indicators of the real problem, and the reason for thinking that (someone correct me if I'm wrong here) is the total lack of hsync and vsync. I would think that any address or data line problems, while they would crash the system, would not take out hsync and vsync, especially since I know the glue is getting 16 MHz.

derkom wrote: 20 May 2020 10:59
I can certainly check these things (already checked a few last night, but not systematically), but I can't help but feel that the errors the diag software is showing are all symptoms, not indicators of the real problem, and the reason for thinking that (someone correct me if I'm wrong here) is the total lack of hsync and vsync. I would think that any address or data line problems, while they would crash the system, would not take out hsync and vsync, especially since I know the glue is getting 16 MHz.

Yeah, I doubt a crash would affect the sync signals. I presume it's all SMT bar the CPU?

Out of curiosity, what is the /HALT signal doing on the CPU when it drops off? is it high or low? Are you running in Lo res whilst diagnosing, and if so, what do you see happen on screen?

rubber_jonnie wrote: 20 May 2020 11:14 Yeah, I doubt a crash would affect the sync signals. I presume it's all SMT bar the CPU?

U400/GSTMCU/C302183-001 (GLUE, MMU, blitter) is the only SMT chip.

Out of curiosity, what is the /HALT signal doing on the CPU when it drops off? is it high or low? Are you running in Lo res whilst diagnosing, and if so, what do you see happen on screen?

HALT is high when the system is crashed, drops low if I hold the reset button. I am running in low res (or med if the diag software manages to start). If the system is started cold, I'll get at least a white screen, possibly even the diag software screen, but then it goes away when sync disappears. If I start it warm, I get nothing at all.

derkom wrote: 20 May 2020 11:36

U400/GSTMCU/C302183-001 (GLUE, MMU, blitter) is the only SMT chip.

HALT is high when the system is crashed, drops low if I hold the reset button. I am running in low res (or med if the diag software manages to start). If the system is started cold, I'll get at least a white screen, possibly even the diag software screen, but then it goes away when sync disappears. If I start it warm, I get nothing at all.
[/quote]

Damn, I bet that combined chip is an arse to check with the pins in such close proximity. /HALT seems fine, as does reset

I think as you say you have more than one problem here, and that video one is a pain. Have you checked the clocks at the Shifter? I know the DIP type should have 32Mhz on pin 2 and 16 Mhz on pin 39, but don't have a pinout for PLCC type (Yet!)

It certainly doesn't look good if after a while the sync signals stop coming from the GLUE, that chip will be a bit of a bugger to swap out.

Really need to find out what inputs the GLUE needs to generate the sync signals, but if they are generated internally, it's not looking good for the GLUE.