Repair Logs – Page 108 – JAMMArcade.net

Konami GT repair log

Jul 232014

A friend of mine sent me this really mint original Konami GT PCB saying it suffered from vertical stripes across most part of screen.

Fired up the board and …he was right 🙂

Initial test said all RAMs were good so the problem was elsewhere.Without any schematics I started my visual inspection as usual.I noticed that the only IC replaced on this mint PCB was a 74LS157 @H13.Since a socket was installed, I removed this IC and all the part of graphics affected by stripes disappeared so I started to think problem was generated after this part of circuit.In particular I traced an output (pin 7) of this 74LS157 to pin 4 (RAS) of some TMM4164 DRAMs (there are 16 of them).Probing these DRAMs with my logic probe revelaed that on four of them pin 2 (DATA IN) was pulsing but the pin 14 (DATA OUT) was stuck high.So I desoldered (they were @G2, G3, H4, H5 position) and test them in my Hi-Lo Systems ALL-07A programmer and the result was this:

They all failed miserably.I was lucky since had some good 4164 DRAMs taken from a scrap PCB in order to repair a Commodore 64 motherboard.Installed them and goodbye stripes for ever!Board 100% fixed.

Juno First repair log #3

Jun 262014

Third repair log from the batch of Juno First boards.
On power up the board was completely dead. No clocks were present on the CPU or many other IC’s.
As this is a bootleg board the available schematics do not fully apply and the clock circuit is normally handled by custom chips so this was a bit of a learning experience.
To help in dealing with this problem I started making my own schematics up.

Using a logic probe I could see that the outputs of the 74LS161 @ H14 were all HIGH. As there is no clock present to this chip it should not have counted anything at this point and they should all be LOW. This meant to the board was booting up in an incorrect state and the clock circuit was never starting.
I desoldered and replaced the offending 161 chip.

The clocks were now all present but I just got a static blue screen and the watchdog was constantly resetting the system.
Using my in circuit Arduino tester I knew the ROMs could all be read correctly by the CPU. I also knew all the program RAMs were fine.
Replacing the 6809 CPU allowed the game to boot properly.

Next problem was the sound or lack of it.
The sound CPU is a good old Z80 so I fitted the Fluke and did a ROM check. This reported back an incorrect signature and when I removed the ROM I see this

The VCC pin was missing. I soldered a new pin onto this and this board is fully fixed.

The last bootleg board has been a major pain and at this point in time I have admitted defeat with it. I have also been harvesting parts from it to fix the others so it will be written off.

Fujitsu FM-TOWNS Marty PSU repair log

Console Repair Logs, Repair Logs Comments Off

Jun 172014

I got from a German customer this nice Fujitsu FM-TOWNS Marty console.

For the uninitiated FM-TOWNS Marty a Japanese console whose hardware is derived from its “big brother” FM-TOWNS computer.It has some of the coolest perfect arcade ports ever published like Splatterhouse, Bubble Bobble, The New Zealand Story, Tatsujin Oh and others.

As every Japanese device it has to be powered by 100V/110V so European people must use a step-down converter capable to reduce our 220V/240V to proper voltage .

This is what the owner of this console forgot to do by mistake..:)

So, after some seconds the “magic smoke” came out from the console.

Obviously the console did not power at all so i opened it and I immediately noticed some blown components.In particular the main 2A fuse was blown and a 100uF 200V capacitor was literally exploded on its top.The blown fuse was a good sign since it means he made his duty blocking the excessive current flowing in the circuit but the big 100uf 200V exploded capacitor meant that this overcurrent reached also other components before the main fuse blown up.So, I decided to further investigate.Usually the first component after main fuse and filter capacitor is the bridge rectifier (which, indeed, rectifies the sinusoidal current in continuous one).In my case there was a 600V 1A bridge rectifier marked ‘S1WB S60’, here the datasheet:

S1WB Datasheet

Infact, as I suspected, I tested it with a multimeter and it was shorted.

So, I desoldered these three bad components:

and replaced them with equivalent ones:

Reassembled the console, powered it and got this:

Mission accomplished.

Juno First repair log #2

PCB Repair Logs, Repair Logs Comments Off

Jun 152014

So here is the second repair log.
Pretty simple this one but I never took any pictures of the actual fault so Ive taken a snapshot of the event in MAME to show it.

The game plays as normal but when the blue ball enemies spawn into the game the froze up on screen and did nothing as circled in red in the picture below.

On my visual inspection I noticed a 1K pull up resistor array next to the bank of 4116 RAM chips what cracked in half.

Replacing this fixed the fault.

I did initially think there was another fault as the ship movement in attract mode seemed a bit strange but after checking in MAME this is a characteristic of the non Gottlieb version. In the Gottlieb version this behavior is not present.

Juno First repair log #1

PCB Repair Logs, Repair Logs 3 Responses »

Jun 062014

This is hopefully one of five Juno First repair logs.
Thanks (I think) to muddymusic I have a stack of these needing repaired. There are two originals and three bootlegs altogether and decided to make a start on the originals first.

This one booted to an unsynced red picture.

Looking at the schematics I could see that the sync is generated by custom chip 082 at location EF13 on the bottom PCB.
Swapping this chip with the one from the other board set brought the sync back. That’s bad news for original board set #2.

So now I just had a red screen with nothing going on.
It was at this point that I learned this hardware uses a custom 6809 CPU known as Konami-1. I was originally going to try and borrow a 6809 pod for the Fluke but that put a swift end it that idea.
Now’s the perfect time to use my beloved Arduino again.
By hooking it up to the address, data, RW, BA and BS lines I wrote a program that would read the program ROM’s back and display the data as well as a bitsum for the ROM.
It worked really well and found my second issue.

This is the original HEX file

and here is what I was actually reading on the board

You can see that bits 0 and 1 are always on.

So the 74LS245 at location D7 on the lower PCB had a two stuck pins on D0 and D1.

Replacing this enabled me to read all the program ROM’s correctly.
I had at this point wanted to be able to test RAM too but due to the timings required and not knowing how those custom chips worked I left it alone.

So now I have a booting game but all the sprites and title screen graphics are missing.

First thing I did was see if I could replicate the fault in MAME.
By creating empty files to replace ROM’s 7C, 7D and 7E on the top PCB I got the exact fault.

Checking those EPROM’s with the probe revealed that none of the chips were ever being enabled.
Following the schematics back to where the ROM selection lines are generated I came to a 74LS273 at location 6D on the upper PCB. Pin 11 is the clock pin for this chip and I would expect it to be pulsing but it was stuck HIGH. Following the /SSEL line back to the lower PCB led me to a 74LS138 at location I6.

This had pulsing inputs but either stuck HIGH outputs or floating pins. Replacing this chip gave me the graphics back.

That’s one down.

Older Entries Newer Entries