JAMMArcade.net

Sega System 18 (Moonwalker) Repair

Nov 062024

Hello everyone, this time I have Moonwalker – perhaps my favorite game – on my desk.

I bought this board “as working” but when powering up, I found out that the board doesn’t boot – it shows no activity at all..

And an IC fell out of the shipping box. But the funny thing is that there is no missing IC on the board.

I bought this board as “working”, but since I bought several boards together and did a package consolidation before shipping, the seller packed these boards naked back-to-back and this is the view…

When we look closely, we can see the damaged traces.

I took out my multimeter, and with it set for continuity testing, I measure the two ends of each trace where a deep scratch passes over it. Fortunately, not every trace is damaged.

There are 2 broken traces at the first scratch location.

In the second scratched place, we have 3 damaged traces. Moreover, it is a bit more of a winding road.

We’re preparing the operating room now.

In many articles, it is written that “kynar wire” should be used for trace repairs. I couldn’t get it from abroad under this name. This is the wire I found – it is 0.10mm.

If you have any feedback such as this is not suitable, too thin, etc., feel free to say so.

What else do you need? Solder:

What else do you need? Flux:

What else do you need? UV solder mask ink. Some people uses nail polish here, but I prefer to use the professional solution for the problem.

And last but not least, what else do you need? A good eye or a lens or a microscope.

And what’s the last thing you need? Patience like a saint.

First of all, we dig up scratch off the masking a little on the left and right where the trace is broken (enough to expose the copper).

Then add a little flux on top:

Then we solder in a small length of jumper wire to bridge the gap.

How is this procedure done by the masters?

First you apply heat with solder and flux to the bridging wire.
Then you apply flux and solder to each end of the broken trace.
Then you solder one end of the bridging wire to the left side of the broken trace.
Then you solder the other end of the bridging wire to the right side of the broken trace, but while doing this, place something that conducts heat (like a cold solder iron tip) in between so that the heat on the right side does not reach the left side and melt the solder there.

Here’s how it looks after soldering:

I apply solder mask ink on top of it to prevent future damages.

Let’s move on to the second damaged area.

This place made me sweat a lot – especially the curved path in the middle – but I still managed it in the 10-15th attempt without giving up. I am not patient but I am stubborn.

I put an cotton swab next to it so you can see the size of the area I’m working in.

After the repair, we apply solder mask ink to it too.

Time to power up and see how things look. Recall that this was sold to me as a working board, but the photos taken before it shipped to me didn’t have this damage.

I power it up and there’s still no activity – just a black screen.

Then I remember something – an IC fell out of the package…

When I asked the seller about this IC, the seller said that it must have been mixed up while packing the board and that it had absolutely nothing to do with this game…

I immediately remove the ROM daughterboard and look underneath. And here I see that two of the ICs have been piggybacked. I didn’t photograph this (sorry), but here’s a generic example:

Piggybacking can be useful while diagnosing a board but is not a recommended long-term solution. It will damage other components because the piggybacked chip doubles the power draw for that circuit.

The type of IC that fell out of the bag 74LS244N. Next to the two ICs that are already piggybacked, there is another IC that is not piggybacked. Guess what it is? A 74LS244N. I’ll piggyback this IC onto it see what will happen…

Prepare the POPCORNs.

IT’S “ANNIE ARE YOU OKAY” TIME!

You can watch me demonstrate the repaired board at: https://youtube.com/watch?v=n0PYuHxzpNk%3Ffeature%3Doembed

Best Regards

Oguz

Raiden II Repair

Nov 042024

Today, I have a Raiden 2 PCB purchased “with Graphics Glitches”:

This PCB uses the -5v power rail for audio. Make sure that your PSU is also providing -5V.

I’ll power up the PCB and look for the graphical glitches mentioned by the seller.

As you can see, there are a lot of nonsense numbers going on here.

Even the text is problematic.

By the way, there was also a sync problem when I first tried the PCB. Seibu PCBs work at 55.xx something Hz and not every monitor can tolerate this frequency. Then I realized that my 9” PVM has a V-HOLD pot on the back. When I played with it a little bit, the sync problem got fixed. This v-hold can even be on regular TV’s too but sometimes it’s inside the case.

The first thing I usually do when I get a board is to clean the JAMMA connector.

For this I use the metal polisher in the photo.

