Aliens Repair Logs
Forum Thread: Aliens PCB Repair
Symptom: Main sprites are either breaking up and parts randomly appearing all over the place, or main sprites okay but whole or complete pieces of other sprites randomly popping up
Diagnosis: Self test didn’t indicate a RAM or ROM problem, but determined that the outputs of the 6116 ‘skinny’ RAM at location I3 were intermittently flaky. That RAM later started to show up in the self test as faulty
Cure: Replaced 6116 RAM at location I3
Symptom: Parts of the letters missing on the text of the self test screen, plus ‘sparkles’ appearing in the graphics along with variable sprite faults
Cure: Some poorly connected pins on the surface mount Konami custom ( 051962 ) at location J16
CA324 amp at location C11 is for the in game music
CA324 amp at location C6 is for the speech and sound f/x
... I had a faulty Aliens in my scrap pile that I paid far too much for so I was keen to get another couple to compare with it. The first board was almost fully working, the only fault was that the sprite graphics were a mess.
By far the most likely candidate was the mask ROMs, so I flipped switch 3 on Dip Bank 3 and put it into test mode. The test it performs on boot up is only a quick test of system RAM and ROM, it ignores the mask ROMs entirely. After a few minutes thinking about it the board came back with the report that K2 was bad.
...and as I know these are pin compatible with 27c400 eproms I tried to dump on my eprom reader, it reported that a number of pins were AWOL and the resulting dumped data was not recognisable. So in went a 40 pin socket and a 27c400 EPROM burnt with the data k02_b09.bin from the MAME set.
After setting the test switch back to "off" and rebooting the game it ran perfectly.
Forum Thread: Aliens PCB Repair
The second board was properly dead, it gave a blank white screen that flashed every second or so, which is the watchdog timer circuit constantly bumping the CPU's reset line to try and get the board to boot. Its purpose is to monitor the buses and if there is no activity after a certain period of time it will briefly pull the /RESET line on the CPU low to initilalise a reboot. It is to stop a crashed board sitting in a cabinet unable to take money and burning whatever image is on the screen into the tube. On a faulty board however it will keep trying for ever even when the fault means it has no hope of success.
This board wasn't in quite as good a condition as the previous board, there were some scuff marks on the solder side and some scratches across some tracks. These all were superficial damage as none of the tracks had been cut. There was also some signs that someone had attempted a repair by the sprite SRAM chip in the top right corner of the board. There was a lot of scratching between one of the Konami custom chips and this SRAM chip, and what looked like an attempt to resolder the pins on the custom itself.
The pins on the custom chip looked like someone had run a dry soldering iron over them in an attempt to fix any dry joints. Although this looked ugly it wasn't going to stop the board from booting.
First thing to do was the dump the ROMs, on these boards the two system ROMs for the main CPU code are socketed and are a 27c1001 and a 25c512 chip, the 27c512 tested fine but the 27c1001 chip at C24 gave a bad read. I tested the same ROM off my really scrap Aliens and it read fine so I dropped it in. The fault remained unchanged.
Having a working board meant I could determine which RAM chips did what by shorting a couple of address bus lines together and watching what goes wrong.
If it turns out to be a graphics SRAM chip then the gfx gets corrupted, if its a palette SRAM chip then the colours go wonky, and if you hit the system SRAM then the board crashes.
As the board was not booting then fault is likely to lie between the CPU and the system RAM, it could be the CPU itself, the system RAM itself or any of the logic and tracks that are involved in running the bare bones of the game code. The CPU on this board is a somewhat mysterious 64 pin Konami custom chip marked "052526". It's the black square FPGA chip by the two program ROMs.
There is no pinout for this that I could find, and no schematics for this board, or any other Konami board that uses is. Quite what this chip is I don't know, the most obvious guess would be a 68000 core, possibly with a non standard pinout to confuse anyone trying to bootleg the board. Normally with a board stuck in watchdog you would hit certain CPU pins to confirm that the board was actually letting the CPU run, but without the pinout I was slightly stuck. All I could do was to go over the reverse of the board with the scope looking to find a clock signal on one of the pins and also trying to find the /RESET line which was going to be pulsing in sycn with the board resetting. Both of these I found and they looked health so it looked like the fault was not simply that the CPU had no clock or was actually stuck in reset. There are other lines to check but these I could not guess at so I had to assume they were OK and move on. What I could do was test the continuity between the System RAM and the CPU on all 16 address lines. As I knew the system SRAM was a 6265 chip I could work out where the address pins on the CPU were, and also confirm that they were all connected up, which they were.
So moving on the data pins of the system SRAM, thats where things started to look bad, on 5 of the 8 pins everything looked healthy, but on three the logic levels were often very low, nowhere near the 4-5v difference they should be. In most cases you would suspect the SRAM chip itself but upstream of this was a Fujitsu 74LS245 chip acting as the bus transceiver.
Even tho the DIR signal looked healthy and the B side of the chip seemed ok, the A side had the mangled signal on three of its pins. So it was either the 74LS245 or the SRAM. In this case the Fujitsu TTL was the more likely of the two, so I pulled it and tested in in my EPROM reader...
The board booted and promptly failed its RAM/ROM tests - on ROM C24 - the ROM I had taken off my scrap board and tested just before was now bad. I did a quick check of the ROM socket to see if there was 5V anywhere nasty which would explain the sudden death but it all looked fine. So I pinched the C24 ROM from the board I fixed beforehand and fired it up again.
The main character was often only a pair of legs, the enemies where pretty messed up and any animated sections in the background that happened to be sprites were a mess.
The obvious place to start was with the scratches by the custom chip, the MCM2018 was also a fairly likely candidate itself so I took it off, firstly to test it and secondly so I could see where the tracks that went under it ended up. I had tried to buzz through to all the vias on the underside but a positive test proves you are in the right place, a negative means either you have a fault or are not where you think you are, or you can't get a good connection due to oxide or lacquer in the via.
A bit fiddly, that's a 5 cent coin on the custom for some idea of the scale, but it's the neatest option.
The scrap Aliens board is still scrap, have found and bridged 5 open circuit tracks around the CPU and it is still firmly dead, I may get back to it one day but I may not.
Repair Logs converted to wiki format by Brad from Aussie Arcade.