Repair Logs – Page 90 – JAMMArcade.net

Fluke 90 repair log

Aug 232015

I’ve come to the conclusion that I will probably never own the 6809 pod for the Fluke 9010. Accepting this fact led me to find a Fluke 90 6809 tester.
These things are a far cry away from the capabilities that the Fluke 9010 offers but they still offer some decent functionality.

I got one of these from the US quite recently and it was, as far as I could tell, unused. It was still in its wrapping and is in pristine condition.
Ive got a couple of games that use 6809 CPU’s to hand so thought I would give it a try out.
IMAG1483

I first pulled Breywood out and clipped the test clip over the CPU but I got an “ERROR 4 UUT CPU BUS REQUEST FAIL”. This means that the /HALT signal cannot be driven.
Its at this point I found the “Getting Started” guide online.
This states that the /HALT line cannot be tied to VCC. Breywood does indeed have this pin tied directly to VCC (and not even via a resistor).
Thinking about it I probably caused this fault by not reading the manuals prior to using it.

Time to break this thing open.
IMAG1485

The Fluke 90 needs to be able to drive the /HALT pin and it also does a check on startup that it can do this. If it cannot drive the pin then it flags up the fail message.
As you can see in the above picture there are a few discreet components for this section. Doing some quick poking around with the logic probe revealed that the emitter on one of the NPN transistor (towards the top on the picture) was dead. I removed the transistor and checked it out of circuit, sure enough it was dead.
I replaced both of these transistors just in case and tested.
IMAG1482

Everything now seems to be working fine.
I’m really pleased with this unit. It has some nice features like being able to set breakpoints (if connected to a PC)

Knuckle Bash repair log #1

Aug 212015

Got this faulty Knuckle Bash PCB in a trade with my friend Ifog:

For the uninitiated, it’s a side-scrolling beat ’em up developed and published by Toaplan in Japan in the 1993.

As expected, on the power up I was greeted by this scenario:

Game was playing almost blind, all graphics were totally wrong replaced by colored blocks.All the GFX DATA are stored in four 42 PIN 16Mbit MASK ROMs:

These devices are addressed by the near custom ASIC ‘GP9001’ @U13 which is the graphics processor unit of the system:

Also schematics confirmed this:

When I went to probe address lines of the MASK EPROMs, I found that most of them were silent.A closer inspection revealed the many pins were lifted.Pressing the custom chip with a clamp (a rude method perhaps but always effective) restored all the GFX :

So, I did a reflow of the custom chip passing the iron tip on its pins (with the clamp still in place) and this fix GFX stably.

Last thing to do was replacing some leaking 10mF axial electrolytic capacitors in the audio section (luckily corrosion didn’t involve any traces ) :

Another great game preserved to eternity (well, hopefully…)!

P.S.

This board turned to be an undumped Korean revision.I sent dumps to MAME developers.

Heavy Barrel repair log #1

PCB Repair Logs, Repair Logs 2 Responses »

Aug 192015

Another Data East board on the bench today, it’s the time for an Heavy Barrel one from my collection :

As you can see from picture above, CPU board was in bad state, very dirty and dusty (besides it missed a couple of RAMs) so I decided to clean it washing with soap, toothbrush and warm water :

Since drying the board under the sun would take some days and given that I have two Robocop PCBs which share the same CPU board of Heavy Barrel, I decided to troubleshoot at least its ROM board:

The first visual inspection revealed a broken IC @18F:

Thanks to schematics (but after removing its pieces I found also the silkscreening under it) I could identify it in a 74LS08:

So was time to power it up for the first time getting this result:

Game was fully playable but with wrong backgrounds graphics.MAME source reports two set of tiles ROMs for each layer so I went to dump the first one to do a compare.When I tried to read the ROM ’24’ @17F, my programmer gave me a warning:

I pulled the 27512 EPROM device off the programmer and some pins started to fall off in my hands:

I burned a new device and this fixed the backgrounds issue:

I was thinking board was 100% fixed but while I was testing it, an horrible sound came from speaker:

Sound FXs was barely audible replaced by the noises above.PCM samples are played by the usual OKI MSM6295 located on the ROM board.Diverting the OKI analog output (pin 36) to an external amplfier I could hear clear all the sound FXs but then the signal was lost along the way before it hit pin3 of 1458 OP-AMP and then be carried to CPU board to be mixed with the music (I circled in red the exact point) :

In this small part of circuit there are few discret components so I went to test them with my multimeter set for continuity test.When I put probes on the 100nF mylar capacitor @C3 the multimeter buzzed:

I desoldered it and had confirm it was really shorted:

Fitted a good capacitor restored full sound.End of job.

Robocop repair log #2

PCB Repair Logs, Repair Logs Comments Off

Aug 172015

Got this original Data East Rocobop for cheap:

Board was marked as not working but when I fired it up all was fine except for sound what was completely missing.Swapping boards with another working set I had , I could pinpoint fault in the top CPU board.Analog section was fine so fault was of digital nature.Sound system is made of a main 6502 CPU, a YM3812 and YM2203 sound synthesis chips:

Probing the 6502 CPU I found that it was undergone an hardware interrupt since its NMI line (pin 6) was low.Technically speaking an interrupt is an asynchronous signal generated to CPU from external peripherals indicating an event that needs immediate attention.

This lead me to think that the YM3812 or the YM2203 were bad (the IRQ line – pin 4- of the 6502 is connected to both these devices) so I desoldered them.But I was wrong since they were good.Analyzyng with a logic probe the TMM2015 SRAM @2F connected to the 6502 CPU revealed nothing abnormal but this didn’t convince me so I used my analog oscilloscope and found weak signal on some data lines compared to healthy ones:

I piggybacked the RAM and sound was fully restored.Time to desoder and test the IC out of circuit in where it failed:

Fitted a new RAM and archivied also this board as fixed.

X Multiply repair log #4

PCB Repair Logs, Repair Logs Comments Off

Aug 162015

Got this Irem X-Multiply PCB (actually a conversion from an Hammerin’ Harry M81 board) from my friend Josef for a repair:

It showed a graphical issue where some sprites (like enemy shots) were blocky during gameplay and backgrounds missing during attract mode:

Sprites and tiles data are stored respectively in eight 1Mbit EPROMs on video board for a total of sixteen devices.

Original devices were 1Mbit 28 pin MASK ROM:

https://pdf.datasheetarchive.com/datasheetsmain/Datasheets-X2/DSA62700099.pdf

while who made this conversion used ST M27C1000 :

https://pdf.datasheetarchive.com/indexerfiles/Scans-065/DSA2IH00172244.pdf

Video board has some jumpers which must be closed according to the type of adopted devices :

In this case the jumper configuration was set to ‘EP’ so not suitable for 27C1000 but required the use of JEDEC devices like 27C1001 or 27C010 (while the ‘MASK’ setting can work straight only with the original 28 pin 1Mbit MASK ROMs and not with 27C1000 which, although the similar pinout, have some extra pins to deal with, so some modifications are needed)

Reprogramming all the data for sprites and tiles into 27C010 1Mbit JEDEC EPROMs fixed graphics completely.

Older Entries Newer Entries