Repair Logs – Page 3 – JAMMArcade.net

Silkworm repair log #2 and schematics

Apr 162024

Board is a bit dusty but very clean nonetheless. Some very specific chips are rusty, probably due to some rodent fluid. Tracks are invisible and located in the core of this 4-layer board making the inner tracks very fragile when pulling a chip out.

Game starts when powering the board with full sound and some graphics. The title screen has a white background instead of black as it should be. A similar white background appears during attract mode:

Cross-testing the board with a good one points the fault to the bottom board (graphics board). On this board I started probing the 8 EPROMs filled with the background graphics data. Some pins are quite corroded, so I decided to dump them to check their contents against MAME data:

As a result, EPROMs 10 and 14 are dead. I burnt two replacement EPROMs and that brought the background back:

Background is back but the sprites are blinking, they are misplaced and have bad colors. Sprites are generated by the custom chip Mitsubishi M60002-0118P and displayed through twenty 4164 DRAMs. These are known for having a high failure rate. I will focus my investigations in this area:

Probing the D-OUT pins of these DRAMs (pin 14), 8 DRAMs out of 20 shows an output signal stuck low or even floating when the game has to display sprites:

I pulled these 8 D-RAMs:

All of them were confirmed bad out of circuit.

I fit 8 brand-new replacement DRAMs. Some sprite glitches are still visible – two other DRAMs have just gone bad. I took those out and replaced them. Now the sprites and backgrounds appeared to be rendering properly. However, the sprites motion is still jerky.

Rygar shares the same hardware as Silkworm and has schematics available. In the schematics, we can see that two 6116 SRAMs handles foreground and background graphics and a third one is dedicated to sprite positioning (SP/POSITION.RAM as per the schematics). This is the area I will inspect.

Inspection of the SRAM chip at location 6L doesn’t show anything abnormal. While probing around the area, I came across a signal stuck high on a 74LS193 binary counter (BORROW output) located at 7K. I double-checked it with my logic comparator:

Red light indicated a bad output – I pulled the suspect:

Confirmed bad out of circuit:

Replacing this chip fixes the jerkiness. Game is perfectly playable. Sound and controls tested OK.

Summary :

11 DRAMs (SAMSUNG),
2 EPROMs,
1 74LS193 (TEXAS INSTRUMENTS)

Some months after this repair, I found the proper original Silkworm schematics, scanned it and upload to my GitHub here:
https://github.com/DocteurPCB/schematics/blob/main/Silkworm%20%5Bschematics%5D.pdf

Crude Buster repair log #2

PCB Repair Logs 1 Response »

Jul 082023

Hello,

This is my first repair log on an arcade board, i hope that my text will not be too long and useful to anyone having problems with their own PCB of the same game.

The preambule of this repair :

First thing first, i bought this PCB sold as broken with repair required, paid 130 euros.

On reception :

After pluging the board on my jamma system, i noticed that the board has at least 4 problems to fix.

The first is that i get japanese characters on screen. After reading each eproms and socketed maskroms, i see that FU-05 is from the wrong set. The solution was easy peasy : i bought a 27512 brand new on ebay, and burn the right content from the world set.

Once this first problem is fixed, i get this screen :

This error has already been solved by Porchy, this message appear when the routine that check the presence of the TC4 PAL chip fails. It indicates that the TC4 chip is wrong or toasted. And indeed, by checking with the magical finger touch, the chip is very hot.

So as a solution, i bought a replacement GAL 16V8 on ebay :

Now, the game boot correctly.

Let’s check the next problem to fix :

I see that the graphics are simply flashing constantly on the screen, it’s a mess. The culprit are the sram located here :

Those are TMM2063, and when i passed my finger on them, they were incredibly hot on touch, and the graphics were going crazy on screen. In order to confirm they are shot, i piggyback with new sram replacements bought on ebay : graphics are now fixed !

Let’s remove the buggers :

And install the brand new SRAMs :

Last problem to fix :

I noticed that jump button and start button for PL1 are not working. this board seems to have been connected backwards, so the RC1 custom components are shot. So i contacted Caius, who sold me 4 replacement RC1 pcbs, that i replaced on the board :

It was not easy to remove properly the dead RC1 components, i got 2 traces cut, that i patched after checking them with my multimeter.

Thanks to Caius on a few tips and hints here and there, the PCB is now fully working.

Another board saved ! 😀

Dlfrsilver

(With many thanks to Caius for the help and the replacement parts).

Duratool Desolder station repair log

Equipment Repair Logs, Repair Logs 2 Responses »

Apr 142023

I’ve used this cheap desoldering station for many years now. Despite its quirks and constant demand for cleaning its been a great work horse.

The an immovable blockage happened recently and I just couldn’t clear it so decided it was time to replace the element. I thought I had a spare from years ago but turns out I have ordered the wrong part.
Looking for the correct part I found it was almost the same price to buy a new gun part itself and I wouldn’t have to mess around slicing the wired inside.

New gun came and all was well in the world for around 5 minutes when the unit got stuck in a reset loop.
Obviously there was a short somewhere so set to work checking resistance until I found a shorted element.
All the wires for this thing are very tightly routed and when i pulled them out I found this

Those small breaks in insulation from being sandwiched together so tight caused my issue. A little bit of insulation tape later and I was back in business

Bosconian repair log #2

PCB Repair Logs, Repair Logs 2 Responses »

Oct 082022

Virtvic handed over his sick Bosconian PCB at a recent event for repair. I’d not seen a Bosconian before so it was interesting to delve into one and it also gave me a chance to redump the PAL chip for the Namco version as the one we have on the PLD Archive is flagged as bad.

On power up the game went through its self test process and displays “RAM OK” and sometimes “ROM OK” then reset itself and the whole process repeats itself.
The game uses 3 x Z80’s all working together which is a little bit of a pain but luckily the MAME debugger makes this a little less painless to aid in fault finding.
In the debugger I could run through the code and see what checks are performed in what order to better narrow down where my issue was.
The memory maps for each CPU are the same apart from the ROM’s for each processor. That means all the RAM is visible to all 3 CPU’s.
CPU 1 does all the RAM tests then it lifts the /RESET pin for the other 2 CPU’s which then do a ROM test for their own ROM’s and stick the result of the ROM test into the shared main RAM.
While this is happening, CPU1 is in a loop constantly checking the RAM area for a value. When the value isnt 0x0 then it either proceeds to boot the game or flags a “ROM #” error depending on which ROM has failed.
Now around 90% of the time the “ROM OK” error didnt show before resetting and I never did see a “ROM #” error.

I pulled all the ROM’s and tested them against MAME but found this to be an undumped version. Overlaying the ROM’s on an existing set I could verify that this version booted fine so they were likely good.
All the CPU’s are socketed and all the pins were also going black so removed them to look for damage and cleaned them up in the process. On replacing the CPU’s the game booted but was very flakey. Messing with the CPU sockets I could get different behaviors so was fairly convinced at this point that the sockets were bad. In hindsight I should have suspected these earlier as they are not the best

I opted to replaced all 3 even though CPU1 socket seemed to be fine.

Next boot up went great and nothing I did would make it crash again

Double Dragon repair log #11

PCB Repair Logs, Repair Logs 1 Response »

Oct 302021

I’ve worked on a few of these boards before so I knew straight away that I should be able to access the components side on both PCB’s when it is all screwed together but on this board set the video PCB was showing solder side out.
This doesn’t necessarily cause damage if powered up but its obviously not going to work either.
I switched it back around and when I did I noticed that the crystal on the video PCB was completely missing.

I had a spare 12 MHz crystal so I fitted that. Without that crystal fitted you would get a blank screen.
I tested the game and it started it self test routine but failed on the 63701 with an “Error” and had some graphical issue too.

I had to hope the 63701 wasn’t actually at fault because that is an MCU with an internal ROM which I cannot replace easily.
The way the self test works is the MCU does its own self test and when it is complete it puts a value of 0x84 into the shared RAM at location IC22. The main CPU them reads this value when it is ready to and compares it to 0x84. If this doesn’t match then we get an error.
Looking at the schematics we see where the RAM is

I desoldered the RAM at IC22 and it failed an out of circuit test.

Replacing it cleared this error and allowed the game to boot.

Straight away I could see that sometimes there was a problem with the characters.

When they glitched so did the game title graphic too. It looked like they were being drawn twice overlapping each other. This led me to look for a counter issue, usually a 74LS161.

Following the VPOS signal on the schematics I came to some 74LS161’s. Found this one that has some excess solder on the legs. Touching this while the game was running cleared the issue so I just replaced it and the issue was fixed.

Now on to the remaining sprite issue.

Found 3 dead ROM’s on the video board which sorted all the graphics out when programmed up with the correct data.

Older Entries Newer Entries