Capcom Black Tiger arcade pcb repair

At first glance this fault appears to be a variant on the common ‘failed sprite linebuffer’ problem that often crops up in arcade pcbs where every 2nd line is missing. In this case though every second line is drawing incorrect sprites – and all up against the left side of the screen. Because there is actual sprite data on every scanline, the line buffer circuits themselves must be working – it’s what is being put into one of them that is the fault.

As the sprite tile is wrong the address lines of the sprite ROMs are the first place to start (as the address lines control what tile is output to the line buffers). The address lines all trace back to the 86S105 custom chip and unfortunately it’s where this repair ends. This chip completely integrates the frontend of the sprite processing and seems to have failed internally. The chip itself is almost certainly based on the design of earlier Capcom sprite generators like Ghosts n Goblins. That game has RAM for the sprite list, then two more RAM chips for an attribute buffer that alternate every scanline. Most likely one RAM or supporting logic has failed.

Interestingly some Googling revealed a picture of a Black Tiger prototype where the custom chip was replaced with regular TTL – and although the picture is low res the 3 6116 RAM chips can clearly be seen.

https://forums.arcade-museum.com/showthread.php?t=21902

The only fix is to replace this custom chip, which is also used on 1943 and Buster Bros/Pang.

Well, thanks to JoeyBagODonuts on KLOV who donated a broken Super Pang this board is working perfectly again. The 86S105 custom was swapped and everything worked!

Centuri/Amstar Phoenix arcade pcb repair

Certain graphics had corruption – usually solid lines through certain sprites or frames of animation. As the issue was specific to certain frames I was fairly sure it would be a ROM problem, as a RAM or TTL problem would most likely affect all graphics. ROMs H2 and H3 hold the sprites and although H2 was in perfect condition like the rest of the board, it contained some corrupt data. A replacement was fitted an everything was fine (a 27c32 was used as I didn’t have any 2716′s – this is fine if you burn the ROM data to both the upper and lower half).

Data East The Real Ghostbusters arcade pcb repair #3

Another Ghostbusters, and like the previous repair no video sync or output although a logic probe seemed to show the CPU was running. I expected to find a bad 74LS chip or a gouged trace on the bottom video board, but I pretty quickly found the custom chip that is meant to produce monitor sync was completely dead. The DRL40 custom takes some timing signals, has a reset line and takes a 12MHz and 6MHz clock. In return it is meant to produce monitor sync and sprites. Even though all the inputs appeared correct absolutely nothing was appearing on the output lines. Manually grounding the reset line didn’t do much either.

When I looked at the board in sunlight though a tiny crack was obvious in this chip – so it had certainly failed and probably made quite a loud pop when it did so. The chip was removed and a replacement taken from a Gondomania pcb soldered in – everything worked again.

Konami Hypersports / Hyper Olympic 84 arcade pcb repair

Game booted to garbage on screen. Logic probe showed the CPU was continually being watchdog reset. ROM & RAM are usually the next things to check and was quickly clear the enable pin on the RAM @ G2 was floating/disconnected. This traced back to a Fujitsu LS139 at H13. With that replaced everything worked again.

Atari Rampart arcade pcb repair

Game would show an initial flash of garbage on 1st power up then get stuck on a black screen and continually watchdog reset. The watchdog can be disabled by shorting the jumper next to the test switch and with this done it was clear the CPU was running fine. In fact it seemed to intentionally be clearing the screen to black and then just sitting in a loop somewhere in code. A logic probe on the IPL (IRQ) pins showed it was responding to interrupts correctly which pretty much also proved the main RAM was working fine (if the RAM was bad then garbage would have been pulled from the stack at the end of the IRQ which would have caused a crash/bus error).

The game uses a selection of GAL chips mainly for memory addressing – I burned replacements for each one with no difference. The ROMs tested fine of course and all address & data lines had continuity from CPU to ROM to RAM (the latter via a pair of LS245s).

The culprit turned out to be the 2816 parallel eeprom used to store the game settings – when tested it showed a just a couple of bad bits that would randomly change on each read – if it had fully failed it would have been an obvious fault. When replaced the game worked fine, so whatever bad pattern this eeprom gave out managed to confuse the program into getting stuck.