Jul 122018
 

Received from Austria this Devastators PCB (manufactured by Konami in the distant 1988)

The board was constantly watchdogging sign that no valid code was executed :

Probing the HD63C09E main CPU revelead some address lines were dead:

I removed it :

Trying the CPU in another board confirmed it was really bad so I replaced it.The board booted up but it was failing the POST showing two bad devices which at fist glance I could not recognize due the complete lack of graphics :

Thanks to MAME I figured out they were the ones @C11 and C14 :

On PCB they are the two 2k x 8-bit static RAMs (Motorola MCM2016 used) which are part of the palette colors circuit

Probing the one @C14 revealed stuck data signals:

RAM chip failed the out-of-circuit testing:

Now the board booted into game but with severe graphics issue : the backgrounds had wrong colors and sprites were missing.Sound was absent too:

I dumped the four OTP MASK ROMs that store tiles data and found three bad ones :

But this made no real improvements.Board is almost fully populated with Fuitsu TTLs so I went to test them in-circuit with a logic comparator starting from this part of circuit which is involved in color generation  :

I found five bad mutiplexers with floating outputs:

This restored correct backgrounds:

I decided to troubleshoot for first the lack of sound.Found in rapid succession these bad ICs:

  • YM2151 (with serial data output pin stuck high)
  • sound RAM and ROM
  • two 74LS74 @G5-F10

And a 74LS273 @B7 with some floating outputs:

Sound was back :

Now the lack of sprites.MASK ROMs check reported two bad devices @H4-K4 which are the ones  storing sprites data:

This particular PCB uses a bottom ROM board with sprites and audio samples ROMs :

But the top board can also host three 4Mbit devices for the same data so you can get rid of the ROM board :

This is what I opted instead of troubleshooting it since all the splitted ROMs were soldered in.I programmed three 27C400 EPROMs with MAME dumps:

The last issue I had to fix was releated to inputs, P1 UP was not working.Using schematics I quickly found and replaced a 74LS253 @E13 with a bad ouput :

Board finally 100% fixed and another battle won against Evil Konami and Fujitsu with this big booty:

 

 Posted by at 6:14 pm

Rolling Thunder 2 repair log

 PCB Repair Logs, Repair Logs  Comments Off on Rolling Thunder 2 repair log
Jul 112018
 

Got this game for a repair.

At boot it displayed the following:

Using Mame source code with the memory map I could narrow down that RAM0044Eo20 was the colour BLUE ram

Desoldering it I could confirm it was bad

After replacing it I still got:

30TIP, 31TIP and 33TIP error

After discussing with Charles MacDonald he pointed me to the DUAL PORT RAM.

It checks if the last entry in RAM (460FFF) is zero, if so that’s an error (should be non-zero)
Then it checks if 460FF contains byte 6B, if it doesn’t that’s an error too

I started to probe around the dual port ram

Until I found a stuck bit on the Left side of the Dual port ram which came from a 74HC175.

After changing it, the game booted but still with TIP33 error which could be erased by pushing the start button.

TIP33 is the error related to the EEPROM which is not inizialized correctly or contain some corrupted data. Normally you inizialize it only one time but everytime

started the pcb, I got this error and offcourse all the dipswitch settings couldn’t be saved correctly.

To cut a long story short, some smart guy changed the original EEPROM with a normal 8k SRAM!

I took a spare from a faulty final lap 3  and I could finally fix 100% the game

 

 

Black Tiger repair log #3

 PCB Repair Logs  Comments Off on Black Tiger repair log #3
Jul 012018
 

Although this is a bootleg it follows the original PCB closely.
Couple of easy fixes on this one.
First a character issue and second a sound issue.


As you can see in the video above, the screen is filled with “A”s and none of the text is correct

There is a seperate EPROM used for characters on this game.

Pulling this and reading back with my programmer yielded a valid dump for Black Tiger.
Checking the adjacent associated 74LS273’s and 74LS245 showed I had at least one pin floating.
I traced this back to a nearby TMM2016 which had D7 floating.

