Seibu Kaihatsu SPI & Raiden Fighters 2

 PCB Repair Logs, Repair Logs  No Responses »
Jan 142026
 

In for repair is a Seibu Kaihatsu SPI mainboard (V2.0 Revision) and a Raiden Fighters 2 game cartridge.

The SPI mainboard wouldn’t boot – on powerup, it would display a generic “Checksum Error” message.

This is a common problem with the SPI platform. The SPI mainboard and game carts are region coded. If the cart region doesn’t match the mainboard region then you’ll see this error. Additionally, when a game cartridge is accepted, portions of it are flashed to chips on the mainboard. If something goes wrong during the flash process, the mainboard’s region code can be lost, causing it to no longer work with any game.

Happily, Trap15 created a tool called SPI Revive that can be used to write a new region code onto an SPI mainboard. I connected my SPI Revive cartridge, and it shows that the region code for this board is “zero” meaning that it was indeed bricked. I told SPI Revive to write the Japan region code to the board, which it did successfully.

After reconnecting the Raiden Fighters 2 cart, the board started up successfully, flashed itself to the mainboard successfully, and then prompted to restart. After restarting, the game boots up and runs fine, but with “jailbar” lines of corruption running through the sprites.

This is another common issue with game cartridges on this platform. There are several SMD ROMs and a large SMD custom chip. Not much solder was used at the factory and over time, some of the chip legs can detach from their solder pads, breaking the connection.

One way to test for this problem is to press on various chips on the PCB and watch the screen to see if the graphics change. I used a plastic spudger and noticed the jail bars would flicker when I used it to press on ROM chips in the OBJ section. I reflowed the solder on them.

Afterward, the game boots up and runs fine with crisp, clear graphics and sound. The final touch is applying reflective stickers to cover the exposed windows on the two EPROMs missing them on the game cart. A successful repair!

Thunder & Lightning repair log

 PCB Repair Logs, Repair Logs  Comments Off on Thunder & Lightning repair log
Aug 152024
 

Got a Thunder & Lightning, a nice ball and paddle game from Seta on the bench today.

At first glance the board looked fine, but there was some worrying rusted pins on one LS close to the 68000 … not sure why, but other chips around weren’t affected.

I replaced the chip and patched the traces with some kynar wire.

When powered up, a working game displays a moving patchwork of tiles for a few seconds before displaying the title screen. In this board case, the tiles patchwork was displayed, but it kept rebooting just before displaying the title screen.

On this board, dipswitch 1 of the first bank puts the game in test mode. Doing so displays a color grid, and after pressing a button you get to the input test. The board worked flawlessly in test mode, meaning the main CPU worked enough to run it. But when pressing the reset button on the board, the following message started to show: “Address Error 2020E6”, before rebooting again …

Not knowing where this address pointed to, I looked into Mame to find the memory map of the game. And I found something very interesting : a PALCE is used as a protection device, using some address lines as inputs and computing a value that’s grabbed later by the CPU … if the value isn’t the one expected, a soft reset is done. That looks reaaally familiar !

Here’s the offending chip (TL-9) :

It was removed …

.. and replaced by a GALV16V8, using the file from the PLD archive. I added a support just in case.

And voilà !

Played a few levels to be sure nothing’s amiss, all is good !

Namco Rompers repair log

 PCB Repair Logs, Repair Logs  Comments Off on Namco Rompers repair log
Aug 032024
 

I’ve had this board in my collection for some years and I’ve made some repair work on before (replacing the cus120 on the CPU board, might put up a repair log on that as well).
I was going through my PCB collection and found that the game would not boot, there was only a black screen and not even the usual klonk sound as Namco System 1 games usually do.

Started with the basics, probed the Program ROMs with my logic probe and I did see some activity on the address and data buses.

Decided to dump the Program ROMs and verify them and they turned out to be ok.

So I started to probe the address and data buses again and found an address line (A2) that was stuck low.

Traced this line back to a 74LS244 at E10

74LS244 is a buffer and according to the Pac-Mania schematics, pin 14 is the output which has its input at pin 6 and there was activity there

This made me quite certain that the 74LS244 at E10 was bad.
But just to be certain, I removed all Program ROMs and the Custom key chip, so none of them would interfer.

And the fault was still there.
I quickly desoldered the 74LS244 and tested it with my tester as bad

I soldered a socket in its place and replaced the IC with a known good one and now the game booted up again

Operation Wolf repair log #3

 PCB Repair Logs, Repair Logs  Comments Off on Operation Wolf repair log #3
Apr 102020
 

Another few Operation Wolf boards in at the moment. This one is from Unit504.

There is a nice little tag on this telling me the faults which really helps me keep all these boards together and where to start looking.

First job was to look into the gun shot register issue.
I did a quick test and could see the screen flash when the trigger was pulled so I knew that wasnt the fault
Following the circuit I come to the 74F74 IC which is used to latch the gun co-ordinates.

I normally wouldn’t start looking at this part but it was already socketed so decided to pull the chip and test it. It failed an out of circuit test.

I replaced this with a 74ALS74 and it seems to be be fine.
Now all the gun shots register as expected.

Next onto the sound.
None of the sounds were working at all and I didnt believe that all the seperate circuits for making sounds would be dead so looked a bit closer at the CPU side of things.
First off I checked the ROM and it dumped out fine.
Next the RAM. An inspection of the RAM showed signs of corrosion

I removed and tested it and thankfully it failed

Looks like that corroded pin has broken contact somewhere. Anyway, replacing the RAM brought all the sound back to life and completed this repair.

Lightning Fighters repair log #4

 PCB Repair Logs, Repair Logs  Comments Off on Lightning Fighters repair log #4
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:

 Older Entries