Someone took a interest in an Atari ST we had on hand, and we naturally hoped that it was just in working order. But, of course, that was NOT the case. It did power on without any smoke or explosion. That's a start. And the video output generation was working. But that video output was a color salad of non-sense. So a repair was in order. Excellent!
So we opened the unit up to uncover the main board inside. We immediately noticed some unusual hacks to this unit. For one, there was something hiding on the system bus. It was buried in an interposing IC socket under one of the ROMs. But far more glaring than that was the blatant RAM upgrade applied over the stock RAM chips. An additional row of 41256 (256k x 1-Bit DRAM) chips are piggybacked over them. The added chips of the top layer were soldered onto the factory-installed chips beneath for parallel connection for most of their pins. But the unique control signals required for selecting the upper memory bank were bussed together across the high and low byte groups with wires soldered atop each stack. Simple way to do a RAM upgrade, albeit not beautiful.
Time to dive in. The video output is garbled, or more accurately probably uninitialized. So, is the 68000 processor running? We looked at the 68000's /AS pin. This is the Address Strobe. Its function is to signal from the processor that the Address Bus and Control Lines are set up for the memory operation. When the 68000 first starts up, it begins by reading its start up locations (Supervisor Stack Pointer and Program Counter) from fixed locations in memory space. So we certainly expect to see the /AS pin go active. But nothing. Dead.
So, why isn't the processor processing? Next, we check out the /RESET line, whose function is to get the processor to a properly initialized state to start execution. And it looked good -- at both power up and a press of the Reset button.
Well, there's this other control pin on the 68000, the /HLT line, that could stop it from running. This pin serves to command the processor to stop executing when active. Measuring that, we see it is stuck low (active). So that would certainly explain why the 68000 is not doing much. This signal comes from a monostable (one-shot) multivibrator timer circuit from U37, which generates a single pulse on power-up, but then maintains so the 68000's /HLT as inactive. And looking with the scope, that timer output signal is good.
Now we need to look at that /HLT signal directly. And this can be tricky to interpret. The 68000 itself can drive this bidirectional signal low if it halts itself, by certain unrecoverable fault conditions. But if the 68000 hasn't even read from memory yet (no /AS asserted), that wouldn't be normal. The signal otherwise originates from a pull-up controlled by a 7405 inverter gate in chip U36. So we used some flush cutters and cut the pin of the 7405 for this signal in half.
This way we can see that the signal line does go up to the pull-up voltage without the gate. And indeed it did. In fact, with the pin cut and the chip unable to interfere, we can now manual generate the proper /HLT signal on power-up and see the 68000's /AS operating as it should. Suspicion now squarely points at the 7405 chip. So we replace it. And with the new chip, we also see /AS going good.
Working now?? Well, better but not quite. In fact, as is frustratingly the case with this ventures, outwardly there was no change. Still, when we turn on or reboot the ST, it just lands on a wacky video output. So what next?
But at least the Address Strobe (/AS) is working now. We see it repeatedly reading from memory as if it is executing code. So let's take a look at some data. Poking around at the data pins of the 68000 processor directly, things look ok. Of course, this data is (and should be) a chaotic scramble of program code reads from ROM, reads and writes to RAM, etc. So really, just looking that each pin has state changes, and that they look “clean.” The edges are reasonably sharp and the height is decent.
So, if the data signals at the 68000's data pins look alright at a glance, what does the data look like at the RAM chips themselves? Although the 68000 data pins connect directly to the ROM and other system peripherals, there is a set of buffers isolating the data path for the RAM and video generating “Shifter.” This is likely because the RAM must serve a second duty to provide video data to the hungry “Shifter” as it runs through the raster of the screen, and that traffic is kept separate from the rest of the system.
So, we look at the data pins of each RAM chip. All look reasonable – active and with good voltage levels – until we get to chip U34. Flatliner. I reflexively assume that the RAM chip is bad. RAM is “always” going bad, right?? Plus, look at that ratty RAM upgrade job. Well, spoke too soon. After replacing the chip, no change. Ok, that was a reasonable guess. (In fact, hey, the RAM chip could have been bad too, I guess.) But we now question what is stopping that line from operating like the others. The signaling from the 68000 side is coming through on the other data lines. So this isn't a control signal problem. After all, each buffer ship services eight data lines at a time. So likely one of the buffering chips themselves is the issue. With the oscilloscope, we notice no activity. If the octal latch (74LS244 at U26) that drives the signal to the dummy RAM location is trying to work, then you'd think you'd see some jostling of the voltage, even if another chip were shorted and fouling up the result. So we make another educated guess and replace U26.
This is done, and again nothing. The RAM side of the signal is dead. We took a break at this point.
When we resumed the next meet up, I looked at the recent work and immediately saw a problem. There were three 74LS373s in the buffer circuitry, but only one 74LS244. Something is not pairing up correctly. It was found that in the previous replacement, a '373 was mistakenly put in where a '244 should have been. The replacement chip was socketed, so the swap was easy enough. And with that, now we see data as expected on the RAM chip in question.
So after all these fixes, is it working yet? Nope. Of course not. In fact, it looks no different. We can now see that the processor is running, and we can see data on all RAM chips. But the screen is the familiar smattering of non-sense.
At that moment, somewhat out of desperation, I just started going over the signals into each RAM chip again. The reasoning was that there was this crazy RAM upgrade with the extra bank of chips glomed on. Could one of those chips be fouling up a signal? And that's when we found the next issue. The Column Address Strobe was dead. Kinda need that. So, tracing it back, that comes from the /CAS0H signal from the MMU. The wiper on the PLCC socket showed dead too. But, when we measured again by touching the pin of the PLCC chip directly, there the signal was.
So we removed the MMU chip from the socket and found the next revelation. The pins of the MMU were heavily corroded. With a fiberglass brush, we buffed up the socket wipers. The brush was totally ineffective on the pins of the chip, though, as they were so heavily crudded over. Some fine-grit sandpaper did the job, though.
We then put the MMU back in. And, yes, it booted right into the desktop environment. In the mean time, I had purchased a convenient Atari ST test cartridge featuring the ROM_TEST_KIT_FOR_ST_V4.4. That also run successfully and the tests came back clean. It passed all the tests!
Great success! A lingering issue, though, is that this unit is a 520ST. That comes with a standard 512kB factory. But with that insane RAM upgrade, it should have 1MB. The test cartridge didn't recognize or test beyond the factory 512kB. Was that because it didn't know about the extra memory from the configuration? Or was the extra memory not working? People were very happy to have a working system at that point, so this wasn't perused and the project disbanded. But we have room for a sequel.
One last detail: This system came with an interesting letter. Apparently it was provided for free by Atari with a hard drive to the user for evaluation.