DISCLOSURE: As much as I wish I had good enough repair skills to be able to solve this on my own, I openly admit I got some expert help along the way.
One of the final tests I do before I would call a board "tested/working" is running a long duration test. For raster games I like to run them for 8 consecutive hours. This board was working and had passed all my other tests. I check in every hour or so to be sure it hadn't reset and I play a game and run the games' self test, making sure everything is working. I checked on the board at 4 hours and all was good. I got distracted and forgot about it and didn't check again until about 9.5 hours. At that point I was presented with this:
Well, that's disappointing. It was late in the evening, so I recorded the above video and turned everything off for the night. I sent the video to a few friends and they (as I also did) immediately zeroed in on it being a sync issue.
The next day I went to check things. Now the game won't even boot up. Just get a white screen. Game will not go into self test. Disappointing to the next level now.
FYI, a few months ago, I started using Fred C.'s most excellent FPGACATBOX (CAT) tool. It allows me to test and diagnose things far above my electrical engineering knowledge (which is basically zero, but I'm trying hard to learn).
I figured back to basics. I put it on the CAT to check ROM and RAM (even though it had run fine for four hours just yesterday).
RAM all passed on the CAT. Missile Command boards come in two flavors, 11 ROMs and 6 ROMs. This was a 6 ROM version, with ROMs at locations H1, JK1, KL1, LM1, NP1, R1. On the ROM test, the CAT reported H1, KL1 and LM1 ROMs bad (and JK1, NP1 & R1 ROMs good).
I did the typical things if a ROM is bad, I cleaned/brushed the legs, I verified the ROMs. I checked the sockets. I was fortunate to have another working board, so I cross tested the ROMs between both boards. The good board ran fine with the ROMs from the bad board and the bad board still tested the same ROMs bad when using the good board's ROMs.
Just about the same time I started using the CAT, I also starting learning to use a (very intimatating to me) oscilloscope. (I'm learning and I'm picking up a few things, but with no electronics background, it's coming along slow). A friend suggested to put the board on the CAT running a repeating ROM test. Use my scope to check the chip select signals (pin 20) on all the ROMs.
On the scope I got an active chip select for ROMs H1, KL1, LM1, NP1 & R1. I got a steady (stuck) low on the chip select for JK1. To quickly summarize: CAT reports ROMs JK1, NP1 & R1 good; and H1, KL1 & LM1 bad. Scope reports chips select on JK1 bad and the rest good.
My buddy suggested checking/scoping the source for the chip select on JK1. The schematics show IC J6 (7408) pins 1 & 2 as inputs and pin 3 as output going to the chip select pin (20) of JK1. Sure enough, both input pins showed an active signal on the scope. But the output (pin 3), was stuck low.
I desoldered J6, socketed and replaced the 7408 @ J6. At this point all the ROMs pass on the CAT! I pull the board off the CAT and pop the CPU back in. Board fires right up. Since the original sync-looking issue didn't occur until sometime after 4 hours yesterday, the next day I ran a long duration test again, this time 12 hours to be sure. Everything passed ok. Board fixed!
I have two theories here. One, I think the sync looking issue was only because the game got stuck once J6 went bad and left the screen in the last state while being continually distorted by the constantly active JK1. Two, I think the CAT reported bad ROMs around JK1 because the stuck active JK1 signal distrupted the testing of the other ROMs.
Conclusion: In the end, an easy fix to a kind of tricky misleading problem presentation. Hopefully someday I'll be able to find and fix these on my own.
END