Although now the JAMMA connector is clean, of course the problem is not solved.

So let’s check the ROMs as a first step.

The contact points get dirty over time with rust, dirt and oxidation. I clean the legs of the ROMs with an X-acto Knife and rinse them with IPA.

Then I move on to reading the ROMs and comparing them with the ROMs from MAME (Hamster’s ROMIdent site is very helpful).

With one of the ROMs, I got a warning that a single pin on the chip cannot be read. After cleaning that pin, it reads correctly.

All of the ROM dumps check out – all is as it should be.

One issue you may encounter when working with ROMs – sometimes the type of ROM is not written on the chip (this is common with mask ROMs).

When that happens, we find the MAME driver file of the game board – this file is like a mechanic’s manual. For many games, the MAME driver lists which type of ROM is used, which type of RAM is used, the type of processors, etc and their location on the board.

Schematics (the topology of the electronic circuits) are also very helpful when available, but unfortunately this board has no schematics.

The MAME Driver for Raiden 2 is: https://github.com/pongnguy/mame0148s/blob/master/src/mame/drivers/raiden2.c

When there are no problems with the ROMs, the next procedure is a bit delicate.

One of the most common problems with these boards is lifted legs on the custom chips.

With my X-Acto knife, I tested each leg one by one to see if any are disconnected.

All of the legs are solid.

After eliminating the ROMs and custom chip connections, it’s time to look at the RAM.

After a little bit of tinkering with my logic probe, I couldn’t get pulses on some legs of the two 6116 RAM chips highlighted in red. Since there was no further information (like schematics) with this board, I decided to “take a shot in the dark” and replace those 2 RAM chips.

I know these RAM chips are responsible for palette data – maybe replacing them will solve some problems.

Here, I’m installing sockets and replacement parts for these two friends:

We have a little accident every now and then. I must have overheated the board a bit during disassembly with a hot air gun because a small part of one of the traces lifted up. I thought it was the residue of the cotton swab I used after soldering (to clean the flux) and when I pulled the swab away, the trace itself came up.

Anyway, I immediately patched it and continued on my way.

One of the 6116 RAM chips I removed failed testing:

I immediately checked the pinout:

I see that I have the same MB8416 chips that I bought previously for an Asterix repair.

I changed the RAM and tested the game, but nothing changed.

Then I tested the old RAM again:

Turns out the old RAM is good after all.

Next is the RAM chips I marked in red.

When I search for what these 2 RAM chips are responsible for, I see that they are responsible for “Background Tiles” and “Intro Animation”.

I think we found the culprit.

I immediately removed both of them.

But if you look, the holes are still partially full of solder. I use both a hot air gun and a desoldering pump combo for clear holes. When I light up the board from the back, the holes look sparkling clean.

I immediately installed sockets and put the old RAM back in for testing (I always try the board as it was before installing sockets, just in case there are any errors in the socket itself or the part removing procedure).

The board operates the same as it did before socketing the parts, so let’s move on.

Now I need fresh parts for this RAM but I don’t have it.

It is 8K x 8 static RAM and has 28 legs.

I take a look at a 28-leg RAM on one of the bootleg boards in my spare parts box and see that the pinouts are the same.

I replace the ram on the left (U0611) with the one I removed from the faulty bootleg board and power it up (yes of course I tested the RAM first on my TL866 EPROM reader and verified it was good).

RESULT:

No more graphics glitches! What do you want to do when you see this beautiful screen? Insert the coin and play, right! But I wish practice and theory were always parallel.

I pushed the Coin button but there’s no response – neither the coin is recognized, nor is there the coin drop sound.

There is something about Seibu Kaihatsu Raiden boards. Let’s make a note here…

Seibu boards rely on the sound section to make the coin up sounds before it will register the coin up. So we should fix the sound circuitry before troubleshooting the inputs. So we know that we have to look for the problem in the audio section.

But I had already done something like this while investigating the previous graphics problem.

I previously removed and socketed the four RAM chips in the section highlighted in red.

Then, when I researched in detail, I realized that only 3 of 4 of RAM chips that I highlighted in red were related to graphics – they were Sprite RAM.

But the RAM chip at the top of the same row, just below the Sound ROM number 5, is related to sound.

Since I’m troubleshooting the audio system, and this is an audio component already installed with a socket, it makes sense to test this part first. So I test the RAM chip:

