Galaga Video Problem

Vraz

Member
Joined
Aug 23, 2008
Messages
135
Reaction score
2
Location
Minnesota
I have a pair of dead Galaga pcb sets (real midway, not clones) from which I trying to revive one. Not having a working set for reference, I don't have a good comparison point, but am making some progress. After replacing the 74128 on one of the PCB boards, I got it up and running. Logic probe testing indicates that its accessing memory, reading the dip switches, etc. However, I could not get any video. After pairing up with the video board from the opposite set, I finally got the images shown below.

It looks like the unit is probably trying to do its self-test, but the screen is mostly garbage. The most telling characteristic is the "banding" of the character generator. You can see it in both attached pictures. In the first, the non-character area has the starfield generator (which appears to be working fine). In the second, the non-character area is pure white and the characters generator area contains more random looking symbols than the zeroes in the first image.

I have already cleaned and reseated all the socketed chips and swapped the 07XX and 04XX customs between the two boards (which didn't make a difference).

Appreciate any suggestions on where to look next!

galvid1.jpg

galvid2.jpg
 
I have a pair of dead Galaga pcb sets (real midway, not clones) from which I trying to revive one. Not having a working set for reference, I don't have a good comparison point, but am making some progress. After replacing the 74128 on one of the PCB boards, I got it up and running. Logic probe testing indicates that its accessing memory, reading the dip switches, etc. However, I could not get any video. After pairing up with the video board from the opposite set, I finally got the images shown below.

It looks like the unit is probably trying to do its self-test, but the screen is mostly garbage. The most telling characteristic is the "banding" of the character generator. You can see it in both attached pictures. In the first, the non-character area has the starfield generator (which appears to be working fine). In the second, the non-character area is pure white and the characters generator area contains more random looking symbols than the zeroes in the first image.

I have already cleaned and reseated all the socketed chips and swapped the 07XX and 04XX customs between the two boards (which didn't make a difference).

Appreciate any suggestions on where to look next!

On a Williams board I would be looking in the address generator for a dead or partially dead 74161. I sure you have a similar type problem here. The question is: what circuit generates the screen location?

Hope this helps,
Saltbreez
 
Check the reset pin on the CPU. It it's pulsing then that means the watchdog is barking which means it's a program ROM access issue.
Could be a problem in the ROM addressing circuity, datapath circuitry or bad connectivity of the ROMs themselves (reseat the ROMs and CPU to check).

If the reset is not pulsing then you should be able to play the game blind which means it's a graphics issue. You'll need equipment to properly test that stuff out....
 
>> useful info on that site....there is a section in there about what to do if you have those zeros..

Yes indeed, I have been using it as one of my references. Very useful material. In the case of the zeroes, its more a reference in passing and does not appear to correspond go my particular problem.

>> On a Williams board I would be looking in the address generator for a dead or partially dead 74161. I sure you have a similar type problem here. The question is: what circuit generates the screen location?

I am sure there is an address component to it. The NAMCO based boards are very complex because they composite multiple video sources together to create the image. Thus, there is a significant amount of address generation/processing in lots of different places. Much more complex than say Defender which uses a single frame buffer and does all rendering in software.

>> Check the reset pin on the CPU. It it's pulsing then that means the watchdog is barking which means it's a program ROM access issue.

Reset was working fine (though I should double check it with this video board). I confirmed POR, WDR and RESET were all working before even messing with video. I was also able to detect that the ROM code was reading the DIP switches (by changing the DIP switches, I could alter the pulsing on my logic probe). However, I did all that testing before swapping video boards (and the images are from the second video board).

---

Experimenting further today, I made two major discoveries:

#1-- The "opposite set" video board I initially tried was doomed to fail because someone had replaced the 00XX and 02XX custom NAMCO chips with 08XX and 06XX custom chips. It never occurred to me to verify that the right chips were in the right sockets. Someone more skilled with Legos (where if the block fits, its all good) apparently attempted to "fix" this board sometime before I acquired it. Replacing those with the proper custom chips brought up an empty screen with just the star field (versus no video at all previously).

#2-- Swapping to the "opposite set" CPU board gave a clearly displayed RAM error (one of the 2114s). Fixing that got me to "RAM OK" at which point the game effectively hangs (the star field keeps moving, but nothing else). Still, its much further than with the other CPU board which was clearly less "fixed" than I believed. So the strange video garbage I posted was due to CPU board issues after.

So at this point, the game comes up, performs all its testing with a video display very similar to what I see in MAME and then hangs at "RAM OK". Tried playing with the voltage a bit, but that didn't help (am using a switcher). One issue is that if I tap the boards (particularly the video board), the game will reset. Suspect I have a bad solder joint somewhere which is certainly not helping things. Will try to resolve that next and then figure out why I am stuck at "RAM OK".
 
Try swapping out the 00xx custom IC as well.

Then start checking the address buffers at 1L, 1M and 1N. That looks like it could be an address line issue.

You could start by pulling out the 00XX, which will stop the normal character display, as it's the video address generation but there won't be anything other than CPU1 on the buffered address bus during the first part of the self test. So you should see the address lines into 1L. 1M, 1N pulsing and pulsing on the output side too. A0-A10 should all pulse during the self test.

The graphics on the self test pic look a bit funky too, so make sure the 08xx at 2J hasn't got a bad socket. Check all the bits on the buffered databus are pulsing too. 2L is a good test point too as DB0 -> DB7 are nicely in a row on pins 20-27.

- James
 
somewhere which is certainly not helping things. Will try to resolve that next and then figure out why I am stuck at "RAM OK".

That can happen when CPU2 or 3 aren't starting up correctly and sending the 'ok' signal back to the main CPU.

Check if CPU2 and 3 reset lines are being pulled high, then check the 08xx's at 2H and 2E.
9/10 I've found bad sockets, missing pins for the 08xx for the sub-CPU when you get stuck at the "RAM OK" message.

There's also the chance one of the sub cpu's at 4J and 4E is just dead.

- James
 
Before you go too hog wild, do yourself a HUGE favor and replace the ROM and CPU sockets with good quality dual wipe sockets.

Those sockets on the Galaga boards suck bad and are notorious for bad connections. You'll chase your tail in circles trying to find problems that were simply bad sockets.
 
Try swapping out the 00xx custom IC as well.

Then start checking the address buffers at 1L, 1M and 1N. That looks like it could be an address line issue.

You could start by pulling out the 00XX, which will stop the normal character display, as it's the video address generation but there won't be anything other than CPU1 on the buffered address bus during the first part of the self test. So you should see the address lines into 1L. 1M, 1N pulsing and pulsing on the output side too. A0-A10 should all pulse during the self test.

The graphics on the self test pic look a bit funky too, so make sure the 08xx at 2J hasn't got a bad socket. Check all the bits on the buffered databus are pulsing too. 2L is a good test point too as DB0 -> DB7 are nicely in a row on pins 20-27.
This is great information. Once I get the current board set working (since its much closer to success), then I will these suggestions on the other video board (connected to a then known-working CPU board). Note that I only have a single 00XX chip so no ability to swap, but based on its performance in the set which gets to RAM OK, its clearly working.

One issue is that if I tap the boards (particularly the video board), the game will reset. Suspect I have a bad solder joint somewhere which is certainly not helping things. Will try to resolve that next and then figure out why I am stuck at "RAM OK".
So I resolved the "tap the board and get a reset"-- turned out the 54XX sound generator had a marginal connection. Tapping it would reset the game. Just removed, cleaned and reseated it and that problem went away. Now I can get to "RAM OK" all day long. One curious thing on "RAM OK"-- sometimes it shows it on the left side of the screen and other times the the right (like FLIP is random). It also seems random whether the star generator is on or off.

Check if CPU2 and 3 reset lines are being pulled high
RESET to CPU2/3 is low and I can see it pulse high/low right at RAM OK which I assume is the main CPU is resetting the sub-CPUs (and then waiting forever for the ok back).

... then check the 08xx's at 2H and 2E. 9/10 I've found bad sockets, missing pins for the 08xx for the sub-CPU when you get stuck at the "RAM OK" message.

Removed, cleaned and reseated with no change. I could swap these with known working from other boards, but didn't do that yet.

There's also the chance one of the sub cpu's at 4J and 4E is just dead.
I am definately seeing strange activity on the CPU pins. It looks like the CPUs are frozen and waiting for something. Here is the pin data: /M1=high, /MREQ=high, /IORQ=high, /RD=high, /WR=high, /RFSH=high, /HALT=high, /WAIT=high, /INT=high, /NMI=low on 4E high on 4J, /RESET=low, /BUSRQ=high, /BUSAK=high, clock=good, +5V=5.01V, A0-A15=tri-stated, D0-D7=tri-stated. Have not tried to swap the Z-80s yet, though especially with 4E where NMI is being held low, I wonder if that is stalling the CPU. Back to the schematics...
 
Replace the CPU and ROM sockets on the CPU board.

If the 2nd and 3rd CPUs cannot start properly then you'll get the RAM OK screen then a reboot. The board will do it repeatedly.
 
Replace the CPU and ROM sockets on the CPU board.
Unfortunately, I need to order some sockets. I have lots of 300 mil in different pin counts, but my 600 mil stock is very thin at the moment. Will order a bunch this week. In the meantime, I decided to test the other two CPUs by swapping with the main CPU since that was confirmed working and the power-on test makes a good CPU test. Swapped the main with 4E and low and behold, the board came up completely! Am guessing that the handling and reseating of 4E probably "fixed" it. Will just replace all the CPU sockets once I get some in.

So at this point, the board set is running happily without any graphics issue. Since its just on my test bench, I don't have a way to play at the moment. One thing is that I don't seem to have any sound. I clipped a speaker to C23/C24 thinking that would provide audio feedback, but not getting anything. Maybe I read the schematic wrong or there could be a different issue. Its always cool to see boards "back from the dead". Once I sort out the sound issue, then I can use this set to help revive the other. Always tons easier when you have one good set to work from.

Thanks for all the great feedback and assistance!
 
So at this point, the board set is running happily without any graphics issue. Since its just on my test bench, I don't have a way to play at the moment. One thing is that I don't seem to have any sound. I clipped a speaker to C23/C24 thinking that would provide audio feedback, but not getting anything. Maybe I read the schematic wrong or there could be a different issue. Its always cool to see boards "back from the dead". Once I sort out the sound issue, then I can use this set to help revive the other. Always tons easier when you have one good set to work from.

Thanks for all the great feedback and assistance!

I would be interested to hear more about the diagnosis on the sound circuit. The sound is dead on my Galaga board (explosion + normal sounds).

congrats on finally getting the video resurrected :)
 
Last edited:
I would be interested to hear more about the diagnosis on the sound circuit. The sound is dead on my Galaga biard (explosion + normal sounds).
Using my detective skills, I looked more closely at the board. "Hey, what is that empty 7-pin SIP outline at 7C", I thought to myself. An inspection of the schematic revealed my answer-- that is where the MB3730 audio amplifier should be. Doh! Curiously, both of my completely unrelated CPU boards have had the audio amp removed. Not sure if this is a common failure component or what, but obviously I need to order some replacements before doing much more. (If I get anxious, could probably connect an external amplifier for testing purposes.)

So some of the best learning from all this has been-- make sure the right chips are in the right sockets and make sure all the components are actually on the board (especially non-DIP components which can be easier to miss). ;)
 
I would be interested to hear more about the diagnosis on the sound circuit. The sound is dead on my Galaga biard (explosion + normal sounds).
I was able to verify that my sound was working by running the un-amplified output to a pair of amplified computer speakers. I just connected to ground and to the non-ground side of C19 (or you could connect to pin 1 of the MB3730). Note that I had to turn the gain up all the way on both the CPU board (that little pot) and my speakers, but got good clean sound (including explosions). In my case, I just used alligator clips to the mini-phone-jack connector on the speakers so nothing exotic.

In your case, since both sounds+explosions are dead, I would suggest this same test. From the schematic, it appears that sounds and explosions are generated independently and only combined at the amplifier. Thus, that seems like one of the few failures which would impact both. Given I have two boards with the audio amp removed, I am wondering if its failing is not uncommon. If you can hear the sounds with an external amplifier, that would tend to indicate your audio amp is dead.
 
Back
Top Bottom