PCB Repair Logs – Page 12

Sheriff (conversion) repair log

PCB Repair Logs Comments Off

Jun 072019

Had this guy on the bench for far too long now. The reason? Its a horrible mess of wires used to convert it from something else. Not sure if this was some kind of factory conversion or someone was churning these out at one point in history but its not really something I want to work on again.

So, on power up I get this

When I first saw this on the video I was sent my first thought was one or more 161 counters had gone bad and then I started looking at the schematics (for Bandido) I found what I hoping to find.

There are actually 4 of these (the other one is on the previous page) so I was half prepared for when the PCB arrived.
When I tested the PCB for myself I could make the issue slightly better with more voltage but never managed to get it perfect within the upper voltage limits.

First thing I noticed on arrival was although the schematics were accurate the chip locations were not.
Like I said at the start of this the PCB is a mess of wires which are directly soldered to other parts of the PCB’s which made taking this stack apart a little tricky but needs must so I did.
Finding a bank of four 161 counters was easy enough.

Feeling sure of my diagnosis I removed all four counters and tested them out of circuit but they all passed.
I socketed and replaced them anyway as I know from previous experience these are a fail point.
When I retested the game the graphics issue was now fixed! I could even lower the voltage to 4.8 without problems. I guess these old ones had started to fail and gone out of spec.

Next issue was the sound but before looking into that I was very curious about the intermediate PCB half hidden under the sound board.

This thing is a horrible freak of nature.
I knew it was something to do with the controls but why so much circuitry? What is that EPROM looking chip on there? and why did it look homemade?
Sadly I don’t know the answer to that last question but I have a fair idea of what the other two are.

First up that EPROM looking thing.
I desoldered it and tried to identify what it was. Best picture I could get from the scratched off markings were this

I could see it was likely a Toshiba device and it had “333P” appended so after a fair amount of sleuthing It was deduced that it was TMM333P device.
As I had no way of reading this with any of my programmers I resorted to using the faithful Arduino to dump its contents. After successful extraction it actually identified in MAME as a ROM from Jatre Specter. This made little sense until I traced out the connections and realised it was actually hardwired to address $4E7 so one ever gave out the byte 0x3A. Furthermore only 5 bits of the byte were being used and they are only used to permenantly enable the adjacent logic chips.
My best guess here is the bulk of this PCB is for obfuscation purposes.
On another sidenote, I tried making a small replacement PCB for this using a CPLD and while it worked as expected without the outputs connected it went wrong when they were connected up. Looking on the scope I could see a fair bit of bus contention so I think the CPLD was just too fast for this old hardware.
Anyway, on with the repair.

There was no sound. I started probing around the 8035 and found it was giving out garbage. I pulled the 2708 ROM and found that also full of garbage. I did try erasing it and reprogramming but it wouldn’t program at all. I replaced this with a slightly modified 2732 EPROM.
I ordered a new 8035 and while waiting I decided the best course of action would be to refurb this whole PCB as much as I could. All capacitors were replaced and replaced some of the logic IC’s too just for good measure.
Found a few dodgy looking solder joints like this one along the way

The replacement 8035 came from eBay but it was DOA. The seller send me another no questions asked and this one worked fine.
That’s about it for this one.

Worth noting with this conversion that it was been wired to use the player 2 joystick as the aiming function for player 1.

Nemesis (Konami GT conversion) repair log

PCB Repair Logs Comments Off

May 252019

Received from Portugal a faulty Nemesis PCB for repair, actually a conversion from Konami GT on GX400 hardware.Set is made of a CPU board :

And a VIDEO board :

The game was full playbale with sound but the graphics were glitched as there were jail bars all over the screen:

The fault was obviously located on the bottom VIDEO board therefore first of all I ruled out all the custom ICs by swapping them in a good board, they were all OK.Then I focused on a couple of rows of 4164 dynamic RAMs (some were already replaced) :

They are 64K x 1-bit devices, here’s pinout :

On this board they are used as sprite line buffer like schematics show :

I went to probe them with my scope and I found one with an unhealthy signal on data output pin (good signal for comparison on left of below picture) :

It was the chip @5H which I prompty removed and replaced with a good one :

This fixed the issue and board competely.Repair accomplished.

Capcom CPS1 – Street Fighter 2 CE repair log

May 032019

A while back I got my hands on a cheap CPS1 set for Street Fighter 2 CE. The reason it was cheap was that the A board was not working. As we know by now, these A boards are dying quite fast and in some cases the culprit is the Custom CPS-A-01 chip for which there are no know replacements as of yet.

Let’s have a look at what we get on screen first

So it seems we’re only getting half the lines in the sprites and , while it’s not visible on a screenshot, the other half is flickering slowly too.

