Topic: Missile Command Repair Log  (Read 5113 times)

Author Message

0 Members and 2 Guests are viewing this topic.

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1190
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
Missile Command Repair Log
« on: October 29, 2012, 01:14:12 AM »
The final board I needed to fix from the ACMI exhibition was an Atari Missile Command board.

It ran in the exhibition for a good few weeks and then one day died, I had had it for a while and as the Exhibition closed yesterday and everything will be on its way to NZ in a matter of days they wanted it back, dead or alive, so I had to get my arse in gear. They had a second working board on site but only one CPU and ROM set between them, so when this one died the parts were swapped into the other board and I was presented with a load of empty sockets and an unknown fault.

The first job was to get it a 6502 CPU ...

...and some 2716 ROMs, both came from eBay and the first problem became apparent, my EPROM burner decided that it actually didn't like 2716s much and cracked the shits, depite me buying one of the brands it claimed to know about. It will blank check ok and will give the briefest impression it is programming them before the burner app locks up and I was forced to kill the process. This went on for a while with me tinkering with the programming parameters and ended up with a set of no-longer blank EPROMs and no progress at all. The next time I came back to it I gave up on in and left it in its crashed state, and after about 5 minutes it chimed back into life giving a "program failed" report. I have no idea why I decided to hit the verify button, clearly there was no point, but the chip verified correctly, it had programmed it after all. So I spent nearly an hour coaxing a full set of EPROMs out of the burner, loaded up the board and was greeted with a pulsing screen of rubbish...

...resetting over and over again. Grounding the test mode pin had no effect on the fault either.

After going over the board with the scope I was getting nowhere so decided that this was the time to buy the last of the 4 Fluke pods that are useful in arcade repair. I had the Z80, the 6809 and the 68000 pod but no 6502 version. I know a business in Melbourne that sells them for a semi-reasonable price so I fired off an offer and a pristine but untested one arrived in the post a few days later.

When hooked up to the master unit it passed the self test...

so was hooked into the board and fired up.

After disabling the active force line option to allow the pod to get past the fact the /Reset pin was bouncing it gave a clean bill of health to the system buses (i.e. all lines were drivable high and low).

This board uses the dreaded tri power 4116 DRAM chips that need +5, -5 and +12v to work properly, if they lose one of these power feeds even briefly the DRAM toasts. But the RAM on board passed the "short" RAM test fine.

Next step was to check if the CPU could actually read all the ROMs correctly, pulling up the memory map and the 9010A checksums from the site...

...allowed me to check each ROM in term from the perspective of a CPU sat in the CPU socket. Very useful as simply confirming the ROMs contain the right code doesn't mean the CPU can read them, any fault in the addressing logic, bus buffers, line drivers or ROM output enable logic can affect it. Good software that cannot be correctly read is about as much use as corrupt software that can.

The first four ROMs came back with the correct checksum, the lower two chips both came back with the wrong checksums so I suspected I was onto a fault with the PCB logic.

Sadly I wasn't but I wasted a great deal of time due to a single assumption. The assumption that even if one ROM was bad in a manner that made it misbehave when sharing a board with other ROMs it would be very unlikely that two ROMs would be similarly affected. Especially a pair from a random batch bought online the just happened to end up next to each other on the board while all the others from the batch (both on this board and the early Defender repair) just happened to be fine. By only testing these two ROM sockets with this pair of ROMs I found that both chips have continually changing checksums when read in either socket, both solo or as a pair. So I went off on the wrong path looking at the schematics and suspecting a single 74LS244 that only deals with the bus solely from this pair of chips. I even re-read the chips on the PC again to confirm they still contained the right data - they did, which reconfirmed my mistake.

The mistake was that both ROMs were still not proven to work on this board, so using only those two in testing was guaranteed to miss one scenario, that they were bad enough to fail on the board, but good enough to behave on the burner.

The fact that the returned checksum differed almost every time I read it also made me suspect the old single wipe sockets, so these were removed and new dual wipe installed.

This changed nothing  and the PCB went on the back burner for a while as I couldn't find anything actually wrong with the board using the scope.

When I looked at it again I had forgotten my "can't see the wood for the trees diagnosis" and decided to move ROM 4 into socket 5 with socket 6 empty. I then read the data from ROM 4 out of the locations that socket 5 maps to. I got a perfect read! I did the same on socket 6 and again got a perfect read of ROM 4. There was nothing wrong with the board at all, those two chips were the cause of all this. Despite reading fine on my burner, and despite the hugely unlikely scenario that a pair ending up next to each other on a board out of a batch of 12 were the sole bad ones, they actually were.

Scavenging a pair of 2716s from my box of crap I repopulated sockets 5 and 6 and re-ran the fluke ROM test, in both cases I got a the correct checksum back. I was finally back to the state the board was in when it died at ACMI.

The board now booted to the old screen of crap, which cleared to a blank white screen, that pulsed black from time to time. At one stage and for a very brief moment I got the Missile Command title screen before it flicked back to blank white.

Putting the game into test mode got me the following... took a long while for the image to stabilise as it was flashing on and off for a while and it was inverted, but at least the board reckoned the RAM and ROM were ok. It now looked like a fault in the video circirty and that the board was actually running for at least some of the time fairly stably.

Poking around the board with the scope I found a 7474 chip at F7...

...that looked very unhealthy, the complementary outputs were very ragged and didn't seem to be complementing each other some of the time. It failed the logic comparator test badly.

Replacing this chip gave me this..

... and the gradual removal of the title screen with explosions...

and finally attract mode...


As I don't have a track ball or the Atari AR board I couldn't test the controls or the audio output, so I swapped it into the cab when I dropped it back to ACMI, it worked perfectly.

Good for another 33 years, well maybe!
« Last Edit: October 29, 2012, 01:51:55 AM by Womble »
Sic Transit Gloria Atari

Offline AndyRCM

  • >=))))º> GO FEED THE FISH! <º((((=<
  • Administrator
  • Amiga 4000
  • ******
  • Posts: 9660
  • Kudos 50
  • Gender: Male
  • Manic Jet Set Willy
    • View Profile
    • Retro Computer Museum
Re: Missile Command Repair Log
« Reply #1 on: October 29, 2012, 08:23:06 AM »
Another great fix mate . . . great to see a board that we all love (?) being brought back to life . . . great game! :)

"I could see the faces of those who led pissing themselves laughing" - Funeral Pyre by The Jam