PCB Repair Logs – Page 70

Pac-Man repair log #3

Feb 162016

Got the second board fixed up today.
This one had a lot more wrong with it and all caused by a previous repair attempt.
Visual inspection immediately revealed this.
20160207_133009

I confirmed these wires were going where they should be and neatened them up a bit.

As with the first board all I got was a blank screen with the board not playing blind. At this point I had my smaller custom replacements verified so could do away with stacking the TTL riser and could just plug the Fluke straight in.
ROM checks were all good but the RAM checks failed straight away.

With the previous repair still fresh in my mind I knew where to look. the 74LS245 at 4H. This had a turned pin socket fitted and a 74HC245 chip inserted. The HC variation means its CMOS logic levels and typically aren’t an ideal replacement for LS parts. If you are going to swap them out you can use the HCT variety which are TTL compatible.
I replace this chip with a 74LS245 but it did not fix my issue. Checking the outputs of the 245 to the RAM led me to suspect a poor desoldering job of the previous chip as several pins weren’t connected to the RAM. I desoldered the socket and found this mess.
20160207_133720

You can clearly see a the traces that have been ripped through. I patched these, fitted a new socket and continued my checks.
The Fluke now reported this.
20160215_203212

Knowing the chip was good and the connections to the RAM were good I focused my attention on the CPU side of this chip.
I knew my custom chips were good and I could correctly read the ROM’s so new the CPU socket was good. This didn’t leave me with many places left to look. I could almost certainly rule out some places as data bits 2 and 6 were across two different chips and the chances of both of the chips shorting together was a bit low. This left me with an 74LS273 at 4D and also to the dreaded crusty flux issue. Cleaning the flux cleared my short.
20160215_205328

Now the game would boot but I get this
20160215_205526
Only the score and credits were showing. If I started a game the lives were also showing at the bottom.

My attention immediately went to the 4 x 1bit RAM chips at 2A-2D and found there wasn’t a great deal of activity and some missing signals.
My heart sank right away as I could see turned pin sockets had also been fitted for all of these which most likely meant the same person had replaced them.
Sure enough there were several traces cut. I did remove one of the sockets just to see what I was up against.
20160216_193306
Some severed traces here and doing a continuity test revealed more and more. I also found one pin not soldered.
20160216_194329

A bit of time later after patching and verifying my work I fired it up and was all ready to feel pleased with myself on a job well done but the same fault was still present.
Confident the fault was still in the area I was already working I set back to work checking continuity and found the ‘Data In’ pin (pin 15) of a RAM at 2A was shorted to pin 1 of the RAM at 2B. Looking back at the picture I had taken I noticed a bit of stray solder bridging the trace that ran adjacent to pin 15 that I had missed earlier. I managed to remove it with a pin and a bit of patience.
After that the board fired right up and plays fine.
20160216_201142

20160216_201150

Pac-Man repair log #2

Feb 142016

I recently asked on UKVAC if anyone had a Pac-Man PCB I could borrow in order to test the recreations of the two custom chips I made for the CPLD replacement device.
JonHughes replied and a few days later I had not one but two PCB’s to play around with.
One was pretty much stripped of parts but the other was complete and even had the TTL versions of the two customs.
I already have a JAMMA adapter for this that I made for my first Pac-Man repair so I was all ready to go.
Visual inspection revealed nothing to be concerned about so I went ahead and fired the game up.
I got nothing. The game was absolutely dead. I checked for activity on the CPU address and data bus but they were static.
Checking the clock pin also showed up no activity. Probing around the clock section suggested that the crystal had died so I went ahead and replaced it but this didn’t help.
There was a small build up of old flux around capacitor C4 so I went ahead and cleaned this up. The clock signal came back!

So now I had this my clock back and activity on the address and data bus lines but I still had a blank screen and it wasn’t making any noise. I also confirmed the board was not watchdogging.
Since the Z80 CPU is already socketed I decided to use the Fluke 9010 to check the ROMs/RAMs. Here is where a little problem came as the TTL custom replacement covers over the Z80 so I fitted a few header to the pins to raise it up enough to fit the Fluke pod.
20160206_195844
With the Fluke connected I quickly verified the ROM’s and RAM’s were fine. It also verified that the connections between these chips and the Z80 were good.

Next step was to work backwards from the RGBS pins at the edge connector.
There was obviously no video output.
I found there was no activity coming out of the 74LS157 at 3A but some activity going in and to/from the connecting chips.
pacman_strobe

Checking the strobe pin (pin 15) of this chip I found the signal was stuck HIGH which basically means the chip was disabled.
Checking the 74LS00 at 4C showed I had activity on pin 12 but pin 13 was stuck HIGH. This being the /VBLANK it was clear that this was not correct.

The /VBLANK signal is given out by a 74LS74 chip at 5M.
Checking the signals on this chip I found the clock signal was stuck LOW.
pacman_vblank

This clock signal is 16V signal that is generated by a couple of 74LS161 4 bit binary counters.
pacman_counter

According to my logic probes there was no activity on pins 11 and 12 of the 74LS161 at 2R (the one that generates the 16V and 8V signals) but seeing as though this chip was already in a socket and it tested good in my chip tester I didnt believe what the probe was telling me so I fired up the scope to take a look at those pins.
20160214_165521

This is a good clear example of signal contention. You can see that the signal is trying to rise up but only getting to about half a volt. Knowing that the chip is actually good out of circuit confirms that there is another signal driving it low.
I found that pins 11 and 12 were shorted together.
I couldn’t see anything really wrong physically on the board where these two signals went so once again I opted to clean off the small bit of old flux I could see and once again this fixed my problem.
Although I’ve read about old flux causing issues I’ve never actually seen it myself until now so this has been a lesson learned for me.