The part tests bad, but for me, it’s a good result – it’s always nice to find a non-working component while repairing a board.

I have a CXK5814P part that I can use instead of the CXK5816P. The pinouts are the same:

Testing the new RAM:

The part passes the test, so I’m installing it on the board.

And now when I insert coins, I hear the sound of “ding”!

Now the board works 100% – a happy ending. You can watch me test the board here:

https://youtube.com/watch?v=SNy9fcdaXpo%3Ffeature%3Doembed

Best Regards

Oguz

DoDonPachi Dai-Ou-Jou PCB Repair

PCB Repair Logs, Repair Logs Comments Off

Sep 162024

In for repair is a DoDonPachi Dai-Ou-Jou (DDP DOJ) arcade board by Cave. It boots up fine but the backgrounds and most of the text are missing.

DDP DOJ runs on the IGS Poly Game Master (PGM) hardware. Although DDP DOJ was never officially released as a PGM cartridge, the game was easily dumped from the original stand-alone boards and can then be loaded onto a PGM cartridge.

According to the MAME driver for the PGM, two ROMs are involved in drawing the backgrounds – a BIOS ROM and an asset ROM.

In MAME, I overwrote the “pgm_t01s.rom” BIOS ROM file with all “FF” but the game still booted up and played fine. Overwriting the “cave_t04401w064.u19” file with all “FF” replicated the real board’s behavior in MAME.

This implied that the mask ROM located at U19 was only reading out “FF”. Probing the address and data lines of that mask ROM on the running board confirmed it – the Address lines would signal properly but the Data lines pretty much always read High.

I desoldered both the U18 BIOS ROM and U19 asset ROM chip and attempted to dump them both as a 29F1610 flash chip since that part has the same pinout. The 29F1610 is a 16 Mbit part that matches the 16 Mbit BIOS but is only one-quarter of the 64 Mbit total stored in the background asset ROM. But even with only one-quarter of the background ROM dumped I’d be able to see if data is reading out of the ROM properly.

The BIOS ROM successfully reads out data but the background asset ROM only reads out FF – looks like the background ROM is toast.

Now for a dilemma – what to do about replacing a dead DDP DOJ background asset mask ROM? The original part is a MX23C3210 mask ROM. There is not a programmable off-the-shelf part with 64 Mbit capacity and the same 5V voltage that the PGM hardware uses that also matches the pinout and footprint of the original mask ROM.

I did prototype a solution that I will describe at the end of this post, but for now I’ll skip to the end of the repair and say that the owner of this board sourced a dead donor PCB of the same game. I was able to successfully transplant the BIOS and art asset mask ROMs from the donor to this PCB and it worked correctly afterwards – a successful repair.

Stepping back to earlier though, while the owner searched for a parts donor, I reached out to colleagues on both the Arcade Projects forums and on Discord for advice for replacing the dead 64 Mbit asset mask ROM. One consideration was to use four 29F1610 16 Mbit flash chips with a 74LS08 TTL chip to drive the Chip Enable lines. A second consideration was to use two 27C322 32Mbit EPROMs – that’s what the PGM cartridge conversions of DDP DOJ use. The drawback to both of these approaches is that the substitute chips would take up a lot more physical space than the original mask ROM so attaching them to the board would be challenging.

A third consideration that I proceeded to prototype with was to adapt an Intel DA28F640 flash chip. The DA28F640 is 64 MBit capacity, 5.0V compatible and programmable but it has a completely different pinout and footprint. I’d never created my own circuit board before, and this seemed like a great opportunity to learn KiCad. Over a few evenings, I referenced data sheets, took measurements, and produced an adapter board.

By the time the production adapter boards arrived, the game had already been fixed with the mask ROM from a donor PCB so my adapter is untested for now. Hopefully I’ll get a chance to try it with a different repair.

Here are the data sheets of the parts involved in this repair, along with the KiCad project files for the flash adapter PCB. If you use this adapter for a repair, please let me know if it works for you!

MX23C3210 mask ROM datasheet
Intel 28F640 pin assignments datasheet
Intel physical footprint datasheet
Flash Footprint Adapter KiCad files (Currently Untested)

Spectral Vs. Generation (SVG) PGM Cart Repair

PCB Repair Logs, Repair Logs Comments Off

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

PCB Repair Logs, Repair Logs Comments Off

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