Aug 252016

The hardware of this matches Part II but it has the multigame add-on fitted.
Not worked on a Space Invaders board before and needed to make up a loom so I could properly test.
The owner says the ship is constantly pulling to the left and there is a sound effect playing over and over all the time.

On powering up I did indeed find these problems. Look at the video, the in game play shows me moving the ship to the right but when I release the controls it moves back far left on its own.
You can also hear the constant tone repeating over and over.

First of all I went looking for the control issue.
The schematics are available however they aren’t too great in places. Fortunately they were good enough to save me a lot of time.
Here you can see where the player 1 left comes in. It goes through an inverting buffer and into a 74153 chip at location 5. The output on pin 9 is the one we are concerned with

From my logic probe I could see that this output is stuck when it should be active. Testing this out of circuit confirmed it.
This fixed the control issue .

Now on to the sound fault.
Space Invaders hardware made this quite easy as each sound effect has its own volume control. By turning the pots down I could pinpoint which sound was stuck on and work back from there.
VR7 was the pot associated with this sound and according to the manual this is the sound of the “UFO HIT”.
Looking at the schematics again and working backwards we can see it goes back to buffer chip 7417 at location 18 and before that it comes from a 74174 at location 14.

The outputs from the 74174 looked good but all the outputs from the 7417 buffer were stuck HIGH.
I removed the chip and once again it failed when testing out of circuit but now I had problem. I dont have any 7417 chips and I no longer have scrap PCB’s lying around.
The sadness was short lived as a quick google search revealed a 74LS07 chip can be used as a replacement and the difference between the two is the 7407 is rated for 30v where the 7417 is rated for 15v.
Anyway, replacing this with a 74LS07 worked and the sounds are all OK.

The video shows the controls now working and the lack of annoying sound. I did actually test the UFO HIT sound in game and it was working fine.

Job Done.

 Posted by at 8:23 pm
Aug 212016

Received this original Nichibutsu Terra Cresta PCB for a repair:


Board had severe graphical issues, backgounds were all messed up and moving, sprites absent:

The first thing I noticed after my visual inspection was that both boards were fully populated with Fujitsu TTLs therefore I was pretty sure all the faults were due them.To troubleshoot them I used my HP10529A logic comparator for  TTLs up 16 pin and a logic probe for 20 pin ones.The backgrounds data are stored in two 27256 EPROMs @15F and 17F on CPU board so I went to probe around and I found a 74LS273 @18E with stuck outputs:


This was confirmed also by a logic analyzing of the device:


Once desoldered the device failed when tested out-of-circuit:


I got  improvements, now backgorunds were almost formed but still scrambled and sprites visible although not perfect:

With my HP10529A I found a 74LS157 with floating outputs @17D on CPU board:


Chip failed the out-of-circuit test:


Backgrounds were now 100% restored but sprites missing lines with some garbage on screen :

At this point I focused on video board since all objects circuitry lies there :


Probing around the sprites EPROMs, I found a 74LS367 @1F with bad outputs:


and a 7LS257 @3C (involved in sprites RAM data bus) with stuck outputs, also this failed its test:


Now sprites were perfect but doing some comparison with MAME I realized that characters were totally missing!

Found a 74LS257 @14G with missing input pin 15 (/OE  ) in the area of the character ROM:


I traced it back to an output of a 74LS367@20B on CPU board:


Logic analyzing confirmed its outputs were floating and chip failed once tested out-of-circuit:


Characters were back:


I was archiving this repair when, during my test,  I experienced some sound issues, sometimes audio was distorted:

This board uses an YM3526 OPL IC paired with an YM3014 DAC although chips are marked with Nichibutsu part name (‘TC 148509’ and ‘TC 1409’) :


Probing pin 2 (the analog output connected to the OP-AMP) of the ‘TC 1409’ revealed a weak signal:


I replaced it with a YM3014 :


This gave good sound back.Board 100% fixed and evil Fujitsu once again defeated.



 Posted by at 11:26 pm
Aug 132016

Lately, I got a total of 4 faulty Night Slashers PCBs from friends to repair. Due to the fact that these boards are mainly populated by SMCs and customs ICs, a custom CPU and no available schematics, making them less handy to diagnose than some older generation boards. I decided to take advantage of having four boards on the bench and recently started working on them.

Among the 4 boards, I had three different board revisions (DE-0395-1, DE-0396-0 and DE-0397-0) only with very minor differences between each.


  • FIRST FAULTY BOARD (DE-0397-0 revision)


Problem #1: The game was running but with major gfx issues. Most of the backgrounds were just plain while sprites seemed fine.


Piggybacking the 64kb RAMs @ 5E, 6E and 9E successfully restored a lot of the backgrounds but there was still some garbled data, even after replacing them.


