Hello everyone, today I have another board on my desk which I purchased as “working” but while my board boots up, it has issues.

Irem produced several models of motherboards, and this motherboard is M92. It is a 2-stack board, consisting of a motherboard and a ROM board. M92 does not have any schematics.
[Editor Note: wickerwacka produced some partial schematics of the M92 when implementing his FPGA core. Also take a look at our Irem M92 entry in PCB Encyclopedia]

First let’s take a look at our board.
Main board:

ROM Board

When I power up the board, it passes the RAM and ROM test successfully.

However, in the warning text, you will see a line at the bottom of the screen. That’s one of our problems.

Here you can see another problem, there is a vertical line on the left and right of the screen.

These are the most obvious problems. It is difficult to show the real problem with a photo. Take a look at this video of the problem:

As you can see, as our character moves forward and the background changes, there are flashes and/or color changes on the screen. This is our biggest problem.

Let’s do a physical inspection. The ROM board seems clean and problem-free enough. I move on to the motherboard.

The mainboard has been worked on before – one of the chips has been changed or reflowed.

When I look closer, I see a solder bridge. This bridge belongs to 74LS74AN part.

I separate the bridge with a tiny touch of a soldering iron.

But removing this bridge causes no change with the game.

Next, I keep the game on for about half an hour, then I check the chips one by one to see if any of them are overheating. It seems that three of the ICs on the ROM board, which I have highlighted in blue, are overheating.

One by one, I remove the parts and test them out of circuit with my EPROM programmer. One of the SN74S373N parts fails the test.

I install socket and replace all three parts.

IC18

IC30 and IC31

Unfortunately, there’s no change in the game – but there’s no more overheating chips now either.

The next task is to check the ROMs by dumping them and comparing the dumps with MAME. I remove everything from the ROM board (both for cleaning and to check the ROMs)

I set the chips down on a notebook in the same order so I don’t forget their places.

When dumping the ROMs, if it is not written on the chip you are reading what type of part it is, we either check MAME or we look for solutions in forums.
[Editor Note: the part numbers for ROMs with Irem M92 boards are in our PCB Encyclopedia]

There were 3 types of ROMs on this board. Let me specify how to read them:

532 –> 27C020

534 –> 27C040

538 –> 27C080

After dumping the ROMs and comparing them, it seems that most of them are okay.

L0

Then I had problems with 2 ROMs – both audio ROMs.

SLO-A and SHO-A

The ROMs are responsible for the playback of all sounds. These ROM comparison sites do not list results if the ROM dump I provide is not 100% identical.

The sound works on this board, so obviously our problems have nothing to do with the audio ROM. I won’t dwell on it, but I’d still like to check how close the files are. Here’s what the “romcmp” command in MAME says about my dumps compared with the correct MAME ROMs:

Next, I am inspecting these two large GA (Gate Array) chips. These are custom chips – when they fail, it is a nightmare to source replacements. Sometimes reproduction parts are created by the community but otherwise you have to source parts from a donor.

GA21 and GA22

I check the connections of the legs with the boards by gently poking them with an X-Acto knife. I also perform a continuity check with a multimeter to see if there are any bridged paths.

I don’t detect any non-contact legs, but I detect continuity in legs 35 and 36 in GA21.

Up close, I don’t see a soldering bridge.

Later on, I asked a friend who has the same board to check on his board, and he gets the same measurement, so there is no problem with these pins. On my board, I reflowed the solder on them just in case.

I went ahead and reflowed the other GAs too.

When testing the game again afterwards … the result is the same. I still haven’t found the culprit…

I’m growing weary with this board, but I wanted to get one more thing out of the way. There are 14 brown ELNA capacitors on the motherboard. These capacitors are very prone to leaking so I thought I would replace them.

Here is the list:

Irem ‘M92-A-B’ Motherboard Electrolyte Capacitor List
C201 1uF 50V
C202 470 uF 25V
C203 220uF 10V
C204 22uF 25V
C209 100uF 25V
C210 1uF 50V
C213 47uF 16V
C215 1uF 50V
C216 1uF 50V
C217 1uF 50V
C218 1uF 50V
C219 1uF 50V
C236 100uF 25V

Here’s all of the old capacitors removed:

And here’s the board after installing the replacement caps.

If you’re using a hot air gun, be VERY, VERY careful! This area highlighted in blue swelled on my board-fortunately I didn’t damage anything. I dodged a bullet.

