PCB Repair LogsComments Off on Nemesis (Konami GT conversion) repair log
May252019
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.
I’m not dead!
Some time ago I scored a great deal on eBay for a Data I/O 29A setup with a load of modules and manuals.
Pretty much everything worked great apart from the display was really dim.
It doesn’t look too bad in the picture but it looked much worse in real life
Schematics are readily available for the unit so fault finding was fairly quick.
With the display being dim my initial though was a voltage issue and the schematics have conveniently labelled the area up as “FILAMENT SUPPLY GENERATOR”.
Using the scope I could see straight away the CD4049 hex inverter at U14 was not inverting at all.
Simply replacing this fixed the fault
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 !
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
PCB Repair LogsComments Off on Teenage Mutant Ninja Turtles repair log
Apr222019
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:
They are two of the four 4Mbit MASK ROMs that store sprites data:
I removed the first device @K6 :
I dumped it, the resulting buffer of my EPROM programmer was empty so device was really bad :
I launched again a MASK ROM check, the device @K4 was reported as good this time so the bad one @K6 was affecting it (data/address busses are shared)
I replaced the bad MASK ROM with a programmed 4Mbit EPROM (I used a Macronix MX27C4100)
Sprites were restored and check no more complained :
But backgrounds were still missing parts :
This part of graphics is entirely handled by the ‘052109’ and ‘051962’ custom ASICs:
On a visual inspection I found a lifted pin on the latter:
I reflowed the pin and this fixed board completely.Repair accomplished.