Now I got this.
20160214_171848

The game is actually running here but there is garbage on the screen. If I left it running all the sprites came on the screen and were complete.
Before moving on I decided to test out my CPLD implementation of the syncbus controller custom. This gave me the same output so was confident it was OK. Now I though I’d try out the VRAM addresser replacement too and I got this.
20160214_183515
20160214_183521

All fully working with sound too.
The actual cause of the earlier fault was created by me as I had bent 2 pins on the VRAM module during one of the many remove/replace cycles I had done. I since confirmed this works fine too.

That’s this board fully working and the two replacements confirmed working too.

Thanks to JonHughes for providing me with these boards.

Rastan repair log #3

PCB Repair Logs, Repair Logs 6 Responses »

Feb 122016

Here is a picture showing a recently repaired Rastan PCB with the replaced chips highlighted in red.

rastan2-5

I will explain every step of the repair process here:

1) When powered up, the game was starting but was constantly rebooting after about 5 seconds. I checked the reset pin on the CPU but it was constantly high so that seemed not related to that. I checked the signals on the 2 CPU RAMs @ IC10 and IC22 (2x TMM2063 – 64kb) but nothing seemed suspicious. Anyway, piggybacking the one @ IC10 made the game not rebooting after 5 seconds but after a longer time. That was sufficient to let me think it may be faulty so I desoldered the RAM and it was tested bad on my programmer. Replacing it by a new one made the game working and not rebooting again and again. Good.

2) Well, the game was now playable but there was no FM sound (so no music at all), only voices were audible. Schematics are available online so I could see that the FM sound is generated by the YM2151 @ IC63 then it goes to an YM3012 DAC @ IC78 then it goes to a TL074 op amp @ IC100 to finally going to the MB3731 amplifier @ IC101. Outputs signals looked healthy at the outputs of the YM2151 and I had correct sound for the voices so the issue should be located before the mix between FM and voices signals, so before the amplifier: more probably within the DAC or the op amp. The TL074 is composed of 4 operational amplifiers:

rastan2-6

I noticed that every of the 4 output signals on the TL074 @ IC100 were looking weird with a negative voltage (between -1 and -2 V). There is another TL074 chip on the board that is related to the voices and every outputs showed a positive signal of approximately 2.5 V. That was suspicious so I desoldered the TL074 @ IC100 and replaced it by a new one and the FM sound was back ! (the signals on every 4 outputs were now showing a positive analogic signal of approximately 2.5 V).

3) and 4) Ok, so then the game was fully playable with perfect sound but there was some graphical glitches on a few items, as seen here in the attract mode:

rastan2-3

I have a previously repaired Rastan PCB that had one of its gfx mask roms replaced by an hacked 27C010 EPROM so, due to the nature of the problem here (glitches on only a few particular items), I suspected one or multiple MASK ROMs to be faulty. I started replacing these ROMs with the ones from my working Rastan PCB and got the gfx working perfectly after replacing B04-07 @ IC14 and B07-08 @ IC27. As noticed in my previous Rastan repair log, the gfx ROMs on this board are 128kb fitted into 28 pins chips. Finding blank chips with these exact specs is hard nowadays so I used 128kb 32 pins 27C010/27C1001 EPROMs as replacement (I could use a 27C1000/27C301 EPROM to make the modification even easier but I didn’t have one remaining then). To fit them on the 28 pins sockets present on the Rastan board, you have to make the following modifications on every EPROM:

If you use a 27C301 or 27C1000 non-JEDEC EPROM (simplest way):

Connect pins #30, 31, 32 together and connect them to pin #1 with a small wire.
Connect pin #2 to pin #16 with a small wire.

If you use a 27C010 or 27C1001 JEDEC EPROM:

Connect pins #30, 31, 32 together and connect them to pin #1 with a small wire.
Gently bend pin #24 so it won’t plug into the socket and connect it to pin #16 with a small wire.
Solder a small wire on pin #2 that you will plug into pin #22 of the socket.

I did these connections on the underside of the chip. Here is how it looks on my 27C010:

rastan2-2

And this is how it looks after the 2 chips plugged in:

rastan2-1

Now the gfx are fully restored, as well as the rest:

rastan2-4

Heavy Unit repair log #2

PCB Repair Logs, Repair Logs Comments Off

Feb 062016

Got this pcb to be repaired from a friend.

The pcb was working perfect excepts that the screen was flickering at 1/2 of the vsync.

As usual I visually inspected the board to find loose legs on smd chips but the only one present was good.

I noticed that the pcb had 4x rams 4164 near the video custom chip which are known to be not very reliable.

I started to probe the rams until I found one which had all the signals very weaks.

After soldering a new one, the problem was fixed!

Heavy Unit

Super World Court repair log

PCB Repair Logs, Repair Logs Comments Off

Jan 312016

Another pcb which was part of the cheap deal.

It was completely dead. Given that it is not an interesting game I was about to use it for spare parts when I asked my friend Caius if he ever repaired a Namco NA-1

He told me he once repaired one with a capacitor connected to the reset circuit of the 68000 which faulty and didn’t produce the reset signal.

I tested mine and to my surprise the reset was stuck low.

I changed the capacitor smd 22uF @C5 with one 1uF which I had available and the game booted.

Unfortunately the sound was completely missing, so I probed with my portable amplifier some smd capacitors which are know to be leaking very easily and I found one which interrupted the sound to the main ampli.

After changing it, the sound was very low with lot of background noise.

To end a long story short, I recapped many small smd caps with new ones and restored full volume.

This is a common problem with Namco NA-1 pcbs

Foto 30-01-16 21 58 07

Older Entries Newer Entries