Oct 262019

I have a ninja spirit on my collection since more than 10 years. I play it regularly but the other day it once powered up the foreground layer had some vertical black bars crossing the screen for the complete height on the right side.

After a while also the left part started to blick glitching ( cannot be seen on the screenshot below unfortunately)

The board is an irem M72 and the background and foreground layers are handled on the bottom board. The circuit for both playfields is completely the same.

Schematics are available for Rtype which is the same hardware minus the C board.

I checked immediately the circuit which draws the foreground and decided to check a couple of TTL

With some luck I immediately found one 74ls283@10A (IC 78) which was glitching badly the left part of the screen  when testing with the probe on pin 10.

74LS86@7B ( IC50)was also glitching the screen when testing with the probe on pin 6

The HP logic comparator gave me bad outputs on some pins of these TTLs.

After desoldering them I tested on my TTL tester and they were declared good!

I decided to solder back  new ones to be on the safe side and to my surprise the game was fixed.

Turns out that the TTL tester didn’t catch the subtle faults of these ICs ( not Fujitsu parts!)

Jul 262019

Here’s a repro of the KNA 6032601 found on boards like Kung Fu Master and Tropical Angel.

While it’s not known to fail as often as the KNA 6034201 (which Caius has already made a repro of ) it has been know to start failing lately.


It’s a 40 pin custom IC on the TOP board of the kung Fu Master stack, sitting at E1 & E2 between two rams and the colour proms

This most likely deals one deals with the final image processing, like layer priorities, just before outputting data into the colour proms

I used a bootleg to see how this one was reverse engineered by bootlegers at the time and identified and area between the rams and the colour proms.

Tracing multimeter confirmed those 9 LSxx ICs were indeed connected to the same ICS as the custom. So I fired up easyEDA and got busy .

A few days later, voila! a working IC and a working board. Not a complicated thing to do, it just takes time to trace back everything .

Huge thanks to Caius for his recent inspiring work on making repros for a lot of these custom ICs and has prompted me to look into the topic and start making my own too. The more the better !

And as usual, for those who prefer the video format :

X Multiply repair log #3

 PCB Repair Logs, Repair Logs  Comments Off on X Multiply repair log #3
Aug 112014

Yes, again.
During some playing of this recently repaired board the game froze up.
On reset I was greeted with this static screen.

Non booting boards are generally quite easy to fault find but due to the V30 I was having problems. This is when I came across a post on KLOV from some time ago with someone asking if an 8086 Fluke POD could be used to test a V30 based system. The general thinking was that it could but no one ever tried it, until now!
Im pleased to say it does work (excluding the RUN UUT function).

Very quickly I found that the main ROM’s could not be read properly. The correct signature was 6A03 and I was getting 6935.
Following my schematics I found that there is a 74LS373 at location IC51 that is used as the latch to address the ROM’s.

This input was confirmed good but there was a stuck bit on the output.
I replaced this and the game was back once again. Ive left this soak testing and hopefully it will be rock solid now.

So just to confirm. The 8086 pod for a Fluke 9010/9100 can be used to check V30 based systems.

Jul 262014

I recently sold this PCB but after a week I was told the board had developed a fault.
The fault showed up as “RAM NG 10” at boot-up and there was some issues with the sprites.

There is absolutely no logical meaning to the error message so using MAME I started corrupting different RAM values during it POST to see what RAM errors were flagged up during which memory writes.
Originally I couldn’t understand how the awful V30 CPU worked. Without knowing how it worked I was unable to use the MAME debugger effectively. Charles MacDonald came to my rescue and told me how the V30 addresses were set. Thanks very much to Charles.
You can see the outcome of that exercise in THIS previous post.

So now I knew for sure that the fault was with the sprite RAM. Now the next challenge, which RAM chip is the sprite RAM?
I originally tried shorting some address/data lines on RAM chips to see if any other errors were flagged but strangely it didn’t show anything else at all.
With nothing left to try I started making my own schematics up in the hope I could work out which RAM was responsible for the sprites.

Due to the complex nature of this board set, I was stuck for quite some time looking on the lower video PCB assuming (yes I know) that this is where the sprite RAM could be but was unable to find any problems at all.
Taking a step back I reversed the PAL chip XM_A-7D- into equations. Using these equations and the schematics I had drawn up I could take an educated guess as to what RAM chip was the sprite RAM.
Knowing that the sprite RAM lies at address 0xc0000, this means that address pins A19 & A18 would need to be active. Looking at the equations I could see that output pin 17 of the PAL chip would fit this address so I followed the signal which led to the /CE line of a 74LS245 of IC40 on the top CPU PCB.

The only chip that this chip goes to is a 2018 RAM chip at location IC52.
This was pretty good news. I removed the chip and it failed the tests so I replaced it and now all the POST tests pass.
The sprites are all back to how they should be too.

Ill be keeping hold of this board I think. It was one of the first games I ever bought since getting into this hobby so it will stay with me for good now.