Problem #2: The fourth RAM @ 10E was tested good, as well as the two MASK ROMs @ 8A and 9A where the background data is stored. Touching the contacts around the gfx area with slightly humected fingers revealed a few ones where data seemed missing/corrupted as we could see the garbled pixels slightly changing. These sensible contacts led to a 74F373 @ 12C, a 74LS373 @ 11C and a Data East ASIC number 74. The signals looked healthy on the scope so after desoldering the two suspicious TTLs chips, it was finally the Motorola 74F373 @ 12C that was faulty. Replacing the chip finally led to a perfectly fine looking game.


Problem #3: FM sounds (synths, generated by an YM2151) were very weak compared to sampled sounds (voices, percussions and other samples, generated by two M6295)
Comparing the audio part with an other board revealed a factory mistake in the row of resistors that connect every sound channel to the amp circuit… They put a 15 kOhm at R17 instead of a 47 kOhm. For a good balanced sound, here are the correct values for them:
-R16, R20 & R21 : 8 kOhm (seen 7,4 kOhm on a DE-0395-1 board revision, difference isn’t perceptible)
-R17 : 47 kOhm (seen 50 kOhm on a DE-0395-1 board revision, difference isn’t perceptible)
-R18 & R19 : 67 kOhm
-R22 & R23 : 10 kOhm



  • SECOND FAULTY BOARD (DE-0397-0 revision)


-Game was booting but with some letters staggered.
-Game was crashing along with a vsync issue anytime an ingame screen appeared.

Never had this kind of fault before. The staggered letters could be an issue in the gfx part but the instant crash after an ingame screen was clearly a CPU related issue. Not really easy to diagnose (of course I checked the CPU ROMs and PALs but they were good) so I started focusing on the RAMs, a row of 4 SMC SHARP LH52250. Touching the pins on some of their address lines with humected fingers sometimes changed a few of the staggered letters so I replaced the whole lot of 4 and luckily one of them was the faulty one. Replacing it fixed the letters and crash issues.

ps. I cannot show pictures of the staggered letters as I forgot to take pictures of the screen before replacing the faulty RAMs. To give an example, the name of the character CHRISTOPHER in the player select screen appeared as CHRISTOGHER.


  • THIRD FAULTY BOARD (DE-0395-1 revision)


Problem #1: Board was booting on a garbled screen, randomly with a white or pink background.


This type of issue is due to a problem in the main CPU section. It is a Data East 156 ARM based encrypted CPU and there is not much information online nor pinouts available so diagnosing it is a bit tricky. First, as it worked with the previous board, I replaced the 4 CPU RAMs, but with no change. Also, clock and reset signals around the CPU looked fine with the scope. Then, while probing the pins on the CPU, the game suddenly launched with minor gfx and sound issues but also with half of the controls not responding. I retraced the non working buttons from the JAMMA connector to the I/O custom chip which is a Data East 104. Everything looked fine on the scope. When I turned the power off and on again, I got the same garbled screen but after a few tries touching the CPU pins with the scope, I could sometimes get the game running again (with the same issues) or sometimes a black screen with a message : “CONFIGURATION MODE ERROR”.

All these missing controls caught my attention so I looked closer at this Data East 104 custom I/O chip.


It basically makes the link between every button and the CPU. In fact, it is connected to the data bus and is sending information for all the controls to the CPU. If it is faulty then it could possibly send corrupted data to the CPU which may crash it. For example, that could happen in a lot of Taito boards from the late 80’s, early 90’s: if you plug the JAMMA harness upside/down you plug the 12V signal which normally goes to the audio amp to the controls and it directly damages the I/O custom chip which then send bad data to the CPU, leading to a non booting game.

I reflowed this 104 chip but with no changes so I decided to desolder it. I had a spare Fighters History board running on a DE-0395-1 revision board (same board than this revision of Night Slashers) and at the same location there was a very similar chip with its part number scratched off. I naturally guessed it was the same chip so I put it in place of the 104 on the Night Slashers board. No luck… Even worse than before: I could not have the game starting at all, only the message “CONFIGURATION MODE ERROR” at best.

So I contacted Bryan McPhail, author of the MAME DECO 32 driver and he was pretty sure this version of Fighters History used a previous revision of the I/O chip numbered 75, not 104. That would explain not having the game booting even once with it plugged in. So I desoldered it and put in place a 104 chip taken from one of the working Night Slashers boards as I needed to clarify the situation… And that time the game launched directly ! I also got all the controls working perfectly.

Good find, but now I had only one 104 working chip for two Night Slashers boards. Bryan told me every 104 chip could work as a replacement. This chip is present on these games: Caveman Ninja, Wizard Fire, Rohga, Boogie Wings, Diet Go Go, Double Wings, Schmeiser Robo, Pocket Gal DX and Dream Ball. The two last ones being the only ones I could imagine being donor boards…
On the way to get a Pocket Gal DX, will update the post after replacing the chip.

