Operation Thunderbolt repair log

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.