Another one of Muddymusic’s boards.
He actually sent me 3 of them in various states but I chose the cleanest and most complete to focus my attention on.
Game booted to a screen of garbage and the watchdog was constantly resetting the machine.
I initially checked all of the ROM’s and they all checked out fine so I guessed the issue was going to be RAM.
I desoldered the 68000 CPU anyway so I could use the Fluke 9010 and see what was going on.
Looking at the memory map in the MAME source code in othunder.cpp we can easily see where various things sit.

First off I checked the CPU is able to actually read the ROM’s properly. I calculated the ROM signatures for this version and ran ROM checks.

Everything is good here, on to the RAM.
First is the main RAM at 0x80000 – 0x8ffff

So we have an issue straight away. At this point I did a few manual read/write tests.
First I wrote 0x5555 and reading it back gave me this

So it looks like half the RAM is working but needed to confirm by writing 0xAAAA.

So what we have tested here is the ability of the RAM data pins to be able to toggle HIGH and LOW.
0x5555 in binary = 0101010101010101
0xAAAA in binary = 1010101010101010

By testing both of these values separately instead of testing 0x0 and 0xFFFF we also test none of the adjacent pins are tied together.
So I removed both of these RAM chips and they both failed tests out of circuit.
Replacing them let the Fluke test pass and gave me the following screen

At this point it looked like the the game was trying to boot but kept resetting still.
Looking into the program code I could see that after the main RAM is tested the palette RAM is tested.
The palette RAM hides behind custom chip TC0110PCR which uses address 0x100000 – 0x100007 to deal with all of the RAM. Again following the code I could see the address is set by writing a byte between 0x0 and 0xFF to address 0x100004 and the data is set by writing a word value to 0x100002.
Here is what I got from my tests

Again it looks like one of the RAM chips is faulty.
Looking at the schematics I could see that RAM chips IC75 and IC79 are the ones im after and that IC79 is my problem RAM.

Replacing this RAM now gave me this screen

The image is reversed as this game normally uses a mirror to invert the picture.

Having identified the screen RAM from the schematics

I carried out a quick check using the scope and found something like this on some of the data pins

So out both of these came and then we got this

So whats up with the colours? I confirmed the RAM was good using the Fluke. Turns out I was 1 off when making up my adapter so this fault wasn’t actually a fault at all, just human error.
Fixing my mistake gave me this

This is good but there were some jailbars in the sprites.
I couldn’t get a clear picture of this as the RGB levels on my supergun are currently fixed and too bright but you can make out there are some differences between these two pictures.
The ripple is also caused by my RGB levels so ignore that

Finding this fault was quite easy. I knew the MASKROM’s were good as id dumped them out. The associated RAM looked good on the scope. The next bit in line were 2 x 74LS374 chips.

Looking with the scope I could see the inputs were present on IC20 but the outputs were stuck LOW.
I hooked the logic analyser up to prove this point. You can see that the inputs are changing state but the outputs are always 0x0

I replaced this and the graphics were restored.

Next onto the sound.
Hooking up the sound surprised me as the sound was present but there was an issue.

As there was some sound I was confident the CPU and ROM/RAM were good.
I had 2 other board sets so I opted to swap MASKROM’s one by one. Swapping B67-07 fixed the issue.

That’s as far as I can test this board now so will send it back.

Received this Lifeforce PCB for a repair:

Board suffered from a backgrounds issue, screen was filled of blocks of garbage instead of correct tiles.Here a comparison with MAME snapshots.This in the title screen:

This is the in-game :

A video for a better understanding:

The hardware uses the famous ‘GX400’ video board :

The peculiarity of this board is the lack of ROMs, all the graphics is generated by logic of TTLs and custom ASICs.Anyway I has a good starting point since the owner assured me the customs were all good so the problem was TTL related.So I started to check for abnormalities with my logic probe.All was good until I found some 74LS157 with stuck inputs.According schematics they come from a 74LS273 @12B:

As you can see this TTL latches data bits from a 6464 SRAM  @15B which is addressed by the custom ‘0005291’ @20D (probably a tilemap generator).Probing it with a logic analyzer confirmed the outputs were all stuck low or high (only one gate was analyzed but all other were confirmed stuck as well with my oscilloscope) :

So confident I removed it (I forgot, obviously it was from Fujitsu):

Once tested out-of-circuit, it failed miserably:

Fitted a rounded  machine-tooled socket and a good chip:

And:

Once again Evil Konami has been defeated!See you in the next chapter of this neverending battle…

A quick fix for a PCB that seems to develop always same issue judging from my experience and other repair logs.Received this Snow Bros for a repair:

It was playing fine but some sprites suffered from flickering (it’s hard for my camera to capture this, see from second 5 of below video)  :

Maybe you can understand better from this picture provided me by the PCB owner:

The sprites are generated by the Pandora custom chip which read data from a MASK ROM and write them to four 4464 (64K x 4bits DRAMs) :

When I went to probe these dynamic RAMs with my scope all was good except one data line (D2, pin 3) of the one @IC24, signal was weak and stuck high compared to an healty one:

Confident I removed the chip which failed when tested out-of-circuit:

Installed a socket for a fresh chip:

and tested again the board:

No more sprites flickering and game 100% fixed.