9 May 2019

Game was dead, no main or sub CPU activity, however sound section was alive since adding a coin would make the associated jingle play.

This was the first revision of the hardware used by Seibu for Raiden, a real nightmare for repairers:
- 18 CPLD (most undumped, few dumps I've found turned out to be incorrect due to most devices being registered)
- 12 SMD custom chips
- 6 SIL custom chips
- few others DIP/SDIP custom chips (e.g. YM3931, etc.)
- many custom SDIP mask ROMs
Seibu probably went this route to discourage piracy, at the price of an overly complicated design, a much more simpler hardware could have done the job perfectly.

I probed main and sub CPU and found there was activity on buses for a fraction of second only then nothing. I was a bit stuck since few signals made no sense: some LS245 had their /OE signal stuck high, putting all outputs in high impedance, although their DIR signal was toggling, Altera chip for sub CPU had 2 floating inputs (pins 5 and 9) coming from the PEEL18CV8 stamped RD016, etc.
I put the board aside for a couple of days, time to elaborate a plan. Having a fully working Raiden I though I'd make few experiences with it. Pulling sub CPU ROMs revealed main CPU was still able to start and maintain its activity. Thus first problem to solve was to get main CPU to run. I continued probing on the main CPU, associated ROMs and RAMs, and nearby PLDs when I found one input (pin 11) of RD002 (U0172, PEELCV8) was floating. This was interesting since that chip generates the /CE signals for ROMs and RAMs and I had found before ROMs 3 & 4 were permanently selected (always low) and the other pair of ROMS (1 & 2) so as RAMs were never selected (always high). I followed the trace and found a point of corrosion on a via near the JAMMA edge. I clean the rust and exposed copper and for sure connection was low on half a millimetre between the via and the trace:

Once patched game then booted and was almost fully working! Except sprites were "cut":

Swapping the daughterboard (OBJ1) with a known working one informed me it was the culprit. Upon close inspection I found several lifted pins on several SMD customs chips:

I reflowed all of them and sprites fully reappeared:

Game fixed.

P.S.: I had used the UEC-52 (SIL22) custom chip from that board to repair an other Raiden board but in the meantime I'd also ordered a replacement part from Caius from jammarcade:

I decided to install the replacement on that board and can confirm it works per fectly. Thanks Caius, good job!

2 May 2019

As often board was dead. Upon inspection I discovered someone previously worked on the board and reflowed the custom chips (in a weird way, by this I mean with a lot of solder but surprisingly there didn't seem to be any short). Also the sample ROM on the top board was in the wrong socket and jumpers weren't set properly but this shouldn't prevent the board from booting. Last thing I noticed was a sticker on the top board saying "NO SOUND".

1) Getting the board to boot

One of the work RAM had its data bit 7 stuck low. I pulled it and it was reported faulty by my programmer. Once replaced I saw no improvement. Main CPU being 16 bit (68k) work RAMs are paired (LSB/MSB) and often when one is faulty the other one is too. So I pulled the second one (again reported bad) and game booted with many graphic faults and no sound:

2) Fixing the sound

I went straight to the audio RAM and again data signals were incoherent. Once pulled it tested bad, as expected. Replacing it brought back sound.

3) Fixing the graphics

3.1) Jailbars

Probing the top board revealed data signal D6 was absent from LS373 @A6. Probing were D7 was coming from gave me the information that D6 was linked with D6 on the LS373 next to it (@A7). I restored the connection with a piece of kynar wire and jailbars disappeared:

3.2) Sprites

I probed the mask ROMs on the top board and found the one named MAA-04 had weak signals on its data pins. I desoldered it and tried to read it with my programmer: it was full of $0E and $0F repeated at infinitum... I programmed a new one (27C400) and graphics were much better, sprites being perfect now:

3.3) Background

Still, there was an issue with one of the background layer.
It's generated by one of the custom chip named '55'. At first I thought it was faulty cause I had the exact same issue before with an other Data East game and the '55' custom chip was the cause.
Anyway, I probed the 2 RAMs associated with that chip and again one of them had weak signals on its data pin. They are directlty connected to the custom chip so not 100% sure they were the RAM was the problem but I took the chance of replacing it after having found 3 other bad RAMs on this board. And it was a lucky bet, the background was much better after replacement but not perfect.
Some tiles were corrupted:

But sometimes background was perfect:

I was pretty sure problem was around the custom '55' @D19, it had been reflowed before so I probed each pin when pin 82 would give me connection with two traces going to the custom chip. In fact pins 81 (ground) and 82 (data signal) were bridged by an almost invisible solder bridge. I removed it and could finally enjoy the game:

24 Apr 2019

Game was a conversion but not sure if official or not:
- game has 2 Sega daughterboards
- labels are handwritten
- program ROMs match the encrypted wboy romset

Anyway, sprites had horizontal bars over them:

I dumped the sprite ROMs but they checked ok, then reseated the associated daughterboard with no result.
So I followed the sprite generation circuit from IC to IC finding nothing obvioulsy wrong.
This is where I reached the 6 DRAMs used for sprites. They were AM2148 devices, known to generate a lot of heat, however two of them remained cold (IC13/IC33): to me that indicated those two chips were doing nothing.
I pulled them and installed fresh ones (much faster though being 35ns were original ones were 70ns) and sprite issue was cleared:

Lisenced... Clearly asking for a legal loophole.

I ended the repair by testing all inputs and sound and confirmed there wasn't any other problem with the board.
Game fixed.

17 Apr 2019

Game got stuck on the memory test screen with palette error C4 and sprite error P15.
I pulled both RAMs (6116 type for the palette, 6264 type for sprites) but they both tested good out of circuit.
As you can't rely 100% on out of circuit tests I installed 2 fresh chips on sockets: errors were still present.
By probing the RAM chips them I could see some signals were floating: board had few points of corrosion and a couple of traces got severed.
I patched them all and then board booted into game but only the very top of the screen was visible:

I continued my inspection of the board, testing continuity of each dodgy point when I found pin 12 of the LS367 @D7 was floating.
For once schematics were available (quite unexpected since Ikari III is a bit of an uncommon game) and from them I learned missing signal was AB11 (address signal buffered through a LS244). Again I patched the severed trace and fault vanished:

Game fixed.

P.S.: This game seems to accept rotary controls through additional connectors on the board but is also totally playable with a joystick from JAMMA inputs.

10 Apr 2019

An other filthy board. But after a good bath in the garage sink it was much better:

Game booted with corrupted graphics, sound and controls were fine.

Since only part of the graphics were bad I thought of a ROM issue.
By having a quick look at the board layout I was sure graphic data were stored in the 4 big ROMs 3/4/5/6. I started by pulling ROM 5 to see if there was any change. There wasn't. Could I have found the issue so quickly?
Well, yes! Dump produced a file full of 0xff. I burnt a replacement in a 27C160 EPROM and graphics turned back to normal:

3 Apr 2019

I received this board as a gift, being warned it had a graphical fault.
Still, I was extremely grateful.

Game worked fine with the exception of jailbars over sprites:

One mask ROM had been replaced (flux used was probably not the best since it left a lot of residue, note to self: clean that) and few traces had been patched:

ROM test reported 2 bad:

Fortunately problem was simple, one via under one of the mask ROMs was corroded and connection between one data line from the mask ROMs and the sprite generator (custom chip) was lost. I redid the patching work and fixed the via by drilling a tiny hole in its middle and soldering the core of a very fine kynar wire in it, restoring connection between the two sides of the PCB: