SSV system colours problem repair log

 PCB Repair Logs, Repair Logs  Comments Off on SSV system colours problem repair log
Aug 142019
 

Some months bought for my collection Vasara and Vasara 2 in bundle from an american guy.

From the beginning Inoticed that Vasara had very dimmed colours and required to adjust monitor constrast to the maximum in comparison to Vasara 2.

Since I was not familiar with this system I thought it was due to the motherboard revision which is earlier on Vasara ( and there is a factory mod to make it compatible)

After some months I decided to check on internet if someone had a similar problem and I found mentioned on system11 blog about Cave CV1000 colour problems.

Repair – Cave CV1000 colour problems

According to him it’s a very common problems on SSV games and I found also mentioned on japanese blog sites afterward.

I checked with the oscilloscope the signals coming out from the 4 2sc1674 transistors ( RGB ans SYNC) and indeed all of them very about 2volts, same intensity of the inputs.

Signals in Vasara 2 in comparison were about 3,5V

I decided to change all of them and indeed it fixed the dimmed colours which are now very bright and crisp

 

 

What I find really curious is that all of them went faulty, I think  probably the transistors choosen by Seta are not correct for this kind of load.

Maybe someone with a good electronic background can shed a light

Pacmania repair log #3

 PCB Repair Logs  Comments Off on Pacmania repair log #3
Aug 132019
 

Got another Pacmania faulty.

This time the sprites were glitchy with some black lines

 

Custom 39 is usually involved in sprites generation but after testing with a good one problem remained.

There are two 74ls377 connected to it and one @A3 has one missing output.

Changing it fixed the board

 

 

The New Zealand Story repair log #5

 PCB Repair Logs  Comments Off on The New Zealand Story repair log #5
Aug 022019
 

Received for repair from New Zealand this The New Zealand Story PCB (sorry for the wordplay…), the one layer hardware revision :

Board booted up but graphics were totally wrong :

GFX data are stored in eight 28 pin 1Mbit MASK ROMs whose pinout is pretty identical to 32 pin 1Mbit non-JEDEC EPROM (extra pins apart)

Before dumping them I used my logic probe and found stuck upper address lines (pin 12-13-14-15)

I traced the address lines back to outputs of a 74LS174 @U9 whose inputs were floating, these came from a Fujitsu 74LS374 @U41:

Inputs of it were toggling but all outputs were stuck at undefined voltage level of 1.48V, this is the typical way of failure of Fujitsu TTLs :

The chip failed the out-of-circuit testing, all outputs were indeed in ‘Z’  (or high-impedance if you prefer) state :

Once replaced the IC the graphics were restored but I noticed some corruption on title screen :

I dumped the 1Mbit MASK ROMs and my programmer complained about the one @U7  :

This was a good chance to use one of my adapters I designed some time ago for replacing the 28 pin 1Mbit MASK ROMs with a TSSOP Flash ROM

But suddenly during power cycling the graphics went bad again :

I quickly pinpointed the fault to another 74LS374 @U10 with floating outputs, another Fujitsu one obviously :

Chip totally failed the out-of-circuit testing:

Graphics were now perfect so I started a game but controls didn’t work, the main character of both players moved by itself:

 

Looking at hardware I figured out the I/O circuit.The inputs from JAMMA connector go to some custom resistor arrays marked ‘X2-005’ and then signals are routed to a 52 pin SDIP custom chip marked ‘X1-004’ that handles them :

Resistor arrays did their job by pulling-up the signals and then routing them to the custom so most likely the ‘X1-004’ was bad.I played the card of replacing it but I had to struggle before finding a good spare as it seems this custom is quite prone to failure.I tried two donor parts but they were faulty until I caught the good one:

This fixed the controls and board completely.Repair accomplished.

 Posted by at 9:25 am

Bubble Bobble repair log #5

 PCB Repair Logs  Comments Off on Bubble Bobble repair log #5
Jul 262019
 

Received for repair from New Zealand an original Bubble Bobble PCB.Set is made of a CPU board

And a VIDEO board:

It came already adapted to JAMMA so it was just matter to plug it in.I did it but nothing came up on screen. I noticed wires were soldered onto the pins of ‘H’ connector and then a molex connector was used to carry power to JAMMA fingerboard:

I didn’t like this solution because it can cause loose connection so I removed the molex connector and soldered wires directly to JAMMA fingerboard.In this way the board properly booted up, games was perfectly playable with sound too but every alternate horizontal line of graphics was missing :

From top of my experience I know this kind of issue are most of times caused by bad counters (74LS161/163/169).Looking at board I spotted two rows of 74LS169 on bottom VIDEO board:

From schematics I could see they are involved in VIDEO RAM data bus, this made sense :

I went to probe these 74LS169 in circuit with my HP10529A logic comparator, all of them passed the test except the one @IC64 that gave troubles on all its outputs:

I pulled the part out :

It failed the out-of-circuit test on my BK560 :

I installed socket and a fresh IC :

This cured the issue and fixed board completely.End of job.

 Posted by at 10:56 am

Space Invaders DX double repair log

 PCB Repair Logs  Comments Off on Space Invaders DX double repair log
Jul 262019
 

I received from Portugal a couple of Space Invades DX PCBs, a game released in 1994 by Taito (more or less a port of the original Space Invaders, with a few new features).

Both boards were in very good condition but completely dead.Here’s the first one:

All I got on power up was a steady black screen.Probing the 68000 main CPU revealed the address/data busses were active but the three interrupts inputs (IPL0-IPL1-IPL2) were all in fixed high logical state.I traced these inputs back to a PALCE20V8 marked ‘D72-07’ :

Then I disassembled the fusemap of the MAME dump of this PAL being able to identify its inputs and outputs:

/** Inputs **/
Pin 1 = i0;
Pin 2 = i1;
Pin 3 = i2;
Pin 4 = i3;
Pin 5 = i4;
Pin 6 = i5;
Pin 7 = i6;
Pin 8 = i7;
Pin 9 = i8;
Pin 10 = i9;
Pin 11 = i10;
Pin 13 = i12;
Pin 14 = i13;

/** Outputs **/
Pin 15 = o15; /**(Combinatorial, No output feedback, Active low) **/
Pin 16 = o16; /**(Combinatorial, Output feedback output, Active low) **/
Pin 18 = o18; /**(Combinatorial, Output feedback output, Active low) **/
Pin 19 = o19; /**(Combinatorial, Output feedback output, Active low) **/
Pin 20 = o20; /**(Combinatorial, Output feedback output, Active low) **/
Pin 21 = o21; /**(Combinatorial, Output feedback output, Active low) **/
Pin 22 = o22; /**(Combinatorial, No output feedback, Active high) **/

Pin 20-21-22 were outputs to 68000 interrupts lines and they were confirmed to be stuck high along with all other outputs :

Although PAL was secured I tried to read it in my programmer, this would have at least told me the state of ‘health’ of the chip.Reading failed hence the chip was faulty:

I burned a GAL20V8 (GAL and PALCE are most of time interchangeable) with MAME fusemap :

Board booted up with no further issue.First board repaired.

 

The second board:

As said, it was completely dead.Probing the 68000 main CPU revealed the clock input was stuch high:

I traced it back to a 74F161 @IC51 which acts as a clock divider of the 32Mhz signal generated by the near oscillator :

There was nothing coming from the oscillator into the clock input (pin 2) of this 74F161 counter:

At first glance I thought the oscillator was dead but before replacing it I made a visual inspection on solder side.I found a dry joint on its output pin :

I promptly reflowed it and then powered up the board again.It booted up with no further issues.Double repair accomplished.

 Posted by at 10:34 am