Repair Logs – Page 3 – JAMMArcade.net

Spectral Vs. Generation (SVG) PGM Cart Repair

Sep 122024

In for repair was a Spectral Vs. Generation (SVG) cartridge for the Poly Game Master platform by IGS. It was booting up to a garbled screen.

SVG was a late release for the PGM platform, and it incorporates strong anti-piracy measures that IGS didn’t have in their earlier games. The cart has an ARM CPU with an embedded ROM that both decrypts encrypted assets and processes some of the logic for the game. The game has yet to be patched to operate without the ARM CPU, and the embedded ARM ROM hasn’t been fully dumped yet with this game. If the ARM CPU fails, that’s pretty much a project killer.

The owner of this cart also sent along a fully functional second SVG cart, and through cross-testing, I confirmed that the CHAR board of the faulty cart is fine while the CPU board is the culprit. I dumped the three EPROMs from the CPU board and while the dumps matched MAME, the good cart wouldn’t boot with the “V200 U30” EPROM installed from the faulty cart, so I programmed and installed a replacement 27C4096 EPROM for that part.

This still didn’t get the faulty cart booting so I moved on to reflowing the ARM CPU and confirming that the ARM was receiving a clock signal from the onboard crystal at U35. The cart still froze at bootup so I reached out for help on the Arcade Projects forums. On there, Fluffy helpfully suggested installing the three GAL chips from the functioning board into the faulty board – a dumb oversight on my part. 😀

Installing the GALs from the working cart got the faulty cart booting to an EXTERNAL RAM TEST ERROR screen.

Replacing the SRAM chip located at U38 resolved this error and now a new error appeared – SHARE RAM 1 TETS (sic) ERROR.

I replaced both the SRAM chips located at U37 and U38. This resolved that error and now the cart was booting up successfully!

I still needed replacement GALs though, and the GALs for this game hadn’t yet been dumped. I reached out to Apocalypse and he graciously offered to dump the GALs for me. I shipped him the carts, he dumped the GALs and the PLD files are now available at the PLD Archive.

Now that the original good GALs were installed back in the working cart, the final step was to program fresh GALs with Apocalypse’s PLD files and swap them into the faulty cart. The faulty cart booted up fine and passed a four hour burn in test. Repair complete!

Thunder & Lightning repair log

Aug 152024

Got a Thunder & Lightning, a nice ball and paddle game from Seta on the bench today.

At first glance the board looked fine, but there was some worrying rusted pins on one LS close to the 68000 … not sure why, but other chips around weren’t affected.

I replaced the chip and patched the traces with some kynar wire.

When powered up, a working game displays a moving patchwork of tiles for a few seconds before displaying the title screen. In this board case, the tiles patchwork was displayed, but it kept rebooting just before displaying the title screen.

On this board, dipswitch 1 of the first bank puts the game in test mode. Doing so displays a color grid, and after pressing a button you get to the input test. The board worked flawlessly in test mode, meaning the main CPU worked enough to run it. But when pressing the reset button on the board, the following message started to show: “Address Error 2020E6”, before rebooting again …

Not knowing where this address pointed to, I looked into Mame to find the memory map of the game. And I found something very interesting : a PALCE is used as a protection device, using some address lines as inputs and computing a value that’s grabbed later by the CPU … if the value isn’t the one expected, a soft reset is done. That looks reaaally familiar !

Here’s the offending chip (TL-9) :

It was removed …

.. and replaced by a GALV16V8, using the file from the PLD archive. I added a support just in case.

And voilà !

Played a few levels to be sure nothing’s amiss, all is good !

Namco Rompers repair log

PCB Repair Logs, Repair Logs Comments Off

Aug 032024

I’ve had this board in my collection for some years and I’ve made some repair work on before (replacing the cus120 on the CPU board, might put up a repair log on that as well).
I was going through my PCB collection and found that the game would not boot, there was only a black screen and not even the usual klonk sound as Namco System 1 games usually do.

Started with the basics, probed the Program ROMs with my logic probe and I did see some activity on the address and data buses.

Decided to dump the Program ROMs and verify them and they turned out to be ok.

So I started to probe the address and data buses again and found an address line (A2) that was stuck low.

Traced this line back to a 74LS244 at E10

74LS244 is a buffer and according to the Pac-Mania schematics, pin 14 is the output which has its input at pin 6 and there was activity there

This made me quite certain that the 74LS244 at E10 was bad.
But just to be certain, I removed all Program ROMs and the Custom key chip, so none of them would interfer.

And the fault was still there.
I quickly desoldered the 74LS244 and tested it with my tester as bad

I soldered a socket in its place and replaced the IC with a known good one and now the game booted up again

Silkworm repair log #2 and schematics

PCB Repair Logs, Repair Logs Comments Off

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 :