Got this from a Jamma+ forum member.
Sold as having graphics problems that went away when touching one of the MASKROMs.
On testing it had lines running vertical down the screen and the fault did appear to go away when touching K27 MASKROM. This however was not dry joint, it was a floating output meaning the MASK was knackered.

I removed the MASKROM and programmed a replacement 27C400 EPROM.
Game now works fine and all self tests pass.

The game does appear really washed out on my test bench but plays fine in a cab. Not sure why this is but I cant actually see anything wrong with the output signals so ill ignore it for now.

UPDATE:
This board also had another fault where button 2 for players 1, 2 and 3 didn’t work.
Turtles actually has an IO test within its test menu so it was easy to check all inputs.

I traced the signal through a resistor network and could see the state toggling with a button press. Traced it back a bit further to a 74LS253 chip at location C26. Replaced this chip now all working again.

Been after a genuine board of this for a bit now and this one came along. I thought it might be in full working order but once again eBay lets me down.
This one had jailbars through all the main sprites.

More often than not this is a bad ROM and this was ended up being just that.

In the corner of this board there is a bank of 8 MASKROMs that contain the graphics. Unfortunately none of these are in sockets and as I couldn’t really see anything hugely wrong on the scope.
This game doesn’t have a test mode nor does it carry out any RAM/ROM tests on start up so I wrote a little self test program myself in assembly that tested the sprite RAM at location 0x0c2000 – 0x0c3fff in the address map and simply would display a “P” for a pass or “F” for a fail.

This passed no problem so my hope is for one of the ROM’s to be dodgy as opposed to one of those custom chips.
I set about desoldering them one at a time and checking along the way. After the fourth one I found my problem with a bad ROM dump.

My dump is on the right and the MAME set dump is on the left. As you can see, bit 0 is stuck on.
I fitted a socket and reinstalled the ROM but with data line D0 lifted and checked it out with the scope.

On a closer inspection it shows that the logic level isnt dropping below 2v.
The MASKROMs are pin compatible with 27C080 EPROMs of which I have none. I have ordered some so will hopefully receive it early next week

EDIT: EPROM came today, the game is now fully working

So I saw this Taito board on eBay. The seller says its broken and unknown but was most likely a Super Chase and supplied a System 16/24 adapter with it, which in its self is very nicely made and they can cost quite a bit.

Only thing is, Super Chase is not a System 16 or 24 pinout.

*pinout supplied by Stefan Lindberg

I made a quick and dirty adapter up with and tested the board, dead.
Now I made a very stupid mistake at about this point. I moved the board down from the test bench and into one of my cabs just to rule out any voltage issues that ive seen before BUT for some unknown reason I left the pinout adapter in the test rig.

After the smoke dispersed I checked the damage.

Power supply is fried. Turns out, without the adapter I tied the +12v line to the +5v line and destroyed the PSU.
At this point I didn’t hold out much hope for the board anymore but tested it anyway.

The board was unsurprisingly still dead.

I check the RESET and HALT lines on the CPU, the watchdog was doing its thing.
Pulled and checked the program ROM’s and 2 didn’t match.
A strange thing here. One has only 1 byte difference right at the end and the other was clearly trashed with random read outs at every read.
I copied the first dump over to MAME and ran it. Turns out this is probably a different region to the one in MAME and that byte difference either displays the country warning screen or not. Mine does not.

I got nothing but a bit of garbage on screen

I fired up MAME and checked what the game should be doing and it does perform RAM checks. I also saw in the code that it has RAM fail messages on screen should it encounter a problem.
Probing around the board in this state didn’t help at all as the watchdog reset everything before I could really see what was going on.
After a quick look at the CPU code I see I can bypass the shared and screen RAM checks very by changing only 1 byte. I did this and replaced the relevant EPROM and watched the game boot

So the screen RAM is at fault. The screen RAMs are the 2 Sony 58257 chips in the center of the board.
I pulled both of these and both failed. Replaced them and the game boots once more.

A narrow escape I think. This will hopefully teach me to slow down a bit, but I doubt it