Board booted to garbage on screen. Logic probe quickly showed the main CPU was not running (no activity on data or address bus). First thing to check is a clock signal is reaching the CPU and this seemed fine. Next up is to check the CPU isn’t stuck in reset – and this wasn’t fine. The reset pin was stuck low – this means the CPU wasn’t even trying to run as it was being held in reset state (the reset on most CPUs works by pulling the line low for a little while, then releasing it to high).
There are no schematics available for this PCB so tracing where the lines go was the next step. In fact it turns out the reset line goes all over the place on this board – the main CPU reset is shared with the sound CPU, the Yamaha synth chip and several other components. The common source is the LS10 chip at E11. The actual reset is generated on the lower board by a PST518 as is common with this era and this too traced to the input pin 1 on the LS10. The logic probe on the LS10 appeared to show valid inputs, but no outputs – so problem found? Well, the LS10 tested fine off the board, but curiously with the chip removed the output lines became logic high. That means an input somewhere on the board had to be driving that line high. So what was actually happening was the LS10 was trying to drive the line low, something else was trying to drive it high, and it ended up as a non-signal in the middle somewhere.
So, more tracing and the problem was found at the i8751 protection microcontroller – it’s reset input appeared to be putting out +5V. When removed there was an obvious problem – a pin was bent and not making contact – in fact it’s the ground pin for the MCU, so this was a very bizarre case where because the MCU was not grounded properly all sorts of lines were putting +5V onto the board. With the pin reconnected the LS10 worked properly, the CPU could reset properly and there was activity on the data & address lines.
But – still garbage on screen. There was one suspicious looking IC on the board – a Fujitsu LS00 at 13C - lots of corrosion on the legs even though all the IC’s around looked perfect. A lot of these Fujitsu’s have a high failure rate – I assume some kind inferior alloy was used for the legs and corrosion has travelled inside the chip package where the lines are even thinner. A logic probe confirmed the chip was getting inputs but the output lines were dead. Swapped this chip out and game working 100%
Game booted fine, but everything was tinged red.
Luckily schematics for this game are available so this was a quick fix. Schematics show the palette RAM connects to a pair of 74ALS574 chips, which go to a pair of 74ALS541 chips which then go to a resistor network to form the analog RGB output. A logic probe showed one of the inputs at U3 was dead, but the corresponding output on the palette RAM was pulsing away.
So what looked like a tiny scratch on the PCB surface was actually a deep gouge that had completely disconnected a trace line. This was patched and the PCB 100% working again.
This pcb booted up but with corrupt graphics. Helpfully Pacland does a self-test on startup and this one briefly printed 0 0 4 on screen (or arguably 4 0 0 as the self-test is printed upside down – to clarify the 4 is the first digit to appear). This means a RAM error and as I have a working Pacland to compare against it was quite easy to work out what error digit corresponds to what chip.
Piggy-backing a replacement chip on top fixed the corrupt text and the top scrolling layer so for sure RAM was bad. The bottom scrolling layer was now completely absent though and the self-test didn’t report any errors.
As I had a working board I swapped the custom chips and tilemap ROMs between boards just to rule them out and it made no difference. I suspected the fault was in the priority mixing circuit – this is what decides what pixel is ‘on top’ be it text, sprite or a scrolling layer.
The relevant chunk of the schematics is above, essentially the sprites and top scrolling layer are mixed by custom chip 29. The bottom scrolling layer is produced by custom chip 30 and drives the ROM at 4N. A pair of LS298 multiplexer chips then decide what takes priority – the background layer or the sprite/foreground layer. The LS298 selector is driven by an 8 input AND gate (LS30 @ 1N). This is really what determines ‘transparency’ in the sprite/top tilemap layer – if any of the 7 bits are high for a given pixel then it is ‘opaque’ – all low means ‘transparent’ and the lower layer should be shown.
On this board the LS298 chips and the LS30 are all manufactured by Fujitsu, which is known for a terrible failure rate. A logic probe showed the output of the LS30 chip was dead – so the LS298′s in turn were constantly stuck. Replacing the LS30 with one from a Dragonninja parts board fixed the problem.
I got a very clean original Double Dragon 2 pcb, but unfortunately it was completely dead. No video output at all, and a logic probe revealed almost zero activity on the TTL chips. After checking voltage, the first thing to do in this case is to check if the CPU is getting a clock signal – and indeed the clock pins were completely dead.
On both Double Dragon 1 & 2 the main CPU clock comes from a 12MHz crystal on the video board. Probing around here again showed no activity so a suspicion is the crystal itself was dead. Before replacing it though I checked the Double Dragon 1 schematics which showed a capacitor should be present and none was on my board. It seems the tiny capacitor that should be at C43 (C36 in DD1) had been snapped off so cleanly it just looked like an unpopulated pad.
A replacement was taken from a Dragonninja parts boards and amazingly that was the only fault – all sound & graphics were perfect.
This pcb was in clean shape but sprites were corrupt. It’s not very clear on the picture but it seemed every second column on the screen was missing, so was more likely to be in the sprite processing area than the ROMs (if it were the ROMs the missing lines would move around).
I confirmed the 4 RAM chips on the top right of the board near the graphics chip involved sprites by temporarily shorting some data lines together and watching the corruption change. I was reasonably sure one of these chips was the problem, but a logic probe showed no obvious errors, so I removed them one by one and replaced with RAM from a parts boards.
The second chip from the top was the problem – replacing fixed the error!
Another 4 slot – a previous owner had installed a new battery and replaced the palette RAM. The board now reported a RAM error with the original BIOS, and the diagnostic ROM confirmed it as the upper WRAM chip (see my previous 4 slot repair).
If you don’t have a SMT desolder station then (if you dare) you can remove surface mount chips with a heat-gun and some tinfoil to protect the surrounding areas. The chips are capable of taking quite a lot of heat so the only worry is warping the board rather than damaging a chip. Because there’s very little solder holding the SMT chips on though, they come off quite easily.
With that one RAM chip replaced, everything worked!
This Neo 2 slot was stuck constantly resetting, which means the 68000 CPU is not resetting the watchdog timer, so the board continually tries to reboot itself. A previous owner had clearly changed out some faulty surface mount RAM previously so I spent some time verifying all data and address lines from RAM/ROM to the CPU were correct as some looked like they could be shorted. Turned out fine however. Without much more to go on I tried out the diagnostic ROM which surprised me by booting and showing a VRAM error. In this case both of the 6116 fast vram type chips that often go bad. Both chips desoldered, sockets added and replacements fitted. Now the diagnostic ROM reported no faults, but the board kept on resetting with the original ROM installed.
I dumped the original ROM and found it to be corrupt – no wonder the CPU kept crashing – really I should have tested that first. Some kind of internal addressing fault as in the dump you can see some ASCII text where the reset and stack vectors should be. Unibios was burned to a replacement eprom and everything worked again!
This NeoGeo 2 slot booted to a screen saying Z80 error. That doesn’t necessarily mean the CPU is at fault – it could be the program ROM, the RAM or several intermediate chips that connect the Z80 to the main 68000 CPU that prints the error. In this case though a logic probe seemed to show the Z80 was dead. Desoldered, installed a socket and Z80 pulled from an Arkanoid, and everything worked!
An original Capcom/Mitchell Buster Bros pcb booted to a solid blue-green screen. This is one of the infamous suicide battery pcb’s, where a custom Z80 CPU contains a decryption table in volatile RAM powered by a battery. When the battery dies the decryption table is lost and the program code cannot be run. This pcb was an untouched original with a 29 year old battery, so safe to say the battery was stone dead.
Full info on restoring these dead CPU’s can be found here – http://www.arcadecollecting.com/dead/pre-cps.html
One of the original tricks of this encryption is that program opcodes (instructions) are treated differently from operands (data). This means that even if you understand the decryption and have the key you can’t just burn a new ROM in place as each byte the ROM will have two values depending if the CPU accesses it as data or instruction. The solution is to decrypt the ROM for both data & instruction separately and burn to a new double size ROM with data in top half, instructions in lower half. The CPU pin that controls whether instructions or data is being fetched is then used to select the upper address line on the ROM.
So the desuicide process is fairly simple – use 27c020 and 27c512 eproms to replace the originals, and run a wire to control the top address bit. I’m pleased to say it booted up first time when I tried it.
But.. pretty obvious there was no red color channel. The palette RAM would be the first port of call in this situation, but a logic probe showed neither of the two chips had any stuck bits. I probed down stream of the RAM and there are 3 LS367 chips. One each for red, green and blue. These are the last TTL chips before the signal is converted to the analog output and they control the blanking by cutting out the signal during h-blank and v-blank events. Shorting pins 2 & 3 on the red channel chip fixed the problem and isolated the fault to that TTL chip (which is a strange type of failure but there you go).
This pcb was dirty with signs of corrosion, booted to garbage on-screen and didn’t play. First problem was very obvious – two RAM chips had been removed from the game board and a lot of traces had been pulled up and ruined. Hippodrome isn’t the greatest game, but it deserves better than that so I installed some sockets and repaired the traces via wires on the underside. I have another working Hippodrome for reference so it wasn’t too hard to figure out what was what, but schematics are available anyway. (The RAM pretty much goes directly to the custom tilemap ASIC on the game board).
I swapped the game board onto the working main-board and the game ran and played. At first there was a problem with 1 layer of tilemap graphics – an address line fault that caused tiles to appear in the wrong places, but that was just a problem with my trace repair and easily fixed.
The main board continued to boot to garbage which is usually a sign the CPU program is not running. A logic probe showing the CPU had activity on the data and address pins so was trying to execute something at least. I removed and tested the main RAM (TMM2063 which are known for going bad). One failed the test. When replaced the game booted!
But not so fast.. although the title screen was correct no sprites or background graphics were visible, just the top text layer. Usually bad RAM would be the first port of call for missing tilemaps and sprites, but one layer comes from the game-board and I’d just repaired and tested it with the working main-board so why wasn’t it showing up here?
I suspected the priority mixing circuit – this is how the game decides what pixels from the 3 tilemap layers and sprite layer are above or below each other and also how transparency between layers works. A lookup PROM is the core of this system – for every pixel on screen each of the 4 layers signals whether it contains a non-transparent pixel. The PROM then contains a set of fixed rules that determine which of the 4 layers ‘wins’. A logic probe seemed to show the inputs to the PROM were all pulsing but the outputs were stuck low (which would mean only a single layer would ever be selected – in this case the text layer).
The PROM was removed and replaced with one from a parts board, and all graphics were working again. It’s quite rare for these kinds of PROMs to fail, I assume it was physical corrosion.