1) It was stuck on a white screen on boot.

After looking for a suspect chip, piggybacking, etc… with no luck, I finally found out that the reset signal was going to high level too quick to let enough time to the 68000 for proper initializing.

Thanks to the schematics, I could see that the reset was generated by a custom Konami chip labeled 051550 located at B19. Like many boards of that era, a capacitor is used to create a temporization when you power up the board and let the 68000 initialize after everything else is ready.

The capacitor takes one or two seconds to fully charges then the chip responsible for generating the reset switches to high level. You can see when powering up the board and looking at the signal on the + pin of the cap with a scope the voltage slowly raising before stabilizing. Here, the ceramic capacitor located just below the 051550 chip didn’t seem to charge slowly and got suddenly to high level when powered up. The cap was a bit hidden under the 051550 chip that was bended over it so I softly pushed it and it went like that:

This chip is a small ceramic board populated with SMC chips recovered by a black material. It was cracked but that was almost unnoticeable before pushing on it. It is used on many Konami boards of that era and luckily I could find a good one on a spare board. Here is a closer look at both desoldered:

After replacing the chip, it booted, got the RAM/ROM test with everything OK:

Then the white pattern:

Then it rebooted and repeated that again and again…

2) I inspected the signals near the CPU part, RAMs, TTLs, but everything looked fine… Retried piggybacking the RAMs with no changes…

Sometimes it may happen that a minor error in the data or address lines cannot be clearly visible with the scope so I desoldered the two CPU RAMs, a pair of Fujitsu MB8464 (64kb) at J13 and L13 and tested them on my programmer. And the one at L13 didn’t pass the test:

I replaced it with a new one and the game launched. Everything else works perfectly.

Initial Symptoms

• Static junk on screen, which changes between reboots.
• No sound or evidence that game is running in background.

Sony PVM monitor wouldn’t sync in RGB mode, but would (for some reason) in Y/R-Y/B-Y mode.

CPU Boot Problem

Probing CPU interrupts showed that sometimes V-Blank interrupts were active, sometimes not. Initial check of EPROMs showed that one was dead, but replacing did not solve the problem. Probing with a logic analyser showed that the data/address bus of the main CPU was pulsing, and the game wasn’t watchdogging so deeper investigation was required.

Tracing with a Saleae logic-8 showed that the first v-sync interrupt was getting acknowledged by the CPU, but subsequent interrupts were ignored. Digging futher I generated a partially complete address/data trace by the (shared) data+address bus and the bus status lines (BS0-2). Since my analyser is only 8-bits, I could only trace 5 data+address lines at once. I wrote a script to combine multiple traces using the bus status lines to synchronise the data. Luckily the behaviour was deterministic, and I could extract enough trace data (12-bits of both data and address) to work out a full trace by correlating the data with a mapped ROM dump from Mame. Doing this I found that one of the RAMs was faulty; The stack was getting corrupted, causing a ret instruction to jump to an unexpected program address. Swapping the program RAM resulted in the game booting.

New Symptoms:

• Some tiles have flickering horizontal bars
• Some tiles seem to not change from top to bottom (in horizonal screen)
• Sound crackly and missing music

Tile Corruption Problem

Probing the tile ROMs shows that ROM U105 address lines 1-4 were floating. These were driven by the SEI0020BU custom chip at U102. Pulling the SEI0020BU and swapping it with it’s neighbour switched the tile corruption. Clearly the SEI0020BU was the cause of the problem. Annoyingly these aren’t easy to come by.

Reverse Engineering the SEI0020BU

I guessed that the main function of the SEI0020BU was to drive the addresses of the ROM chip in the direction of the raster. I checked the connections of the SEI0020BU with a multimeter and worked out the function of each pin (see schematic below for more details).

Checking the Mame source confirmed that the address mapping for this chip corresponded with the x-axis scroll register. I guessed the purpose of the chip was to store an x-axis scroll offset and add that result to the raster x-position. I guessed that only 8 bits of shift were actually needed, and I knocked up a prototype on a breadboard, which seemed to work well.

With a working prototype, I got to work using CadSoft EAGLE (PCB CAD tool) to design a PCB daughterboard for a more permanent solution. The PCB was printed by Seeed, and delivered in a few weeks.

Once the printed PCBs were delivered, they seemd to work well, but I’d made a few mistakes. Firstly, the output from the LS156 should have been pulled high. Secondly, only 8 bits for the shift offset was insufficient – I actually needed 9 bits. This was a stupid mistake – I’d been unable to test the full shift range properly on my test rig because of a faulty joystick adaptor! Once I tested the board in a cabinet, it was clear that scrolling too far to the left (offset register wraps) causes the tiles to distort (-1 wrapped to 255 instead of 511).

I managed to hack a fix onto the PCB by piggy backing an extra 8-bit buffer and a 4-bit adder onto the PCB, cutting a trace and wiring up with patch wires. The modified PCB finally worked properly, and the graphics were fixed. I wasn’t happy with it though – I’d printed a PCB, so I thought I may as well finish the job!

I modified my design in Eagle (see schematic below), and ordered a new set of PCBs to be printed.

The new PCBs arrived, and worked perfectly – phew!

Sound Fix

Sound was working, but distorted and noisy. Probing the sound input to the amplifier with an oscillioscope showed that the signal was weak. This was driven by the HB-41 SIL package. The inputs to the HB-41 looked clean, so it looked like it was bad.

Luckily I had a spare on a Seibu Soccer donor board. Hooking it up solved the sound problem. Job done!