Problem #2: Had a few gfx issues (vertical lines on a few sprites).


I quickly found something by touching pins on the gfx ROMs. Vertical lines seemed partially flickering and disappearing when touching some of the address lines on the MASK ROM labeled MBH-09. These are 512kb ROMs with MASK pinout so I burned the matching content on a 27C400 EPROM and tried piggybacking it. It resolved the problem so I put a socket and plugged it as replacement.

Problem #3: Had some sounds issues. Some voices/samples were missing and replaced by junk noise. One of the two M6295 voice generating chips @ 12M had previously been badly repaired and a pin was very near to fracture. Tracks #14 & #18 on the board were broken by the previous repairer and replaced by two wires going from the M6295 to the MASK ROM @ 14L. I removed the serviced chip and these two wires. In order to replace the missing tracks, I inserted tiny pieces of wire in the holes below the chip, bended them and soldered them in.

You can see here how they were broken on track #14 and how I fixed them on track #18:


And here is how it looks after a new chip in place:


Part of the voices were back but some junk sounds were still audible. While checking the other M6295 chip @ 13N, I found a signal that seemed strangely inactive on an address line which goes to the MASK ROM @ 15L where these sounds are stored. I piggybacked the ROM with a burnt EPROM of the same content but nothing changed. Suspected the OKI M6295 so I replaced it and that fixed the issue. Everything is fine now.


  • FOURTH FAULTY BOARD (DE-0396-0 revision)