Looking at the schematics we can see the two parallel banks of rams processing each odd/even lines of sprites. These are coming straight out of the CPS-A-01 GPU IC. Let’s check out the DT/OE enable lines or the rams first.

Looking at them in with the scope reveals a couple of issues:

The bottom one is pin 21, and it’s not really toggling apart from that one regular jump, while we can see that the other line is toggling all the time. This is why we’re only seeing half of the sprites: one bank is not being enabled.

The other issue is this jump on both lines which is most likely why the entire sprites flicker regularly.
These are coming from Pin 21 and 47 of the cpsA .
bank A pin 21
bank B pin 47

Tying the enable line of bank B to bank A will restore the sprites but we still have the issue of the flickering sprites… in a nutshell, the CPS-A chip is fried and this A board is toast.

Luckily a viewer of the youtube channel (thanks Kris Ankers!) sent me a spare A & B board.

The board is in unknown working state . Checking the few remaining proms it’s another SF2 CE , not that it makes much difference here as we’re only interested in the A board. Let’s replace the A board on my other stack and fire this up

…nothing. board is dead.
A quick visual inspection reveals a few corroded badly corroded sockets on the BUF1 and ROM1 pals. corroded is an understatement here too since the socket were missing legs that had completely disintegrated.

Let’s put new sockets in place and see what we get.

Still no boot. I took both pals from my other set and dropped them in.
After some more swapping I found that the Rom1 pal is working so it was just the BUF1 pal that needed to be replaced.

Success!! The board is now booting and playable. Sound is also working fine.

But it seems we’re missing the red color.

A look at the schematics tells me me which ICs are handling the rgb output. We’ve got two rams outputting to 2 LS273 flip flops. This is then sent through ls07 and ls367 buffers, through resistor arrays before being output to rgb.

The difficulty here is that apart from the legs of the rams and resistor arrays which can be probed from the underside, the other ICs are SMD and hidden by the b board so I am not able to probe the legs. Time for some logical guess work :

Since the pairs of ls07 and ls367 are shared across the colors it’s unlikely one of those has failed or it would affect more than one color (still possible but unlikely)
Two resistor arrays are needed per color. If one had failed, we’d get some red at least but here it’s all gone and while it’s possible, it’s unlikely two are gone
So I’m first going to look at the RAM at 1C and the 273 at 4C
Probing the RAM seemed ok so I decided to remove 4C and replace it.

Bingo!

Behold a working (for now) Street Fighter 2 CE CPS1 stack. It’s a bittersweet victory though as there’s no telling when that CPSA chip will fail (not if but when) . But for now I’m going to enjoy some Capcom fighting. Thanks Kris for the PCB donation !

And for those who prefer the video format…

Tough Turf ( Sega System 16 pcb) repair log

PCB Repair Logs 1 Response »

Apr 282019

Some weeks ago I bought this game for my collection in really great conditions.

While playing, I messed up with the external potentiometer of my supergun and menaged to detach it for a brief moment . Result was that the power supply jumped to 7V on the 5V line and 18V on the 12V line.

With my surprise, the game was not totally fried, sprites were still good but all the background was totally black

Also the game had no sound ( but the amplifier was still good)

For the graphics problem, 2k sram @H15 and H16 had all the data lines in the grey area.

Changing them restored completely the graphics.

The sound had also another UMC 6116 sram and the data lines were completely in the grey area.

Changing it led to no improvement but after checking the connections I found out D6 line was not connected to the Z80 but only to the YM2151.

I probably broken it during the exhange. Restoring the line led to a fully working game.

In the end it appears that UMC parts were the weakest devices of the pcb , I replaced all the ones which were present on the pcb

Teenage Mutant Ninja Turtles repair log

PCB Repair Logs Comments Off

Apr 222019

Got for repair from the States this Teenage Mutant Ninja Turtles PCB (actually the US 4 Player ROM set)

Board booted up with noticeable graphical issues, both sprites and backgrounds were affected as they were missing parts.Also colors were wrong, screen was blue tinted (hard to distinguish in the video and pictures though)

The palette circuit is made of two 2k x 8-bit static RAMs, a couple of latches (74LS273), some open collector buffers (74LS07) and finally three ‘052535’ RGB DACs that outputs each color to respective JAMMA edge connector pins :

A blue dominant means the RED color has some troubles so I went to probe around this part of circuit and found the 74LS07 @D23 (from Fujitsu, obviously…) with an output (pin 4) shorted to GROUND :

Chip failed in that pin when tested out-of-circuit:

Replacing the TTL IC restored the correct colors so I moved on the grahical issues.I launched a MASK ROM check which reported two bad devices @K4 and K6: