On with the second Spy Hunter repair.
On boot the game displayed a screen of garbage and just sat in watchdog.
Having a look at the ROM’s showed that the EPROM at 6D was a 27128 and it should be a 2764. I pulled this and dumped it to find only half the chip was being used. In order to use a double size EPROM the data needs to be doubled up so this wouldn’t work. I also noticed that this board had the free play ROM’s installed. This needs the EPROMs at 6D and 10D replaced so without the correct ROM’s at both 6D and 10D the game wouldn’t boot.
I installed original ROM’s but the game still did not boot.
Plugging in the Fluke I found I couldn’t get a good read of the EPROMs.
So looking at the schematics I can see the address lines are buffered

Probing the 74LS244 showed that although I had inputs pulsing away all the outputs were floating.
I removed this and replaced it for a new one and the game now boots.

I had a strange fault here that for some reason I didn’t take a picture of. The game booted but certain tiles from the background were being drawn in the wrong areas, This changed on each reset but I couldn’t understand how this happened.
I pulled all the EPROMs and checked them but they were OK. I pulled the video RAM chip and tested but that was fine too. I did notice the socket for the video RAM was very dodgy

I replaced this but it made no difference.
As I was struggling to understand why this happened I thought Id check out everything associated with the video RAM chip.

The 74LS245 was the first check but this was fine.
The 74LS32 at 2F however had some strange behavior going on. Some of the pins looked to be stuck HIGH but then other times they appeared fine. I pulled the chip and it failed tests.
Replacing this fixed all the graphics faults.

On to the SSIO.
There were two SSIO boards with this set, the first of which works fine so ill write about the second one instead which was not fine.
So with this SSIO attached the game is in constant watchdog.

Here is where I got stuck for a little while. I couldn’t get consistent reads of the EPROMs with the Fluke. I could dump the chips no problem and they are checked out fine. Strangely replacing these chips made the error go away.

The last issue was with the sound itself.
Some of the sounds were missing and there was a constant tone in the background. Replacing the AY-3-8910 @ F7 fixed this up.

Everything is working fine and I can now test all the inputs too.

The SSIO board does not initiate a RESET to the main board at all but as it is directly connected to the main PCB’s address and data bus it has the ability to mess things up if there is a problem in those areas.
Using the Fluke I narrowed it down to one of six chips on the data bus as I found D4 was stuck HIGH. I eventually found the 74LS244 @ E2 was to blame. Replacing this allowed the game to boot again but I had a “Timeout Error”.

I’m on a roll at the moment and this one was one of the smoothest repairs Ive ever done.
Here I have a couple of boards from muddymusic. First up is Bionic Commando.

There was a ribbon cable missing completely. Ive got loads of these spare so that was pretty easy to replace.
Test time. The game booted to garbage.
First step was to check the program ROMs and found this on one chip

and this on another

With those sorted the game now boots although all the text is a bit messed up.

With the help of the MAME source which specifically identifies which ROM is responsible for text I pulled the ROM and read it. Each read gave a different CRC so it failed its verification.
Burning a new EPROM for TS-08 brought back all the text.

Job done.

This one has been fun.
Ben76 on the J+ forums has many sets of Spy Hunter PCB’s but none of them are in working states.
He kindly sent me a board set and a loom of some sort so I could learn a bit more about the hardware and to attempt a fix.
My idea was to create a test rig for this hardware as they seem to be quite prone to failure after their many years of service.

So to start with, as always it was a visual check. The boards, although in need of a clean, were in decent condition.
There was some old flux on the underside of one of the boards that I cleaned up.

Checked resistances between the power pins to make sure there were no shorts. All clear.

Next was the ROM check and also where the fun started.
All the ROMs on the CPU board checked out except for the 27128 EPROM at location 11D. My dump also came out half split swapped compared to the MAME dump.
I fitted the Z80 pod so I could use the Fluke 9010.
The first ROM at 6D gave crazy reading, this was sorted by reseating the ROM a few times.
The odd thing was that reading 11D with the Fluke gave me a signature comparable to the one in MAME.
TO THE SCHEMATICS!

From here you can see that the upper address pin (A13) is connected straight to the CPU (via buffer).
From the MAME driver you can also see where ROM 11D starts.

So, 0xA000 = 1010 0000 0000 0000 in binary which means that when this ROM is read address line A13 is HIGH so the upper half of the ROM is read first.
This has now been rectified in MAME.
One mystery solved.

Since I had the Fluke hooked up I gave the RAM’s a checking over.

Its quite well documented online that the NVRAM can cause issues when booting so lets look into this for a moment.
The NVRAM is used for book keeping and maybe other things too. The RAM chip used is a 6116 compatible RAM which under normal usage is volatile meaning it loses its contents when the power is removed. To combat this BITD a battery was installed in order to keep the RAM chip alive when power was removed. Now we all know batteries don’t last forever and many are either dead or were removed long ago. This wouldn’t normally be a huge issue as for the average collector/gamer book keeping isn’t too important BUT this RAM chip is subject to a RAM test on startup. If the battery is dead or removed then the chip has no power and will fail its RAM test which will result in a non booting game.
The ways around this are either fitting a new battery or you can add a wire link at JW15. This will attach the chip to the +5v line.

