Tag Archives: midway

Ms. Pac-Man with no “Sprites” (Ghosts, Ms. Pac-Man)

So, a gentleman reached out to me right before my fusion surgery asking me to have a look at his Ms. Pac-Man game. It was not showing sprites but was otherwise behaving correctly – it passed self test, and you could still see dots being eaten during attract mode, etc.


Initial instinct was something wonky with the VRAM Addresser Board, so I gave him a known good one and sacrificial socket to test with, but this produced no change. He dropped off the board and I gave him one of my spares so he would be able to at least play his game while I was in recovery.

When I was able, I took a closer look at the board and did not see anything obvious as far as lifted traces, bent pins, etc. I looked at all of the troubleshooting information and repair logs that I could find, including the Mowerman docs, but none of the solutions for the same identical problem seem to apply here.

Using the troubleshooting guide for some theory of operation info, I started working my way from the Attack RAMs all the way to the video output. I eventually stumbled upon a 74LS161 @ 1E whose outputs were not following its inputs: they were essentially floating.

I piggybacked a replacement ‘161 on top of it:

– and this made the game draw the sprites correctly, so it was a simple matter of clipping the chip, desoldering its pins, putting in a socket, and sticking in the replacement ‘161.  After that, I confirmed the sprites returned and were behaving correctly.

Board repaired, and a new(?) solution for the “missing sprites” problem.


As it turned out, the board that I let him borrow happen to have the Doc Cutlip cheat on it where you hold the one player start to become invincible and the two player start to go fast (or vice-versa?) and he liked it, so I planned to put that on his board before I gave it back to him.

Originally I was going to erase and burn his existing 2532 @ 6F that was already on his board.  But even though it erased correctly, it would not program consistently and would fail verification at different (progressive) locations. I tried another erase/burn cycle and got the same behavior so I binned it and burned one from my stock and used it instead.  (Working versions of these EPROMs are getting harder and harder to find without breaking the bank.)

Dead Gorf

So I found a dead Gorf on Craigslist.  It was an older ad, but was still available when I inquired.  Dude I picked it up from had done some pretty impressive restorations on some other games.

Anyway – it was dead alright.  Shows a blank screen that looked overly blue due to how the monitor was adjusted, no starfield was visible.  Slid the test switch over and power-cycled, but this made no difference either.

The previous owner had mentioned that he had done some work on it.  I saw some of his other previous work on other boards of his and while not perfect (some cold joints, or not enough solder in some places leaving “pits”), it was not horrible and definitely no worse than what I was doing when I started out.

Anyhoo, starting with the power PCB – the previous owner said he had already replaced the caps, but I wanted a second look at it, JIC.  On the solder side of the board, some larger traces has been lifted off the board during some previous repair work (I do not think it was his, maybe someone before him?).

It looked like the someone used a serious soldering gun to do the work, because there were scorch marks on the board(!) and flux was all over the older work too.  Continuity was where it was supposed to be, so I guess that while it was ugly, it worked. Continue reading Dead Gorf

Galaxian – “Dead”

Purchased described as “dead”. Started by creating a JAMMA adapter (I hate creating adapters, it is tedious work). Well, the description was correct – she is dead alright: screen has static garbage and required some tweaking to sync correctly on my test bench monitor.

Watchdog is barking, disabling it has no effect on the screen’s contents. Board already had some previous work done in it, solder-side contains more than 20 jumps to connect some RAMs back onto the bus. The Parts side shows the missing/removed/blown traces being jumped.

Started by checking the daughterboard, seems OK. Next I remove, socket and replace the 74LS245s on the board because word has it that they tend to be the cause of most problems, the Galaxian Trouble Shooting Logic Board manuals lists similar symptoms connected to those chips, and the Fluke 9010 troubleshooter says that the address lines are tied. Other than that, I cannot come up with a good way to check them! 🙂

Gotta wait for some replacement sockets and chips to come in…

Continue reading Galaxian – “Dead”