STFM doesn't boot, CPU halted. How to find what's going wrong?

[trashwolf]

A while back I picked up a slightly battered STFM in a bundle of old computing equipment. Unfortunately, it doesn't boot.

On initial testing, all video outputs appeared blank with no vertical sync. There was no CPU activity even though /HALT and /RESET were not asserted. So, I replaced the CPU. After doing this, I could see activity on the address and data lines, but the video output remained the same.

I found that the GLUE was generating a horizontal sync pulse, but no vertical sync, /BLANK, or DE. After fitting a replacement GLUE, all the video timing signals were present, but the display remained blank (though sync was now present). Once again there was no CPU activity, but this time /HALT was asserted.

The reset circuit seems fine (both inverter inputs to the /HALT line are low). The system ROMs are also probably okay (my EPROM programmer doesn't have a definition for that type of IC, but I did manage to get the first 64K off each chip and it looks valid).

So, the likely explanation seems to be that there is another device that is failing to respond properly to the CPU, causing it to halt with a bus error.

The main suspects seem to be:

• MMU
• DMA controller
• 68901 MFP
• GLUE (unlikely, but I suppose it's not guaranteed that some random replacement chip from eBay is definitely good)

Clock signals and supply voltages all look okay.

I have an analogue scope with single-sweep mode, but frustratingly it does not have a storage function. Using this, when I switch the machine on:

• /RAM and /DTACK on the MMU have at least one falling edge
• /CS and /DTACK on the 68901 have at least one falling edge
• /CS on the DMA controller has at least one falling edge, and RDY has at least one rising edge
• /DTACK on the GLUE has at least one falling edge

It's very hard to see what the signals are actually doing in the fraction of a second they're visible, but it seems none of the chips are completely dead.

Does anyone know a way of narrowing down which device (or devices) might be causing trouble, or figuring out exactly what the system is trying and failing to do? I don't want to start replacing out-of-production custom chips without being sure they're faulty.

CPU and GLUE are now socketed, so can be removed if needed for troubleshooting. System is a stock 520STFM, motherboard revision C103414 rev 1.1, with 2-chip TOS 1.04.

Thanks in advance for any ideas.

[czietz]

Since you already had to replace GLUE and CPU, I suspect that something very bad could have happened to the machine, e.g., an overvoltage. In that case there might be multiple damaged chips and fixing it would become very tedious.

But if you still want to try, these things that come to my mind: When connecting the ST to a suitable color (not monochrome!) monitor, does the screen remain completely black or is it white or colored or striped? Even with an analog scope you should still be able to probe the RAS and CAS signals on the MMU for periodic activity as an indication that the MMU is working. Since the machine is clearly doing something, it's also worth using the diagnostic cartridge and a terminal connected to the serial port (9600, 8N1) to see if there are any error messages that might help.

With really hopeless cases I tend to use my logic analyzer to see which addresses on the bus are accessed. Compared to a working ST or TOS disassembly, I can usually tell which HW failed. However, I realize you don't have that available. Maybe, depending on where you live, you might be able to find a nearby retro enthusiast who can help with test gear?

PS: Service manual is of course available at dev-docs: https://docs.dev-docs.org/

[neanderthal]

Sounds like a interesting fault..Have to read the whole thing properly later on (beer and such just now)

Initial thought since stumbeled on to a thing with the falcy some years back.A adress line not connected..And yes even old boards can get that sometimes.The machine does some cycles and halts due to double bus error.

[siriushardware]

In this case it seems like every time a chip is replaced a little bit more of the machine comes to life, which bodes ill: As Ceitz says, it sounds like something catastrophic has happened to this machine, such as overvoltage on the +5V rail or a lightning strike on the mains supply - in such a case there will hardly be any ICs in the machine which are not damaged.

[trashwolf]

I have no idea what happened to the machine before I got it, so it's entirely possible it suffered a weird power surge or something. The PSU actually seems rock-solid, with no damage and barely even any ripple on the outputs. It'd be nice to get it working if possible, though depending on what's wrong it may turn out not to be cost-effective.

Video outputs:
RF output: black with a bit of multicoloured 'snow' (the outer shield on the RF connector is loose, so this output may not be entirely reliable).
Composite video: completely black. On the scope, the signal has sync and colourburst, but no actual picture information.
RGB: Haven't got a cable made up for this yet. I am sure the first time I looked at this on the scope, R/G/B were all steady at 1.5V. However, I've checked again and now I'm seeing toggling between 1.5V and 3V on R and G, but 0V on B. I will make a cable this weekend and check what's actually on screen.

/CAS0H, /CAS0L, /RAS0, and /RAS1 are all toggling. /CAS1L and /CAS1H are not - is that normal, given that there's only one bank of RAM populated?

Diagnostic cartridge might be worth a try. I do have a serial terminal, and I've found the ROM images and plans for the cartridge on dev-docs.

Using a logic analyser to figure out how far into the boot process it's getting sounds like another promising line of inquiry. I don't own a logic analyser, as you've guessed, but might be able to find someone who'll let me borrow one.

Thanks for the ideas! I'll tinker about some more and report back.

[Arne]

/CAS1L and /CAS1H are not - is that normal, given that there's only one bank of RAM populated?

There should be some activity when TOS boots (RAM detection phase). But without a scope with storage function you won't recognise that. As soon as TOS detects just one bank /CAS1x are constantly high IIRC (/RAS1 isn't as you stated correctly).

[trashwolf]

Well, it turns out the replacement GLUE did fix my machine after all!

I made an RGB adapter for the video connector, put the machine back together, and hooked it up to an RGB monitor. And it booted to a perfectly usable GEM desktop.

So today I learned:

• Pin 2 of the video connector only has composite sync on it, not composite video.
• The RF output on this machine does work, but the connector needs to be held in place extremely carefully otherwise the picture is just coloured snow.
• The machine won't boot without a keyboard.

Whenever I'd been probing the innards with the scope, I'd had the machine partially disassembled with the keyboard unplugged. Whenever I had it all plugged together, I'd been looking for a nonexistent picture on the composite output or a nearly-nonexistent picture on the RF output. I feel very foolish now -- I spent days puzzling over this when the problem was, in fact, a combination of newbie mistakes and a fairly obvious bad connection.

Is the STFM meant to have composite video output, or is that only the STE? The websites I've looked at have different/unclear answers. If the STFM doesn't have it, then the only problem I still have is the broken RF connector.

Thank you to everyone who replied, I seriously appreciate your help.

[czietz]

The STFM is supposed to have composite video on the connector, generated by the modulator. An STF without modulator indeed only has composite sync -- or sometimes even nothing at all, because in some cases the components to generate composite sync were not fitted.

[SteveBagley]

Using a logic analyser to figure out how far into the boot process it's getting sounds like another promising line of inquiry. I don't own a logic analyser, as you've guessed, but might be able to find someone who'll let me borrow one.

I bought a cheap 8-bit clone of a Salae logic analyser off Amazon (this one in fact) several years ago for about £10 (although it seems the price may have gone up) which helped me track down several faults on an ST. If I remember correct, I used it to sample /AS, /DTACK, R/W and A23 which was enough (coupled with a copy of the TOS disassembly in Atari ST Internals) to track down what it was doing and how far things got through the initialisation process by sampling A23 you can line up the ROM/Hardware accesses with RAM accesses with the relevant instructions in the TOS startup sequence.

Steve

[trashwolf]

Might pick up one of those little logic analyser boxes on the basis that I'll probably use it for something sooner or later. Using a single address line to track the boot sequence is certainly elegant.

I've definitely got some sort of signal on pin 2 of the video connector, but still no luck getting my old portable TV to recognise it over SCART. I'm inclined to blame the TV at this point, given that there's a picture on the RGB and RF outputs, and I can't see any plausible way those would both be working but composite video wouldn't. I'll stick with the RGB monitor for the moment.

Anyway, I now have a new problem, which is that when the machine reads from a floppy, it appears to hang and the monitor loses sync. It did start working for a while (long enough to read a couple of disk directories and get part way through loading a game), but then froze. After power-cycling, the problem had returned.

Checking the video signal on pin 2, it looks like the signal frequency approximately doubles at the moment the monitor loses sync. When I check pin 37 on the GLUE, it looks like horizontal sync is doubling in frequency there.

Could it be switching to the frequencies that would be used by monochrome mode, for some reason? I haven't been able to see a transition on pin 29 of the 68901, though. I've also tried swapping the floppy drive for a spare, and it still behaves the same. Anyone else ever seen this happen?

[trashwolf]

So I was looking for clues to the problem, and found that pin 27 on the 68901 was pulsing low while the system checked for a disk during boot, but as soon as I inserted a disk, the monitor lost sync and pin 27 went permanently low.

Then the monitor started malfunctioning: it would display a white screen for a split second as I powered the STFM on, then nothing but black. But the RGB and composite video signals were still present, and the STFM was still making disk access noises. So I connected a different RGB monitor. And now the machine is reading disks fine.

I'm baffled. Is it possible that a monitor, using a cable with only RGB+composite+ground pins connected, could do something to make the STFM's sync signals and disk access go screwy? I am sure there shouldn't be a way for a monitor to crash the computer it's connected to, but it's not like I changed anything else. I guess I just have to wait and see if the problem ever comes back.

At least I can have a nice game of Lemmings now.

[siriushardware]

When you say 'RGB monitor', do you mean one which uses composite video / composite sync for sync like most TVs and a lot of general purpose video monitors do, or do you mean one which has separate Hsync and Vsync like the dedicated Atari monitors do?

The reason I ask is that I don't think the sync outputs from Glue have the 'strength' to drive monitor Hsync and Vsync inputs which have an input resistance of 75R, as some do: The input resistance of the Vsync and Hsync inputs on Atari specific monitors is much higher and the ST's sync outputs are designed to drive that load.

If you are connecting the vsync and hsync outputs from the ST to inputs on a monitor which have very low input resistance, you are probably overloading the GLUE IC. The STe (Not the ST) has low value resistors in series with its Hsync and Vsync outputs, probably to prevent damage in the event that those outputs are connected to very low resistance sync inputs on a third party monitor.

If you have a scope, have a look at what is happening to the Hsync and Vsync outputs when the ST is connected to the 'bad' monitor.

Edit, sorry, looks like you were using only Gnd + Composite (for sync) + RGB, so the information above does not really apply here. If the cable you were using was combining Hsync and Vsync out to produce Csync then the observation concerning input resistance would probably apply, as the composite-in input on a video monitor usually does have an input resistance of 75R.

[trashwolf]

When you say 'RGB monitor', do you mean one which uses composite video / composite sync for sync like most TVs and a lot of general purpose video monitors do, or do you mean one which has separate Hsync and Vsync like the dedicated Atari monitors do?

The former; I have a small heap of CRT monitors with RGB+CSYNC inputs, and have been using the STFM's composite output for the sync signal. The monitor inputs are all 75 ohm impedance, which I think should be fine given it's the same as SCART and there are plenty of people using SCART cables with their Ataris.

I've just dug a third monitor out of the pile, same model as the 'bad' one, and both it and the STFM are working happily together.

The monitors are getting old, so I'm not surprised that one would go a bit funny, but I have no idea why that failure mode would even be possible. Only thing I can think of is that the monitor going wrong was coincidence, and something else made the Atari start working (a marginal capacitor reforming after having power applied for a while, maybe?).

Thanks for pointing out that the Hsync and Vsync outputs are designed for high-impedance inputs; I might not have thought to check that if I'd decided to try a different monitor at some future time. I wonder if something like that was what killed the original GLUE chip?

[siriushardware]

I only discovered this when I bought a lead intended to allow a VGA monitor to be used as a substitute hi-res (mono) monitor - one particular LCD monitor that I have ('Medion' Brand) would not work, the sync inputs on that monitor measure 75 ohms from Hsync and Vsync down to ground. The ones which work have a much higher resistance from Hsync in and Vsync in down to ground.

I can't remember the exact input resistances of the sync inputs on 'proper' Atari ST monitors but it is in the order of Kilo-ohms, which is a much more reasonable resistance to expect a TTL-level chip output to drive directly.

With respect to the composite video input on typical SCART TVs and RGB monitors, composite video inputs are always 75 ohms so composite video outputs are designed with that load in mind.