Jul 122019

Got in the mail today this Tatsujin Oh PCB (japanese release of Truxton II), a great vertical shoot ’em up released by Toaplan in 1992 :

The board was bought on eBay and according to the seller it didn’t accept credits.But actually, when I powered it up, it booted to a ‘TILT’ message screen and then kept resetting in an endless loop:

I have experienced this issue many times and the culprit was always him,  the “infamous” ‘HK-1000’ :

This custom IC handles all the inputs including SERVICE, TEST and TILT and it’s a very prone to failure part, especially the first ceramic revision (like the one present on this board) cracks very easily or goes internally bad.As you may know, I have done a reproduction of this custom IC so I installed a unit after removed the original part and put some round machine pin headers :

Board booted now into game and correctly played but audio was loud, especially explosions and other sound FXs :

As you can see in above video I could not even adjust the volume by acting on the 1K potentiometer :

So I removed it:

It was broken as it fell off in pieces :

I installed a good one:

Sound was fully restored, board 100% fixed.End of today job.



 Posted by at 3:55 pm
Jul 112019

Received some days ago an Out Zone PCB for repair :

Board was marked as faulty with player 2 stuck in down direction and so it was when I powered it up:

Probing the P2 DOWN pin (19 solder side) on the JAMMA connector revealed it was floating as if it was not pulled-up :

Checking the relevant pin of the 4.7KOhm resistor array (which acts as pull-up) gave me a value of 3.8KOhm, there was something pulling it low:

The signal from the resistor array goes then to pin 4 of a 74LS240 @15M whose resistance to GROUND was only 2.2KOhm:

I removed the IC :

Although the chip was tested good out-of-circuit I replaced it :

This fixed the issue with player 2 but the board suddenly died while I was testing it giving me a solid black screen on power up.From the top of my experience with this hardware I know that the audio circuit must be running otherwise the board will not boot.When I checked the Z80 audio CPU I found the clock input stuck low :

The clock is derived from a 28MHz oscillator:

The scope confirmed there was no periodic signal from its output, ther oscillator was dead:

I pulled it out :

Fitted a spare:

Board booted up again with no further issues.Repair Accomplished.

 Posted by at 9:51 am
Jul 072019

Today I’ve uploaded the latest version on my BINman software to v4.5.0
The main addition here is the inclusion of Fluke 9010 signatures to the checksum area.
Not only does it have support for the 8 bit signatures it also supports the 16 bit signatures.
For 16 bit signatures, it will only support single files so if your hardware has the files across 2 EPROM’s then these will need interleaved or whatever is required to merge them.


 Posted by at 8:04 am
Jul 052019

Received an ESP Ra.De. board for repair for my friend Vic.

This was the video I was sent originally

This PCB had apparently had work done before but all we knew was the big 240 pin custom chip had been reflowed. This always makes me nervous because if it was destroyed somehow then all further attempts of repair would be for nothing unless I had a donor.
Visual check carried out of the board in general revealed nothing bad so hooked it up to the test. As expected we have no sync and the game does not appear to be running either. I confirmed this as the watchdog was kicking in.
Using the scope I probed the sync pin at the JAMMA connector and found a low sync signal of 13khz.
I started tracing the signal back but it went to the big custom chip that I already knew had been worked on, I also confirmed the main clocks and signal to the custom chip.
With no other ideas at this point I decided to tackle the game booting issue. The 68000 CPU was already in a socket so using the Fluke 9010 with a 68000 POD (Thanks Caius for the extended loan of his POD) I could start troubleshooting.
First off a BUS check revealed data bit 2 was tied low. In actual fact data bits 2 and 3 were shorted together.

I started tracing all the point where these data lines go and one by one started isolating them from the circuit. Once again my search led back to this big custom chip.
Reflowing these two pins on the custom cleared the fault.

At this point I took a closer look at this custom and found if I got the light in at the right angle I could see a lot of dried flux underneath.
Over time flux residue will dry out if not properly cleaned and it can go conductive.
I cleaned this and the bus test now passes. The ROM check between 0x0 – 0x7FFFF should be 1BBA which also passed.

The main RAM lies at location U39 & U40, 0x100000, 0x10FFFF. The Fluke reported a decode error on bit 1 which basically means there is a problem with the address lines.
Doing some manual reads and writes I could see that bit 1 of RAM U39 did not work. I replaced this and retested which then went OK.

I started my way through the rest of the RAM location as per the MAME driver.
The sprite RAM lies at U43 & U44, 0x400000, 0x40FFFF. Once again the fluke reported bits 5 & 6 tied together and once again I was led back to the same custom chip.
From here I just opted to reflow the whole chip. This cleared the issue with the sprite RAM. All other VRAM passed tests.
Retesting the PCB now resulted in a nice looking game for the most part but there was a strange strobing around test and lines that were white. Going into the test mode made this very obvious.
I couldn’t get a good video of this as it all looked fine on a camera.

To began with I thought this was all to do with my test monitor and the sync being a tiny bit high for it but I tested it on all my monitors and cabs and they all gave strange results.
I eventually went back to that custom chip and inspected all the pins again.
I couldn’t visually see anything but checking continuity on all pins against the adjacent pins revealed a short somewhere around pin 190. A further reflow of these pins resulted in a completed repair

One strange thing about this board is that on boot up it stays in a reset state for around 2 seconds which is the point where the sync reads 13khz. After that the sync steps up to 15.23khz and all OK.

Here is a layout of all the RAM locations on the PCB

 Posted by at 4:38 pm
Jul 042019

Received a Parodius DA! PCB for repair, a shoot’em up and second title in the Parodius Series produced by Konami :

Board booted up and game was fully playable with sound but sprites were wrong:

First of all I launched a MASK ROM check which reported two bad devices @K2 and K8 :

They are, indeed, 4Mbit MASK ROMs that store sprite data processed then by the near ‘053244’ and ‘053245’ custom ASICs :

The result of the check didn’t imply the devices were really bad but also that they could be not reached.So I went to probe them and found that pin 1 of the MASK ROM @K2 was floating while same pin of the one @K8 was active :

Pin 1 is the highest address line of the MASK ROM and should be in common between the two devices whereas, at quick check with a multimeter, it was not.Hence the trace to pin 1 of device @K2 was interrupted somewhere.I added a jumper wire on solder side:

This did the trick, sprites were restored and board 100% working again.Repair accomplished.

 Posted by at 6:47 pm