How to repair a Galaxian PCB
This is the basic sequence I follow when fixing a Galaxian PCB. I’ve added some tips, some will only work on Galaxians, others may be useful for any boards. This does not go into the ultimate detail, it just gives outlines of where to look for problems.
Remove any patches
If the game has had any hacks applied to allow it to run an alternate game, or remnants of a previous repair, I remove them. I also check for the common memory map modifications, as these also need to be sorted before continuing (unless you are leaving the game as a moon cresta or similar which requires the hacks – just remember to check the correct memory address ranges!)
If I’m planning to put the hacked game back afterwards, I make sure I make notes of what I remove, so I can put it back on after it’s fixed.
Fill empty sockets
If there are any empty sockets or missing chips, where someone has used the board as a donor in the past, then I replace these first – it’s certainly not going to work without them.
Make a Loom
If I don’t have an adapter this type of board, then I make a basic loom up for testing. This has just has the power (5v, 12v and GND), the speaker and the video wired. We can add controls when we have the basic functions working on the board.
If the PCB is setup for AC, then you may need to convert it to DC before using it on your test rig (Depends upon your test rig – mine is DC only)
Insert a test rom
Test roms exist for Galaxian and Pacman, and possibly others. They are useful, since they don’t rely on the rom daughterboard working and these may have problems on their own. For a 2716 Galaxian memory test rom, click here, for a dedicated galaxian ram tester, see the ‘Test Board’ information on the menu at the top of the page. Remember to make sure that you have galaxian graphics roms fitted, since the test roms may make little sense with other graphics roms. (They definitely do not work with Moon Cresta graphics roms)
Power it up
Well, we now have enough sorted that we can try it out on the test bench, and see what it looks like.
No Screen Display?
If you get nothing displayed at all, then there are two main things to check out. Firstly is that you have wired it correctly, Secondly, use a logic probe to check that the onboard clock is running. The main clock is handled by 1D and 1E, The screen clocks are generated from the 74161’s at 3A,4A,5A and 6A. I usually look at pin 2 (clock input) and then pins 11,12,13,14 and 15 (outputs and carry out). If any of these are not pulsing, then you need to sort them before moving on to the next check.
Program rom
Now we need to check that program code is correctly mapped. How you achieve this depends upon the test equipment that you have. If you are using a test rom, then hopefully the test program started running when you powered the board up.
If you have a Fluke micro-system troubleshooter, then you can read address 0000, which in most test roms and even in the program code is usually AF. If this fails, I usually put the Fluke into ‘loop’ so I can use the logic probe to follow the memory select circuits and trace /CS (pin 20 on the eprom) to ensure that it is being selected correctly. You may also need to check that the buffer chip (8F and 8H or 9B *) is set for the correct direction and is not holding any lines high.
If you do not have anything like a fluke and the test rom does not startup, then you can still use the logic probe to check /CS on the eprom to see if it is being selected (signal goes low) when you start the board. However, in this case you will also need to perform the CPU checks detailed later.
Program Memory
If you are using a test rom of any sort, then all of the memory will be tested when you power up the board. If you get any ram failures shown, then you will need to check out the items listed under the relevant memory section. If the screen is garbled with duff characters so you cannot read the results of the test, then you can safely assume that the video ram is faulty and start with that check.
Using the fluke, I normally start by testing the program memory. This occupies from 4000-43FF and is directly connected to the CPU, so any problems here are usually down to the ram chips (2114’s at 7N and 7P), the buffer chip (8F and 8H or 9B *) or memory addressing. As a rule of thumb, if you get a few odd bit errors or decode errors, it’s the ram. If all locations have the same error but it’s not all bits, then check the connections and buffer. If it’s all bits in error then check the memory mapping! (a trick you can use if the ram is socketed is swop the ram chips over – if the bit mask of the error has reversed then it’s ram, if it stays the same, it must be buffers or connections)
Object Ram
This is the sprite and colour ram. To write to this the CPU has to go through the first of the buffer chips (8F and 8H or 9B *). To read the contents back, it also uses additional buffer chips at 4L, 4M and 5M. This occupies memory from 5800 to 58FF. A failure in this will normally be down to the ram chips (4F and 5F) or the afore mentioned buffer chips.
Video Ram
To access this ram, the CPU now has to go via an extra buffer chip (4J and 4K or 5J *) so if we do this last, we already know that the first set of buffers are OK. This occupies memory from 5000-53FF. A failure in this will usually be ram chips (3F and 3H) or the second buffer.
Now you need to either use the galaxian test program board, or you can put a set of galaxian roms on the board, since we are going to look at graphics, colours and sounds! If you made a partial loom earlier on, it’s also time to wire up the controls, since we are going to need those as well.
CPU Checks
If you still get a screen of rubbish, then there are some extra things you will need to check.
The first of these is the reset circuit. Reset (pin 26 on the z80) should start low when you switch the board on, and then rapidly go high. If it is pulsing, then the watchdog is probably kicking in.
If the game starts going through the self-test (various patterns on screen) but keeps re-starting the test, then the other line to check is the interrupt. (pin 16 on the z80). Now this is trickier to test, since it will only start pulsing when it is enabled by the software!
Normal cause of problems here are the enable latch (pin 5 of 9N) or the fact that the memory mapping for this has changed (some games move the interrupt enable, so check for linked pins or cut tracks)
Sounds
Well, now the board is running, we need to checkout the sounds – firstly, do you hear any sound? It’s unusual for all of the sound generator circuits to be dead, so silence usually means that it is wired wrong, the amplifier is dead or the potentiometer feeding it is broken. (some bootleg PCBs do not have the ‘speaker-‘ connected properly, so remember to check this first – for these boards, it should connect direct to ground)
For the individual sounds on the Galaxian board, here are the items to check if they are not working.
Tunes
This includes the coin insert noise, and the hit galaxian noise. If the board makes an annoying fixed tone as soon as you power it up, it’s this circuit as well. Chips used are a latch to hold the value of the tone required at 9J, two 74161’s to make the noise at 8K and 9K and this is then sent through 6T and 7R to control the volume. (7R is also used to switch the fire and hit noise, so if they are also missing, start looking there!)
Most common problem is that the tone generation circuit has been disconnected – check pin 2 of the 74161’s to make sure that a clock signal is being fed to them. This is often altered to change the pitch of the sound generated.
Fire
This is the noise made when you fire a missile at the galaxian horde. It is switched by the 74259 at 9L (pin 10). This charges the capacitor at C25, which in turn triggers the 4066 at 7R. To check to see if this is happening, use a logic probe at pin 11 of 7R, when you fire the signal should go high. Other chips to check are 7S and 7T. (7T being a common fault – this may also affect the hit and rack noise)
Hit
This is the explosion when your ship gets destroyed. Works in a similar way to the fire noise for triggering, coming from pin 7 of 9L, this time through C21 and onto pin 4 of the 4066 at 7R. Again, this can be checked with a probe.
Rack Noise
Now this is the nightmare part of the sound circuit!
Each of the three noises is made using an NE555 (8R,8S and 8T) which are fed from one central NE555 (9R). These are triggered by pins 4,5 and 6 of 9L. Additionally, the speed of the rack noise is controlled by another 74259, but this time using pins 9,10,11 and 12 of 9M.
If you get a static tone rather than the usual descending noise, then you will need to check out the transistors at Q1 and Q2 and the op-amp at 7T. If you have to fit anything other than the transistors that were in your board, make sure you have the pins connected to the correct place. Several bootlegs use transistors that fit in backwards to the silk print on the board!
Graphics
Now for the background graphics, galaxian PCB’s seem awfully hardy, I’ve not seen many with problems in this circuit, unless they were caused by some of the odd hacks that people have done in the past. If characters are wrong then check out 3J, 3K,2L,2K,2J and 2H.
Depending upon the exact graphic glitch you are experiencing, you may be able to narrow down the search, but trying to list every possibility here would take reams of text, and probably a fair number of pictures. Checkout the galaxian troubleshooting manuals for more information about this part of the circuit.
Sprites
Now if the rack noise was the nightmare part of the sound system, sprites are the equivalent in the graphics area.
Once each screen line has been drawn, the data for the sprites on the next screen line is written to the sprite rams (1N,1P,1R,1S and 1T). When we draw the next background line, this data is read back, and superimposed over the top of the background graphics. However, unlike most modern circuits, that have alternate buffers for odd and even lines (which is easier to understand!), Galaxian uses the same buffers and does some interesting tricks to make it work.
If any colours are missing or wrong, most common cause is the 27LS00 sprite rams already mentioned. Be aware that the pull up resisitors are only needed for some types of sprite ram, if you are getting problems then you may need to add these resistors (if not present) or remove them (if they are). These get so annoying that I made a small adapter board to allow a fast 2101 to be used in place of four 27ls00’s.
Other common problems seen within the sprite circuit are incorrect sprite drawn (check out 4L) or the top half or bottom half of sprite doubled up (check 3B)
again, for further information on this area, check out the Galaxian troubleshooting manual.
Missiles and Shells
These are drawn by similar circuits, with missiles at 4R,5R and 5P and shells at 4S, 5S and 5P. These are often hacked to change the size of the missiles.
Stars
These are switched by pin 9 of 9N, generated by 1A, 2A and 1B and then controlled using 2B to ensure that they only appear on the main part of the screen (not the borders). A common hack is to cut one pin 15 of 2B to prevent them from being displayed.
As mentioned at the start, this is not meant to be a comprehensive list of every galaxian fault, and how to fix it. For information on particularly tricky to find faults, check out my repair log, and indeed search on google, as many others also have parts of their repair logs available on the web.