Time Pilot repair log

Got Muddymusic’s Time Pilot on the bench this time.
This game gave me the run around for a lot longer than I anticipated due to reasons I don’t really understand. Maybe someone can help me understand why.

So the game was meant to have two faults. The first was the RIGHT control didnt work. The second was the sound did not work.
Straight away I ran into problems. I could not get this board to sync with any of the 3 screens I have on my test rig, it also wouldnt sync properly in my Astro City cab.
I have recently bought a couple of those mini cabs and one was stripped out at the time so I used the monitor from that and the board seemed to sync up just fine.

There was that big red border around but I recall having the same thing on a Circus Charlie board I fixed so thought nothing of it.
Playing the game led me to think the background colours were missing.

I spent about 3 days going right through the schematics and running tests with the Fluke 9010 to figure out what was wrong. I couldn’t understand it. Muddy claimed that the background colours were present before he sent it off.

As I started doing more and more testing I started to get new faults with the sprites. I needed to figure out which chips were the sprite RAM’s so I reversed the ‘custom’ chip known as K526. In reality this chip is an 82s153. I dumped the chip and reversed it into equations

Pin 1 = MREQ
Pin 2 = RFSH
Pin 3 = A15
Pin 4 = A14
Pin 5 = A13
Pin 6 = A12
Pin 7 = A10
Pin 8 = F4

0xb400 (spriteram2)
/o12 = /MREQ & RFSH & A15 & /A14 & A13 & A12 & A10 & /F4

0xb000 (spriteram1)
/o13 = /MREQ & RFSH & A15 & /A14 & A13 & A12 & /A10 & /F4

0xa000 (main ram. covers color ram and video ram too)
/o14 = /MREQ & RFSH & A15 & /A14 & A13 & /A12 & /F4

0x8000 (Goes to pin 12 of 501 custom and also F3.)
/o15 = /MREQ & RFSH & A15

0x6000 (enable for unpopulated ROM socket, H5)
/o16 = /MREQ & RFSH & /A15 & A14 & A13

0x4000 (ROM H4)
/o17 = /MREQ & RFSH & /A15 & A14 & /A13

0x2000 (ROM H3)
/o18 = /MREQ & RFSH & /A15 & /A14 & A13

0x0 (ROM H2)
/o19 = /MREQ & RFSH & /A15 & /A14 & /A13

I figured out that the 4 x 2114 chips at D7 – D9 were the sprite RAM. 3 out of 4 had failed one by one so I ordered some up and replaced them when I got them.
All the sprites were back but still no background colours.
In a desperate attempt I wired the RGB-S straight into a scart connector to try a different TV. This is what I got.

The backgrounds were there all along but for some reason my other monitor wouldnt display them. I know the monitor works fine with my other games but why I did this I have no idea. If anyone knows or has any theories I would love to hear why.

On with the repair.
As you may already know this board gave me the opportunity to test Shoestring’s diagnostic ROM. After a few teething problems we got it working and I was able to test the player inputs. To my surprise they all worked fine and testing in game confirmed this. No idea why it didnt work for Muddy but it works now.
After getting the game up and running with background I noticed the main ship sprite was no longer a ship (see picture above).
Lightly flexing the boards fixed the problem but then the board stopped working. The Fluke was already plugged in and running test gave me a DCD error.

This error means there was a problem with the RAM addressing/decoding. This issue is normally missed by POST routines as they simply write a value to an address and read it back comparing it. The Fluke doesnt do this. It writes specific values to specific addresses so if there are any addressing issues it can tell. My issue ended up being caused by me. There was a tiny flake of loose solder bridging two address lines on the main RAM. Removing this made the game boot again but now I had another issue.

The graphics were now doubled up.
This was easy to find and ended up being a dodgy socket on the 082 custom chip at location F5. I replaced the socket and now everything was good again.

With that all done it was on to the sound.
I was getting a little tired of looking at this board so after a few preliminary checks I just desoldered the Z80 and fitted the Fluke.
BUS CHECK showed bit 0 and bit 1 were stuck LOW. I wrote 0x55 to a point in RAM and read it back, I got 0x50.
I then wrote 0xAA to the same point and read it back, I got 0xA0.
Looking at the schematics I pinpointed the offending RAM chip to the 2114 at B7.
Replacing this game me back the sound.

On the final test the sprites died again!!
I replaced the last 2114 RAM chip on the main board and this is now 100%