Replacing this fixed the screen

The sound issue was even easier. The sound program EPROM was completely smashed. Replacing it fixed the issue.

Job done.

 Posted by at 11:49 am

Sunset Riders repair log #8

 PCB Repair Logs  Comments Off on Sunset Riders repair log #8
Jun 042018
 

Was asked by a friend to repair his Sunset Riders.

When starting up the PCB, it was stuck in something resembling a watchdog fault.

But I’ve been working on Sunset Riders before and this didn’t seem like an ordinary watchdog. I felt that it went a little bit longer in the startup sequence before crashing.

The board was a bit dirty but I started with the usual:

  • Checking CPU signals like clock, reset and halt
  • Verifying the program ROMs
  • Checking the program RAM for odd signals

All looked ok, but then I found this at the 051550 reset signal generator.

Pin 1 on the 051550 looked like a cold solder joint.

Pin 1 is the clock signal input pin on this IC and without that input, I can understand that the game doesn’t boot up properly. Gave that pin a dab of solder

And booted up the game

Board fixed without any other issues 🙂

Jun 012018
 

Received from Germany this faulty DonPachi PCB for repair:

Board played almost ‘blind’, most of graphics was missing, only some corrupted text was visible:

According to MAME source there are three layers of graphics:

ROM_REGION( 0x100000, “layer0”, 0 ) /* Layer 0 */
ROM_LOAD( “atdp.u54”, 0x000000, 0x100000, CRC(6bda6b66) SHA1(6472e6706505bac17484fb8bf4e8922ced4adf63) )

ROM_REGION( 0x100000, “layer1”, 0 ) /* Layer 1 */
ROM_LOAD( “atdp.u57”, 0x000000, 0x100000, CRC(0a0e72b9) SHA1(997e8253777e7acca5a1c0c4026e78eecc122d5d) )

ROM_REGION( 0x040000, “layer2”, 0 ) /* Text / Character Layer */
ROM_LOAD( “text.u58”, 0x000000, 0x040000, CRC(5dba06e7) SHA1(f9dab7f6c732a683fddb4cae090a875b3962332b) )

I translated this info on hardware and figured out the relevant circuit of each layer:

Each circuit consists in a QFP custom ASIC (maked ’38’) which addresses an 8Mbit MASK ROM (or a 2Mbit EPROM for the text layer) reading back data that then are written to two 8K x 8-bit static RAMs.After succesfully  checked connection between ASIC, ROM and RAMs my suspicions fell on the 8k x 8-bit SRAMs, they were all manufactured by Sanyo so in my experience not a great guarantee of reliability.Probing the ones @U50 and U51 (which lie in the ‘layer 0’ circuit) revealed weak or stuck signals on many data lines:

I removed both:

Actually only the one @U51 failed the out-of-circuit testing:

Now all graphics were visibile.Backgrounds and sprites were fine but text was corrupted throwing garbage over the screen :

The ‘layer 2’ identified in MAME source as ‘ Text / Character Layer’ was obvioulsy the involved one.Checking the two Sanyo 8K x 8-bit SRAMs @U55 and U56 revealed again weak signals on data lines:

I removed them and installed machine sockets:

Actually both RAM chips successfully passed the out-of-circuit testing of my different programmers.Anyway, replacing them fixed completely the graphics:

But sound was horribly scratchy and corrupted as you can hear in the above video.Here it comes again to help my audio probe for checking the relevant circutit:

“Listening” to various points revealed the sound was clear on the analog output of the two OKI MSM6295 and still good on outputs of the LM324 OP-AMP and input of the LA4460 amplifer.It was fine too on one output (pin 7) of the LA4460 amplifier:

 

But corrupted on the other output (pin 9)

I ruled out all electrolytic capacitors checking them in-circuit with my ESR meter (bad ones can affect sound in this way) so I decided to remove the LA4460 amplifer:

Put back a good one and some thermal compound for a better heat dissipation:

This restored a crystal-clear sound.Mission DonPachi accomplished!

 Posted by at 9:10 pm