After recapping, the previously almost inaudible game sound now sounds great!

Now back to the main problem with the horizontal lines at the bottom of the screen, the vertical lines on the right and left of the screen, and the color distortions when the background scrolls.

I take out my Logic Probe and start probing. There are two palette RAM chips located at IC15 and IC16 on the motherboard. These parts are Fuji brand – the most susceptible brand prone to fault. The part is MB81C78A, which is 8K x 8 = 64KB of RAM.

I documented the logic activity of the pins on the two chips by making a table:

According to the data sheet for these memory parts, Pin 19 on these parts is the “I/O 8” data line. When probing this pin, I see a difference between IC15 and IC16.

IC 15 –> Pin 19 –> shows PULSE activity between HI and LOW. So there is a data flow.

IC 16 –> Pin 19 –> LOW only and no PULSE. So no data is flowing.

Two things could be happening here:

1) This RAM chip is bad
2) Or one or more ICs connected to this pin are bad.

I trace Pin 16 of IC19 with a multimeter and see that it goes to Pin 31 of IC2.

IC2 is a SN74LS374N part. According to it’s data sheet, Pin 2 –> 1Q (Output)

I also find that IC31 Pin 2 also connects to Pin 2 of IC23.

IC23 is a SN74LS245N part. According to its data sheet, Pin 2 –> A1 (I/O)

I remove these parts with the suspicion that they are causing at least part of the problems.

Testing the parts out of circuit in my EPROM programmer, the SN74LS374N chip passes the test.

The SN74LS245N part also passes the test.

Nevertheless, I install sockets and change them out anyway.

Testing the game afterwards, the result is the same.

Next, I decide to replace the Fujitsu Palette RAM parts as well. I have the following equivalent RAM parts available:

I remove the old RAM and install sockets.

Now, when testing the old RAM out of circuit … they test as faulty.

I install a new RAM part that passes the out of circuit test in the socket to replace this faulty part, while leaving the other old Fujitsu part installed in the other Palette RAM socket.

Now when testing the board … everything is worse. Now, in addition to the old problems, there is now a problem with the color Red. As you can see in this video, all of the colors appear in the narrow columns on the left and right, but there is no Red on the main screen in the middle.

I decide to put the board into TEST mode to test the red color. For this, press 1P A+B on the RAM ROM TEST screen. Then, on the menu, select Screen test.

As you can see in the Screen Test, there is no trace of Red.

In case I missed something, I check around further with the Logic Probe, and I find another IC on the same line.

Pin 18 of IC10 is connected to the same pin as the others – I missed it before.

There are 3 resistor packs in this area. I measure the resistance of their feet with my multimeter – they should be equal to each other.

The results are good.

IC10 is a SN74ALS273N. According to the data sheet for this part, Pin 18 –> D7 (Input)

Here is my drawing of the connections between these chips:

I’m thinking of replacing IC10, and then something strange catches my eye. On the chip it says SN74ALS273N but on the motherboard, HC374 is printed as the part for this chip. At first, I think that the wrong chip was installed in this board, but then I look at other photos of this board on the PLD Archive site and they are the same.

I do some research on the subject and the information I can get is that 74HC374 was used here because 74LS273 was too slow. Later, when faster 74ALS273 parts came out, they switched to them since they were cheaper.

I proceed with replacing this IC. Since I don’t have another 74ALS273 on hand, I will replace it with a 74HC374.

After removing the old part, I test it out of circuit in my EPROM programmer and I see that its problematic.

When the game now, it seems that there is a big improvement. The colors that were flickering in the background as the character walks have been fixed.

But we still don’t have red…there is only red on the far right of the screen.

You can see it better in this video:

Let’s keep on trying. When checking the data sheets further, it seems that the pinout of this new 74HC374 IC is slightly different than the 74ALS273 it replaced.

SN74HC374N –> Pin 18 –> 8D (Input)

It turns out that on the 74ALS273 datasheet, the channels are numbered from 0 to 7. On the 74HC374 datasheet, the channels are numbered 1 through 8. However, the functionality between the two is the same.

I decide to remove the other 74ALS273 IC above the one I just replaced – IC9 – and test it.

No problems in the test, but I proceed to replace it with a SN74HC374N to match IC10.

Now when powering up the board … everything works correctly. The board is saved!!!

Best Regards

Oguz

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.

The following “all rights reserved” is even corrupted.

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:

Best Regards

Oguz

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!