Problem: Had some sounds issues. Some voices could be heard repeatedly at unintended moments. For example Christopher was saying “I take that !” repeatedly and randomly.
Found an I/O line on the M6295 @ 13N (pin #37) with no activity. This goes to the 104 chip but here there was no continuity with were it is supposed to go. There was a bit of corrosion around the M6295 and a closer inspection of the area revealed a broken hole connected to the track of pin #37:


Only this side of the hole was damaged so I inserted a tiny piece of wire on the other side, bended it here and soldered both sides:


That worked. No unwanted voices constantly repeating anymore.

Aug 112016

For the uninitiated the Irem M92 is an arcade platform introduced in 1991 by Irem.Technically speaking the system is  made from a top and bottom board, the top (main) board is common across the games, but the bottom (game) board can vary game to game.Each game has an encrypted sound cpu.Here are hardware specs:


  • CPU : V33 @ 9 MHz, V30 @ 7.159090 MHz
  • Sound Chip : YM2151 @ 3.579545 MHz, GA20 @ 3.579545 MHz
  • Other Chip : GA21, GA22

List of games on this platform:

  • Blade Master / Cross Blades! (1991)
  • Dream Soccer 94 (1994)
  • GunForce (1991)
  • Gunforce 2 / Geostorm (1994)
  • Hook (1992)
  • In the Hunt / Kaitei Daisensou (1993)
  • Lethal Thunder / Thunder Blaster (1991)
  • Major Title 2 / The Irem Skins Game (1992)
  • Mystic Riders / Gun Hohki (1992)
  • Ninja Baseball Batman / Yakyuu Kakutou League-Man (1993)
  • Perfect Soldiers / Superior Soldiers (1993)
  • R-Type Leo (1992)
  • Undercover Cops (1992)

With these premises I begun my troubleshooting on an Undercover Cops and GunForce PCBs.

I bought the first as faulty:


Seller warned me about severe corrosion in some area of PCB, this was confimed once received the board, it seems like the board has been stored in a very humid place :


Anyway, once powered it up I got this:

Game actually played blind.I noticed that if I pressed the PAL marked “M92-A3-M” @IC11  graphics were restored in a bad way though:


This was not a case since this PAL was located in the corroded area so I decided to remove the socket.Underneath I found this scenario:


After cleaning from corrosion, I checked all the connections and found a missing contact bewteen pad of pin 8 (an input of the PAL) and its trace which I promptly patched with some kynar wire:


With this fix graphics were almost good but there were jailbars all over the screen:


Again, pressing a specific area of the PCB restored graphics temporarily so I started to look around until I was able to locate the cause of that issue:



Several pins of a custom ASIC on the video board were lifted.Since the pads were corroded too,a reflow was not enough to ensure a good soldering so I decided to reinforce it using some pieces of AWG3o wire :


This fixed this first M92 board completely:


So I moved on the GunForce PCB:


First thing I noticed after my visual inspection was the lack on many electrolytic capacitors in the audio circuit:


Board booted up but video as disturbed and a rustling sound was present on backgorund :

Usually this issues are caused by increased ESR of elecrolytic capacitors which inject disturbs on video circuit as well.The previous repairer thought about this and therefore removed all the electrolytic capacitors but this didn’t cure the problem.But He forgot to check the main amplifier:


Probing in AC the +12V line with my scope confirmed that ripple was present:


If I excluded the +12V from my supergun the video became normal and no more rustling sound.So, since on PCB there was no other component connected to this supply line, the amplifier was most likely the culprit.I removed it :


After fitting a good amplifier and all the missing capacitors, the video and sound were perfect but other two issues were present : the controls didn’t work and sprites were glitched.As for first issue, it was due the fact someone replaced a couple of custom resistor arrays with normal 4.7Kohm ones:


Like the ‘8M472J221J’ part name said, the original array is a mix of 4.7KOhm and 220 Ohm resistors.Not having other spare parts, I opted for a custom solution keeping the 4.7Kohm array and mounting some SMT 220 Ohm resistors on solder side:


This worked perfectly, controls were responding  so I moved on to troubleshoot the sprites issue:

Sprite devices were four 2Mbit MASK ROMs (compatible with 27C020 EPROM) on video board:


I reprogrammed a 27C020 for each ROM file in order to do piggybacking.When I did it on the one @IC41 glitches vanished.I removed the device:


My programmed warned me about a bad contact on pin 31 while I was reading it:


I socketed and replaced it :


100% fixed!End of this double Irem repair.

 Posted by at 1:30 pm
Aug 092016

Another one of Muddymusic’s boards.
He actually sent me 3 of them in various states but I chose the cleanest and most complete to focus my attention on.
Game booted to a screen of garbage and the watchdog was constantly resetting the machine.
I initially checked all of the ROM’s and they all checked out fine so I guessed the issue was going to be RAM.
I desoldered the 68000 CPU anyway so I could use the Fluke 9010 and see what was going on.
Looking at the memory map in the MAME source code in othunder.cpp we can easily see where various things sit.

First off I checked the CPU is able to actually read the ROM’s properly. I calculated the ROM signatures for this version and ran ROM checks.

Everything is good here, on to the RAM.
First is the main RAM at 0x80000 – 0x8ffff

So we have an issue straight away. At this point I did a few manual read/write tests.
First I wrote 0x5555 and reading it back gave me this
So it looks like half the RAM is working but needed to confirm by writing 0xAAAA.

So what we have tested here is the ability of the RAM data pins to be able to toggle HIGH and LOW.
0x5555 in binary = 0101010101010101
0xAAAA in binary = 1010101010101010

By testing both of these values separately instead of testing 0x0 and 0xFFFF we also test none of the adjacent pins are tied together.
So I removed both of these RAM chips and they both failed tests out of circuit.
Replacing them let the Fluke test pass and gave me the following screen

At this point it looked like the the game was trying to boot but kept resetting still.
Looking into the program code I could see that after the main RAM is tested the palette RAM is tested.
The palette RAM hides behind custom chip TC0110PCR which uses address 0x100000 – 0x100007 to deal with all of the RAM. Again following the code I could see the address is set by writing a byte between 0x0 and 0xFF to address 0x100004 and the data is set by writing a word value to 0x100002.
Here is what I got from my tests

Again it looks like one of the RAM chips is faulty.
Looking at the schematics I could see that RAM chips IC75 and IC79 are the ones im after and that IC79 is my problem RAM.

Replacing this RAM now gave me this screen
The image is reversed as this game normally uses a mirror to invert the picture.

Having identified the screen RAM from the schematics

I carried out a quick check using the scope and found something like this on some of the data pins

So out both of these came and then we got this

So whats up with the colours? I confirmed the RAM was good using the Fluke. Turns out I was 1 off when making up my adapter so this fault wasn’t actually a fault at all, just human error.
Fixing my mistake gave me this

This is good but there were some jailbars in the sprites.
I couldn’t get a clear picture of this as the RGB levels on my supergun are currently fixed and too bright but you can make out there are some differences between these two pictures.
The ripple is also caused by my RGB levels so ignore that

Finding this fault was quite easy. I knew the MASKROM’s were good as id dumped them out. The associated RAM looked good on the scope. The next bit in line were 2 x 74LS374 chips.

Looking with the scope I could see the inputs were present on IC20 but the outputs were stuck LOW.
I hooked the logic analyser up to prove this point. You can see that the inputs are changing state but the outputs are always 0x0

I replaced this and the graphics were restored.

Next onto the sound.
Hooking up the sound surprised me as the sound was present but there was an issue.

As there was some sound I was confident the CPU and ROM/RAM were good.
I had 2 other board sets so I opted to swap MASKROM’s one by one. Swapping B67-07 fixed the issue.

That’s as far as I can test this board now so will send it back.

 Posted by at 9:08 pm