Yves M

Dangun Feveron repair log #2

General, PCB Repair Logs, Repair Logs 4 Responses »

Mar 262020

I had this Fever SOS (international version of Dangun Feveron) PCB since many Years. Here is a picture of the board with the two chips I had to replace highlighted in red:

It had flickering sprites (the problem being pretty hard to photograph, I’m not able to show screenshots of it). In other terms, every second frame of sprites was not displaying.

1) The sprites are generated by a large 240pin custom chip labeled 9838EX002 – 013 on this board. Closer inspection revealed a cross marked on it by a previous repairer as well as a mark on pin #226. That pin goes to the RAS (Row Address Strobe) pin (#14) of a DRAM (424260) at U36, which is one of the two DRAMs that deals with sprites, each of them displaying alternatively one frame after the other.

There was no signal at all on that pin (#14). Probing the equivalent pin on the adjacent DRAM at U35 showed a pulsing signal. RAS being a signal going towards the DRAM meant that the large custom chip wasn’t giving the signal needed at pin #226.

I needed to change that large custom chip. These being on Cave 68000 systems, they are unfortunately available mainly on rare and expensive games (list available in the Cave 68000 MAME driver). After a long time, I finally had the opportunity to grab a UO Poko board which has the same chip, even labeled not exactly similar: 9749EX004 – 013.

Left is the faulty chip taken off the Fever SOS board. Right is a working chip taken off a UO Poko board. Notice how the left one blistered after heating it for desoldering, while the right one didn’t change.

2) Unfortunately, swapping the chip did not resolved my sprite flickering issue but at least the signal at pin #226 was then looking good. Probing the linked DRAM at U36 showed some weird looking signals on a few I/O pins (#2, 3, 4 & 5 pins).

I swapped it with a functioning DRAM (a NEC 424260). That finally resolved the flickering sprites problem.

Board fixed !

Lightning Fighters repair log #4

PCB Repair Logs, Repair Logs Comments Off

Mar 242020

I got a Lightning Fighters PCB with GFX problems. As you can see, major colors and layers issues:

1) Probing the Konami 053251 custom chip revealed some weak signals on a few pins. This chip is a priority encoder, it deals with colors and layers and seems to be prone to failure in more and more boards of that generation. Unfortunately, you have to find a donor board of the same era to get a working one (good thing anyway is that it is used in a pretty good amount of Konami games).

Here is the result after swapping it with a good one:

2 & 3) Colors and layers are now fixed but we have some jailbars on sprites. This looks to be a sprite’s data issue. Probing the mask ROMs revealed missing signals on a few data lines for 939A05 and 939A06 ROMs. I replaced them with two burnt 27C400 EPROMs. Board is now fixed:

Here is an overview of the chips I had to replace on the board:

Megablast repair log #2

PCB Repair Logs, Repair Logs Comments Off

Apr 192019

I got a Megablast board that was not booting at all.

1) As reported on Caius Liquid Kids repair log (https://www.jammarcade.net/liquid-kids-double-repair-log/), it is common on these Taito F2 system boards that TC0220IOC custom chip is faulty in this case (I suspect plugging the board to the JAMMA connector upside down may fire that chip, sending it +12V via the I/O ports. That’s probably what happened here).

Indeed, after swapping the TC0220IOC chip from a donor board, the game booted and offered me a nice glitched screen:

2) Another common issue on these Taito F2 boards are the mask roms getting internal disconnections within time. So I started replacing the background ROM (C11-05 @ IC58) by an equivalent 27c400 programmed EPROM and got backgrounds fixed:

3) Anyway, all the sprites were missing. After a long search and many tries I found a weak signal on one of the RAMs data line that carry sprites information between the main CPU and the sprites generator custom chip TC0200. Replacing the RAM (a TMM2063AP @ IC50) made sprites appearing, but glitched:

4) I found out that one of the sprites ROM was dead as well (C11-04 @ IC31). Replacing it with a programmed 27C400 EPROM fully restored the graphics:

5) & 6) One last thing I didn’t mentioned yet was the sound that was scratchy. More precisely, sample sounds were clearly corrupted, not the FM sounds. With no surprise, I found out that both IC where audio samples are stored (C11-01 @ IC29 and C11-02 @ IC30) were dead. Replacing them with equivalent 27c040 programmed EPROMs totally restored the sound.

Board is now fully fixed. Here is an overview of the chips I had to replace on my board (interesting fact is that Caius had to replace the exact 4 same mask ROMs on another Megablast board: https://www.jammarcade.net/megablast-repair-log/):

Mahou Daisakusen repair log

PCB Repair Logs, Repair Logs Comments Off

Aug 222017

A friend got a Mahou Daisakusen (japanese version of Sorcer Striker) board with faulty graphics.

It was playing fine with sound but there was an obvious color palette problem.

I started looking at signals around the color outputs of the PCB and quickly found weak signals on the 74HCT273 at location U12. Piggybacking the chip with a working 74LS273 fixed the colors immediately.

I replaced the chip… Board fixed.

Here is a picture of the PCB with the defective chip highlighted in red:

Golden Axe 2 – The Revenge of Death Adder repair log #1

PCB Repair Logs, Repair Logs Comments Off

Oct 042016

Got this Golden Axe 2 rom board (here plugged on a working Sega System 32 mother board from an Arabian Fight) with a black screen on boot:

goldenaxe2-1

I borrowed a friend’s working Golden Axe 2 rom board for tests and found out that the security board was the faulty part:

goldenaxe2-2

This board uses an encrypted V60 CPU to prevent conversions by swapping ROMs between boards. For example, there is the exact same board on Arabian Fight but CPUs have different IDs:
– 315-5533-01 for Arabian Fight
– 315-5533-02 for Golden Axe 2

So obviously, putting the security board from Arabian Fight didn’t make the game working, even with the EPROM from Golden Axe 2 plugged in.

ROM, PAL, oscillator and 75HC04AP were tested good but I found a few address lines which looked inactive with the scope. So the faulty chip could be either the CPU @U2 or the RAM @U1. As the encrypted CPU cannot be retrieved anywhere else than another Golden Axe 2, replacing the RAM was my only chance to repair it.

The RAM is a Fujitsu MB8421 (16 kb CMOS).

goldenaxe2-3

I bought a new one (got a MB8421-90L instead of the original MB8421-12L but not a problem as it is a faster 90 ns instead of the original 120 ns), replaced it and luckily the game booted with no other issue. 🙂

goldenaxe2-4

Older Entries