Atari ST #2 Repair

So the first step was a long and tedious date with the solder sucker to clean the through holes and install sockets at those nine positions.

In my inventory, I found the needed 41256 (1-Bit x 256k) DRAM chips – and took 9 of them. Funny enough, I had been sloppy in counting and thought only eight were needed. But I fortunately did grab one extra. (I know to expect the unexpected.) The next step, of course, was to install these chips. They were 150ns versions, since that matched what was already in place on the board.

I got out my Atari SM124 High-Resolution Monochrome Monitor. I'd happened across it a couple years ago along the random journey of life, and, since the price was good, I picked it up. Of course, I didn't have an ST at that time, nor a particular plan to get one. But now I have it, and I plugged it into the machine.

Next I found myself an authetic power supply. Being somewheres around 40 years old, I was first sure to test that. The +5, +12 and -12 supply rails were looking ok unloaded. So I plugged that into the Atari ST.

And finally, the time had come. I flipped the switch and powered on the ST. Nothing. Waited. Still nothing. Waited a bit more. Alright, more troubleshooting fun...

With the oscilloscope, checked the operation of the /RESET and /HALT signals to the 68000 processor. Each was good.

Next looked at CLK pin of the 68000. I would expect an 8MHz square wave (ideally) there, but, ah ha, just floating at 3V. There is no clock.

Looking at the schematic (non-modulator version for this machine), the clock originates at 32MHz from a crystal oscillator and feeds first into “shifter” video generator chip.  Indeed, I measured 32.0425MHz coming in at pin 2, and a “16MHz” output at pin 39 measuring 16.0213 MHz.  Tracing it along, I then successfully measure that same signal fed over to pin 5 of U15 (MMU).  But from the MMU at pin 19 for “4MHz” and pin 20 for “8MHz” there is no clock.  It is the floating 3V signal, the same dead signal I saw at the processor.  Now suspicious of the MMU chip, I probe along the various /RAS and /CAS lines and other outputs.  They all seem dead at 3V, just like the “8MHz” clock.  Conclusion, the MMU chip is dead.  Quite dead, in fact.  So I did the basics:  plucked it out of the socket and cleaned the pins, inspected, reinserted.  All looked ok physically and shouldn't have been a problem.  Tried again and still nothing.  Then I measured that the VCC and GND power supply pins were actually making sound connections.  They were.  Let's call it a day.

So I ordered a replacement MMU.  Got it from Best Electronics out of San Jose, CA.  Although it was a simple enough order, it was a good experience.  I would recommend them.

A cute little box arrived at my door, and I had my new MMU.  So I reopened the ST to install it.  But to my dismay, the part number of the chip I received did not match what was in the system.  For an instant, my emotion ran high.  Was this the wrong chip sent??  But after a second I had another thought.  There are two identical looking 64-pin PLCC chips in the machine.  They are the MMU at U15 and the GLUE at U12 chip.  This was clearly an abused parts machine.  Could those have been swapped for some reason?  Well, indeed, the MMU part sent to me did match the chip in the GLUE socket.  I then looked up photos of the ST board and confirmed, yes, the chips were in the correct orientation but their positions were exchanged.

My mind rallied.  Could it be as simple as swapping these chips back to the proper locations?  But were they damaged by being connected in the wrong sockets?  They were only +5V chips, and usually those can be somewhat forgiving.  And I have the new MMU anyway.  But what if the GLUE chip is damaged?  Another order to Best?

As my brain churned on all of this, I quickly swapped the chips back.  Then I turned the unit on and once again checked the 68000's CLK line.  And, whadda ya know.

Now, we have the 8 MHz clock, just as expected!  That's a good start, but is it actually running code.  To check that, I next hopped the oscilloscope probe over and looked at the Address Strobe (/AS) line.  This is a signal from the 68000 processor to indicate to proceed servicing a bus cycle.  And indeed, it looked good.

So, it is just working??  I reattached the monitor, and, well, the answer is, “Oh, Yeah.”

This ST, apparently, is an old one.  It came with two boot ROMs installed at U4 and U7, with the other four IC sockets for ROM empty.  Story goes that when the first ST units shipped, the internal ROM software was not yet ready.  So the decision was made to have this software load from disk instead.  This allowed additional time for software development without delaying the release of the physical machines.  Later, as the software matured, the ROMs would include this software, so it did not require the boot disk (or the RAM needed for this software).  Let's give this machine that upgrade.

We start with a quick search of the internet for the Atari ST TOS.  Version 1.4 sounded like a good option for my 520ST, with its 512kB of RAM.  Looking at the number of address lines present on the ROM sockets, these had footprints like 27256 chips (JEDEC standard).  I happen to have a lot more 27512 EPROM chips around at the moment, and the difference between the two chip types electrically is an additional address line required for the latter.  Turns out that pin (pin 1) on the ST board is connected to a fixed +5V, making that highest-significance address bit a constant 1.  So essentially the 27512 will work fine but be limited to addressing only the upper half of its memory.

So we create the ROM image files accordingly.  Conveniently, on-line the TOS data was found already divided up among the respective six ROM chips.  The downloaded file was called "TOS 104 split.zip" and unzipping it yielded the necessary files for the six sockets, labeled U2 through U7.  Each of these files was 32,768 bytes in size, consistent with the capacity of a 27256 256-kilobit (32-kilobyte) chip.  .Since we are substituting 27512 chips with double the capacity (and the upper half is what will be active), we can simply duplicate the data.  At the Linux command prompt, this is accomplished simply with the commands:

The freshly burned chips were popped into the Atari ST and power was switched on.  Initially the display blanked to white, but then hung indefinitely.

The test cartridge with "ROM_TEST_KIT_FOR_ST_V4.4" was installed into the cartridge slot, and running that test signaled something curious.  The ROM checksum test failed for ROM L0.  This corresponds to chip U7.  So that ROM chip was replaced with another that was programmed with the same U7 ROM file.

After doing that replacement, the unit not longer showed the problematic ROM L0 in the checksum test.  In fact, it was able to pass all internal tests continuously running via the "Q0" command.

Next, the test cartridge was removed, and it was powered again.  And after a suspenseful moment with the initial white screen, it indeed showed the little bee mouse cursor as it booted.  It then landed nicely on the GEM Desktop.

My little repair project ST doesn't have the luxury of a mouse, but fortunately Atari equipped us for this situation nicely.  Natively, the arrow keys move the mouse cursor when the Alternate button is pressed.  And similarly the Insert and Delete keys can serve as the left and right mouse buttons.  So I was able to navigate the pull-up menus.  Checking out the About box was a nice closing milestone.