Mortal Kombat 2 pcb repair help

myPinballs

Member
Joined
Nov 29, 2015
Messages
40
Reaction score
5
Location
Leeds, United Kingdom
So i'm starting another repair, after fixing the TMHT pcb. This time a midway Mortal Kombat 2 pcb. These boards are going to be additional games i can play when i find an original r-type cabinet and board :)

So this board was part of a few pcbs i picked up this week. The others were capcom cps era.

This board appears to be dead. I've been messing about with it on and off over the last few days. This is what i get when powering on

attachment.php


Then after a few seconds the screen goes blank and i never get to the handy cpu board test screen :( Bloomin annoying.

Board is in good condition. No corrosion or previous repairs afaict.

attachment.php


Board is the later version, with the 8mb roms so no need for the memory expansion card. I have removed the sound card for now to. Checked the voltages and am sure i have a good solid 5v, ground and 12v coming in to the board.

Burned a new set of revision game roms even thought he originals checksumed ok. No change.

Probed the clock lines. All ok.

Probed the voltage and reset monitor ic. Reset line goes high for a few seconds and then goes low and high and repeats over and over, which is in time with the second Board led (DS3). The issue seems to be the watchdog line never pulses. So i'm guessing something is causing a cpu or custom asic crash. If you add a pulse to the watchdog line then it doesn't reset but still does not boot. So i'm thinking the monitor ic is ok.

Anyone have any ideas what's needed to get to the cpu test screen? Judging by whats on the screen, the custom asic seems the be the main ic, as the cpu is shown on screen as a test item. I haven't found any issues with the revision game roms. All address and data lines and enable lines are present and pulsing though.

I did think of a possible option, as there are 4 ram ics which are part of the cpu section, and 2 of them on this board are Fujitsu brand (from experience with konami i suspected these may be an issue) but they actually appear in the cpu test as 'scratch ram' tests so my logic says these can't stop the test screen appearing if they are tested after it displays.

Brain ache!!
 

Attachments

  • IMG_7658.jpg
    IMG_7658.jpg
    515.5 KB · Views: 164
  • IMG_7659.jpg
    IMG_7659.jpg
    478.3 KB · Views: 167
Last edited:
Anyone have any ideas what's needed to get to the cpu test screen? Judging by whats on the screen, the custom asic seems the be the main ic, as the cpu is shown on screen as a test item. I haven't found any issues with the revision game roms. All address and data lines and enable lines are present and pulsing though.

I did think of a possible option, as there are 4 ram ics which are part of the cpu section, and 2 of them on this board are Fujitsu brand (from experience with konami i suspected these may be an issue) but they actually appear in the cpu test as 'scratch ram' tests so my logic says these can't stop the test screen appearing if they are tested after it displays.

Bad scratch RAM or a related fault could potentially derail the game before it reaches the test screen. This RAM is essential for correct execution of the TMS34010 program. The startup code uses function calls and without a working stack to push/pop the return address, execution will run off into the weeds.
 
Bad scratch RAM or a related fault could potentially derail the game before it reaches the test screen. This RAM is essential for correct execution of the TMS34010 program. The startup code uses function calls and without a working stack to push/pop the return address, execution will run off into the weeds.


Many many thanks for the reply and info. Much appreciated. I was wondering about this type of thing. Its really tricky trying to fathom out why a board won't even get to the handy test screen and so have been trying to identify which parts are required for this first step.

I can't see any problems on any signal lines, address lines, data lines and i've had the 2 PLCC chips out a few times to reseat and checked continuity on all socket pins. I've also been through all buffer chips for the address generation so i'm kind of left with randomnly guessing as to which ics may be faulty it seems.

If anyone has ideas or has seen this problem before then i'd love to hear about it. I feel like the next action is to change these 2 fujitsu rams and see! I don't like this approach but don't see much else i can do. The 2 fujitsu ones are the lower 8 data bits D0-D7 which is also related to UJ12

I really wanted a way to try and reproduce the original screen fault in mame, but not sure how to corrupt ram chips in emulation! I know corrupting the version roms can stop it getting to the test screen.

It is like the program starts and displays the very first test ram garbage screen, then the cpu crashes and thats it. The screen displays until the watchdog timer expires on the maxim chip and triggers the reset, which then blanks the screen and just keeps looping the reset.
 
It is like the program starts and displays the very first test ram garbage screen, then the cpu crashes and thats it. The screen displays until the watchdog timer expires on the maxim chip and triggers the reset, which then blanks the screen and just keeps looping the reset.

Is it displaying the same test pattern on each reset loop or does it only appear once?
 
Is it displaying the same test pattern on each reset loop or does it only appear once?

The test pattern (ram garbage) as shown on the pic in the first post only appears for the first time before the watchdog timeout kicks the reset loop in. After that the screen is just blank
 
Last edited:
So, i removed my 2 fujitsu rams from the board in an experiment to see what happens without them. I thought i may as well start with these ics, seeing as the reliability of fujitsu ics over time isn't great. (learnt from previous konami repairs)

attachment.php


And the answer is the board does exactly the same thing without 1 or both of these rams installed. Hmmmmm. So i'm trying to determine if this helps understand things or not. I'm guessing that what ever is bust either isn't accessing the rams or the rams themselves are bad. I've got some new rams on the way to check so if this does fix it i'm going to be well happy.
 

Attachments

  • IMG_9574.jpg
    IMG_9574.jpg
    243.4 KB · Views: 135
Some progress finally :) And look what's coming up as bad so far! Fujitsu ram...