To check this RAM with the Fluke this jumper needs to be in place or alternatively if you run the game for a couple of second you can test the RAM then as it will be properly setup.
It is setup by a counter which after a certain number of clocks activates the chip select line. According to Midways own documents this is to ensure proper startup/shutdown of this NVRAM to prevent data loss.
There is a PLD chip at location 1F which decodes these writes to the counter. I have successfully reversed this chip and a replacement can be programmed into a GAL16V8.

Anyway, The RAM’s checked out fine.
Maybe I should try running the game.
Little did I know before taking this on that the game uses HV sync lines instead of composite sync. I initially made up a simple circuit to combine these which seemed to work but my test TV is quite picky about certain sync signals and just displayed a black and white picture. I then recalled that my 1084 monitor can accept HV sync.

Unexpected to see this working in a fashion. Clearly the graphics are a bit messed up but its playing. The screen is flipped as I did not have the SSIO board attached at the time.
So whats wrong with these graphics.
All the ROM’s checked out fine.
There are a lot of 93422 RAM chips on this board that I cannot test using my usual methods.
The answer was writing my own test program for the Boardmaster 4000.
All these RAM chips tested good.
Feeding the address lines to these 93422’s were a bunch of 74LS169’s. Probing these quickly showed the chip at C12 had some stuck outputs when compared to the rest of them. Replacing this chip cleared up all graphics issues.

Nearly time to hook up the SSIO board. Before doing this I checked all the chips I could. All the ROM’s were fine.
As the SSIO board has its own processor I was able to test this board independently of the others.
With the Fluke attached I could not get a consistent read off the ROM’s.
I found a shorted out 74LS374 @ A5. This chip is the link between the SSIO and the main PCB data lines. With this replaced everything was good.
Now with the SSIO connected the screen flipped but I get the “Sound Board Interface Error”

This “fault” gave me the run around for a week, literally!
It was a issue that I had actually caused in the end as when I removed the ROM’s I didn’t take note of which way around they were. Enter mystery #2.
I went as far as disassembling the code to see why this error is given. Here is what it does.
The main PCB writes data to the audio latches at address $1C-$1F, it then looks for the same data returned on the audio status address at $7
At this time the SSIO reads the latch data, compares it against the values it expects and if all the latches match it then writes the value into the audio status for the main PCB to read.
It does this for several values. If any of the values don’t match or it times out then you either get the “Interface Error” or the “Timeout Error”.

With all this in mind I went about checking this whole circuit. It all checked out fine. This is what led me onto looking at the ROM locations and finding that MAME has these two labelled wrong. They were in the right address space in the driver but the locations for A7 and A8 were swapped in the filename.
With this corrected the error message was gone.

On to the sound itself.
Here is where my main headache happened.
As I was using a switcher there was a lot of noise present on the audio section, so much so that I could not make out any clear unamplified audio signals. At this point I went ahead and injected my own signal in at a point and followed it through.
Right away I found all three of the 4016 chips were burning hot after seconds of power on. I replaced all these.
As I couldn’t get anything at my test speaker I tried replacing the op amps with no luck.
After a lot of patchy testing sessions I just suspected some bad AY-3-8910 chips so ordered a load up.
Before receiving these however I saw that the game uses another PCB. This one is an amplifier PCB.
Taking some advice from Irongiant I butchered the audio cable from a set of powered speakers and hooked them up to the output pins. With the sound test running and the volume turned up to full I could just make out the sounds of the game. This was kind of encouraging as it meant the board was actually running and playing the right sounds.
All I could think of was shotgunning the capacitors and just before placing an order I remembered I hadn’t tested something.

A few days back I posted a message asking if anyone knew what kind of volume I would get out of this if the volume potentiometer wasn’t installed. No one really knew and I forgot all about it.
So before pressing the “Confirm order” button I went and tested the pot 1kohm pot I had ordered. To my surprise the audio was nice and loud with this installed and was fully adjustable.

I coined up the game but was greeted with some odd screens that didn’t match what I expected.

This is one of 3 different screen showed.
After asking Ben he confirmed that if you press the accelerator when it is coined up it will show these screens. Doesn’t explain why they were so messed up so checked in MAME and they too were a bit messy looking.
Entering the test menu and poke about the pins to get the values for the accelerator to change so I am confident they work to some degree but I cannot test the player controls any further.

When I start the game the car accelerates off and to the left causing it to die immediately.
This kind of concludes my testing of this board set.

I would also like to thank the following:
Ben76 for sending me this stuff
David Haywood/Phil Bennett for their help in confirming my issues with the ROM’s
Irongiant for putting me on the right path with the sound
Equites for his kind offers of parts if I needed them
Frothmeister also for his kind offer of parts
anyone else that has helped or provided any input what so ever