HAL21 repair log

 PCB Repair Logs, Repair Logs  Comments Off on HAL21 repair log
Aug 272015
 

Got this HAL21 PCB from my frend Josef for a repair.The game is  a vertical shoot ’em up produced by SNK in 1985, a mix between Xevious, Terra Cresta and Alcon.

Board was in good shape given its age:

HAL 21_PCB

but fautly since it didn’t boot at all, stuck on a static garbage screen:

no_boot_missing_red

First thing I noticed (besides the fact that it didn’t boot) was the wrong colors, specifically the red one was missing. My friend Josef gave me an hint pointing me to a missing transistor 2SC1815 @Q1 near the edge connector:

2SC1815_missing@Q1

Actually this transistor was for driving the RED ouput (the other two are for BLUE and GREEN) so replacing it restored correct colors:

no_boot_correct colors

So, I started my real troubleshooting .Hardware is made of two Z80 CPUs ( a main and sub one) plus a third one for the sound.I decided to hook up my Fluke 9010A in order to perform some test on main CPU.MAME source reports this memory  map for the RAMs:

AM_RANGE(0xe000, 0xe7ff) AM_RAM AM_SHARE(“spriteram”) // + work ram
AM_RANGE(0xe800, 0xf7ff) AM_RAM_WRITE(marvins_bg_videoram_w) AM_SHARE(“bg_videoram”)
AM_RANGE(0xf800, 0xffff) AM_RAM_WRITE(snk_tx_videoram_w) AM_SHARE(“tx_videoram”) // + work RAM

When I performed a long RAM test on the first and third address spaces, I get an R/W error from Fluke 9010A.With the help of its probe, I could located the involved chips, eight 2114 of video board:

2114_RAMs

I probed them with my BK Precision 560A in-circuit tester which reported bad devices for the four ones on the right :

2114_in-circuit

I took this result with reservations, most likely not all four chips were bad but one certainly and  this affected the other ones (due the fact they share same address bus) misleading the tester.Not being able to accurately identify the faulty chips I desoldered all the four and I found two bad ones @6L and 7L:

2114_failed_out_of_circuit

With two good 2114 RAMs fitted, the board properly booted with no further issues.Mission accomplished.

fixed

 Posted by at 9:07 pm
Aug 252015
 

Got this Sunset Riders PCB always in a trade with my friend Ifog:

Sunset Riders_PCBJPG

Board was really in mint condition but, as my friend warned me, it was faulty.

Actually when I first powered it up it played perfectly but after some minutes it showed an issue where some parts of graphics had wrong colors (pinkish, I’d say) :

color_issue

Since I have repaired other similar Konami boards with same issue, I already knew where start to look at.Palette RAMs are two 2018 devices @13D and 14D:

pallette_RAMs

I probed them with my oscilloscope but didn’t notice anything abnormal (though they were hot at touch), also piggybacking them didn’t change anything.So, I went more ahead in the palette circuitry following the path of the data bits of these RAMs.Just before the generation of the three RGB colors there are some open-collector buffers (74LS07):

palette_circuitry

Probing the one @8C with my scope, I found discrepancies between input pin 3 and output pin 4:

7407@8C_waveform

Once desoldered, the IC failed on pin 4 indeed:

7407@8C

Comparing on a tracer the bad output with a good one, you can see how the internal junction was altered (good one on the left of the below picture):

7407@8C_comparing_tracer

Fitted a good IC fixed the colors.

Success!

 Posted by at 11:31 pm

Knuckle Bash repair log #1

 PCB Repair Logs, Repair Logs  Comments Off on Knuckle Bash repair log #1
Aug 212015
 

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

Kuckle Bash_PCB

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:

issue

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:

GFX_MASK_ROMs

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

GFX_custom

Also schematics confirmed this:

GFX_MASK_ROMs_addressing

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 :

fixed_with_clamp

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 ) :

leaking_capacitors

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.

 Posted by at 7:25 pm
Aug 192015
 

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

Heavy_Barrel_CPU_board

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 :

board_cleaning

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:

ROM_board

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

Boken_74LS08@18H

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

74LS08@18H

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

tiles_issue_

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:

24@17F_warning

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

27512@17F_broken_pins

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

backgrounds_fixed

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) :

sound_mixing_

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:

100nF_mylar_capacitor@C3JPG

I desoldered it and had confirm it was really shorted:

100nF_mylar_capacitor_shorted@C3JPG

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

 

 Posted by at 11:11 pm

Robocop repair log #2

 PCB Repair Logs, Repair Logs  Comments Off on Robocop repair log #2
Aug 172015
 

Got this original Data East Rocobop for cheap:

Robocop_PCB

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:

digital_sound_section

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:

DATA_lines_comparing_TMM2015@2F

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

TMM2015_RAM_2F

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

 Posted by at 10:27 am