attachment.php


So here's how i got here.

Studied the address and data lines coming and going from the cpu. The roms, the settings ram and the 4 scratch rams along with the main custom asic along with various buffer ics seem to make up the system section. This is where i was concentrating my probing and testing. Spent what seems like 3 days looking over every trace, signal, connection again and again in this sea and got nowhere....

So decided to change the settings ram, as i wanted to use a battery free nvram anyway. I needed to make some changes to the maxim power management ic as this determines how the battery voltage is applied to this ic at power on and off. Removed the old ic

attachment.php


and installed a new 8k x 8bit nvram ic. Tried the boot up again no different. Also tried with the ram out no different.

Went back to the schematics again and traced through the data lines and address lines on all 24 pages in case i missed something. Then i noticed that the dip switches (2 banks of 8, 16 in total) are connected via buffers to the cpu data bus. This got me thinking about whether some settings or configs are read on boot, before anything happens. However checking the manual didn't show anything particularly useful for system use at power on. Had a break for awhile and thought about throwing it in the bin, or setting fire to the damn thing.....

Then late last night, fired up mame to check the boot ram screens and was wondering why the mame version doesn't perform the board test on boot. Didn't think much more about it until i was going through the various test screens after selecting the board test directly. On looking a the DIP switch test page i saw this:

attachment.php


Option 7 and 8 on UJ1 dip switch bank are NOT unused as quoted in the manual!! And option 7 looks very handy indeed. Also option 8 is how the board test knows what to check and what to display regarding the memory expansion board. i.e this is not automatically detected.

Checking the original board showed that dip switch 7 was indeed on and switch 8 was off. !!!!!!!!!

attachment.php


Altering these settings and then powering up the board again got me to the test screen as shown at the start :)

Now i know i have a bad scratch ram (just 1) and as i've already socketed those (pretty pleased at earlier the guess work) i know where to start! and can hopefully get to the next part of the test soon.

So lessons learned, never trust the manual!. Mame is invaluable for fixing hardware faults. Keep plugging away at a problem and you will prevail :)
 

Attachments

  • IMG_9592.jpg
    IMG_9592.jpg
    236.2 KB · Views: 121
  • IMG_9594.jpg
    IMG_9594.jpg
    186.2 KB · Views: 121
  • IMG_9600.jpg
    IMG_9600.jpg
    192.9 KB · Views: 129
  • dip switches mame.png
    dip switches mame.png
    197.8 KB · Views: 123
Last edited:
Back
Top Bottom