13 Feb 2019

Hammer Away - Sega+Santos 1991 (repair log)

I got this game in a lot of faulty boards from ekorz. I'd like to thank him a lot, the boards were in great condition. According to him romboard was fine but motherboard had colour issue and a repair had been previously attempted. I could confirm both, game had a saturated blue colour, and both palette RAMs and a couple of nearby TTL chips had been put on sockets.



I started by probing the palette RAMs and found signal /WE of IC42 was floating. I traced it back to a LS244 (IC40) but piggybacking it made no difference. Then I found the two enable signals (1G/2G) of this LS244 were tied together and held high when not writting to the RAMs. This causes the output signals to go in high impedance state, however probing /WE signal of the second palette RAM revealed it was high so there clearly was a pull-up resistor involved. I measured 1kΩ resistance with Vcc whereas the floating output measure few MΩ. Looking at the board closely I discovered a 1kΩ resistor between the two palette RAMs. On was tied to Vcc as expected the the other, altough aligned with the /WE pin of the RAM IC42 was connected to nothing. I could see the trace was going straight to the rivet (only few millimetres away) of /WE pin so to me had to be connected there. I restored connection and colours were fixed:



I then tested inputs, sound, etc. but found nothing else wrong.
Game (very easily) fixed.

6 Feb 2019

Master System II - Sega (uneconomical repair)

Some repairs aren't worth the effort an time they would need. I'm looking at you faulty Pit Fighter PCB! But giving up is the easy way and I like challenges.

Here we have a faulty Master System II. According to previous owner left direction for player 1 is stuck. I powered the console (with Alex Kidd built-in) and sure enough Alex went straight to the left. I opened the unit and found the custom chip handling (amongst other things) inputs was a 315-5237. SMSPower website has tons of info about the MS and is an extremely valuable source, thanks to all of you guys contributing to it. So I quickly found pinout and probed pins used for controls:
- P1 down was floating
- P1 left was stuck low (= seen as button depressed)
- P1 right was stuck low (= seen as button depressed)
Other controls seemed fine (P1 up/buttons, P2 controls). This was confirmed by testing the player 2 port with different games, however behaviour for player 1 changed from game to game:
- Alex Kidd = keeps going left and impossible to crouch/duck
- Double Dragon = keeps going down/right
- etc.

Not that way Alex!

Ugh... I'm cornered.

I suppose this all depends on how each game was coded and what priority was given between up/down and left/right directions.

Anyway pull-up resistors for those inputs are embedded in the custom chip and previous owner already installed an external resistor but it didn't do the trick. I measured resistance for all 3 faulty inputs and found:
- P1 down wasn't connected to anything internally (no pull-up resistor measured, in fact resistance was infinite with any other pin)
- P1 left and P1 right had only few dozens of ohms resistance with ground so wasn't surprising the external 4.7kohm resistor didn't work

I could have stopped there, custom chip being faulty I would have needed a replacement from an other Master System II with the same motherboard. Sega hardware is generally rock solid and only faults I've repaired before on Master System II were broken solders on the AV port and severed traces, in other words even if I had found a compatible donor it's likely repairing it would have been simple. At least simpler than pulling the DIP48 custom chip and transplanting it in the other console.

Having repaired older Sega hardware similar to the Master System (e.g. Mark III) I knew controls could be read and data sent on the bus with simple TTL chips. My idea was to reverse engineer the part of the 315-5237 custom chip handling inputs.
I started to build a small test circuit with the custom chip on a socket and a GAL chip to recreate the faulty part of the custom chip. I lifted pins of the custom chip corresponding to P1 down/left/right and data bits D1/D2/D3 in order to isolate them.


The Master System reads control trough two mapped ports $DC and $DD, inputs are latched to the data bus:
- $DC.d0 = P1 UP
- $DC.d1 = P1 DOWN
- $DC.d2 = P1 LEFT
- $DC.d3 = P1 RIGHT
- $DC.d4 = P1 BUTTON  1
- $DC.d5 = P1 BUTTON 2
- $DC.d6 = P2 UP
- $DC.d7 = P2 DOWN

- $DD.d0 = P2 LEFT
- $DD.d1 = P2 RIGHT
- $DD.d2 = P2 BUTTON 1
- $DD.d3 = P2 BUTTON 2
- $DD.d4 = RESET BUTTON (not present on MS2 anyway)
- $DD.d5 = Cartridge slot CONT signal
- $DD.d6 = P1 LIGHTGUN/REGION BIT 1
- $DD.d7 = P2 LIGHTGUN/REGION BIT 2

Given all other functions of the custom chip were working fine I went for the minimal replacement solution, that is to say reading of P1 DOWN/LEFT/RIGHT inputs and latching them to D1/D2/D3 on the data bus. It was quite easy to figure out equations. Here is the PLD file I wrote for a GAL16V8 chip in case someone else has a similar issue and wants to take inspiration (for some reason WinCUPL didn't allow me to use more than one term for the OE equations so I used a spare output, it might be a GAL16V8 limitation):

Name      315-5237_repair;
Partno    ;
Date      ;
Revision  ;
Designer  Apocalypse;
Company   ;
Assembly  None;
Location  None;
Device    G16V8;
/**  Inputs  **/
PIN 1 = JyDs;
PIN 2 = A0;
PIN 3 = A6;
PIN 4 = A7;
PIN 5 = RD;
PIN 6 = IOREQ;
PIN 7 = DOWN;
PIN 8 = LEFT;
PIN 9 = RIGHT;
PIN 11 = IN_OE;
/**  Outputs  **/
PIN 18 = D1_BUS;
PIN 17 = D2_BUS;
PIN 16 = D3_BUS;
PIN 15 = D1_5237;
PIN 14 = D2_5237;
PIN 13 = D3_5237;
PIN 12 = OUT_OE;
/** Logic Equations **/
OUT_OE = !RD & !JyDs & !IOREQ & A6 & A7;
D1_BUS.OE = IN_OE;
D2_BUS.OE = IN_OE;
D3_BUS.OE = IN_OE;
D1_BUS = !A0 & DOWN # A0 & D1_5237;
D2_BUS = !A0 & LEFT # A0 & D2_5237;
D3_BUS = !A0 & RIGHT # A0 & D3_5237;
D1_5237.OE = !IN_OE;
D2_5237.OE = !IN_OE;
D3_5237.OE = !IN_OE;
D1_5237 = D1_BUS;
D2_5237 = D2_BUS;
D3_5237 = D3_BUS;
And then was successfully tested:



Console (uneconomically) fixed.

30 Jan 2019

Slot PGM - IGS (repair log #2)

I received this faulty PGM slot as part of my Christmas gift from my friend Lorenzo2mars.
Problem was red colour being saturated in-game:



However some screens appeared fine:




Colours bars in the hardware test menu also appeared correct:


So did the RAM check (from my experience colour RAMs U23/U24 correspond to RAM 5 in the test):


To me problem was downstream in the late colour generation stages (DAC). I followed data lines from the colours RAMs leading me to the IGS custom chip U6 (stamped IGS026) then on the other side of this custom were custom resistor arrays (stamped RSA1) and few other components (transistors for amplification and few resistors to drive them). I quickly found each analog colour signal could be mixed with one coming from the expansion connector (same one used for 3p/4p inputs). Was this functionality ever used (photo booth or similar?). I probed the transistors used for the red colour (Q3/Q4) but they seemed ok. I went back to the custom resistor array noted RN1 on the silkscreen and found connectivity was lost between its legs in the middle. Having a spare IGS motherboard in my part bin I was able to replace it. While pulling the faulty one this happened:


It was probably cracked before but I couldn't notice it. Once replaced red colour was back to normal:



An extremely easy repair this time!
Board fixed.

23 Jan 2019

Sega System E to JAMMA


While working on a side project (multi System E) I decided for once to make a nice JAMMA adapter instead of a handmade one with dozens of sagging wires.

Nothing fancy here, it's easy to install and does the job:

















16 Jan 2019

Wrestlefest - Technos 1991 (repair log)

This board was bought by Kelvin as working but on arrival it was clearly not. Luckily for him he got a full refund.
This is the Korean version of the game, not sure what are the differences outside of the "KOREA ONLY" text in the intro.

I powered the board and found the following issues:
- wrong colours
- horizontal lines in the background
- garbled/misplaced sprites
- no sound
Not bad for a working board... 😒

Wrong colours:


Found one of the colour RAMs (IC55, 6116 narrow type) faulty:


Horizontal lines in the background:



Found a severed trace due to a poor previous reflow job on the custom chips. I used the core of some kynar wire on few millimetres making it almost invisible.



Garbled/misplaced sprites:

Found both sprite RAMs (IC26/IC27, 6116 narrow type) were bad:


This revealed an other issue, sometimes sprites had "holes":


Found mask ROM IC15 bad (27C080 compatible):


No sound:

Found sound RAM IC41 (again 6116 narrow type) was faulty. However replacing it gave me activity on buses but sound was still absent.
Using an audio probe I could hear both music (from the YM2151) and samples (from the M6295) were generated correctly before amplification. However nothing came out of the two pre-amps IC74/75 (Fujitsu MB3615, silkscreen says M51516). I replaced them and sound was fully restored.


To complete the repair I replaced a cap hanging by one of its legs.




Game fixed.

9 Jan 2019

Sega 315-5298 GAL22V10 alternative (System 16B)



While working on the System 16B multi I soon discovered some romboards (171-5704/171-5521/171-5797) contained a PLS153 chip noted 315-5298 used for tiles banking. Unfortunately I own only one System 16B game (Shinobi) and it runs on 171-5358 romboard which is the simplest one and lacks the PLS153 chip (not needed as early games had less tiles). Fortunately collector lapsus sent me one for dumping (side note: PLS153 can't be read protected/locked).

Using MAME's tool jedutil I dumped equations (jedutil -view source.bin device, where device = PLS153):

Inputs:
1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19
Outputs:
9 (Combinatorial, Output feedback output, Active high)
11 (Combinatorial, Output feedback output, Active high)
12 (Combinatorial, Output feedback output, Active low)
13 (Combinatorial, Output feedback output, Active low)
14 (Combinatorial, Output feedback output, Active high)
15 (Combinatorial, Output feedback output, Active high)
16 (Combinatorial, Output feedback output, Active high)
17 (Combinatorial, Output feedback output, Active high)
18 (Combinatorial, Output feedback output, Active high)
19 (Combinatorial, Output feedback output, Active high)
Equations:
o9 = /i4 & o14 +
     i4 & o17
o9.oe = vcc
o11 = /i4 & o15 +
      i4 & o18
o11.oe = vcc
/o12 = /i4 & o16 +
       i4 & o19
o12.oe = vcc
/o13 = /i4 & /o16 +
       i4 & /o19
o13.oe = vcc
o14 = i5 & o14 +
      i7 & o14 +
      i6 & o14 +
      i1 & /i5 & /i6 & /i7
o14.oe = vcc
o15 = i5 & o15 +
      i7 & o15 +
      i6 & o15 +
      i2 & /i5 & /i6 & /i7
o15.oe = vcc
o16 = i5 & o16 +
      i7 & o16 +
      i6 & o16 +
      i3 & /i5 & /i6 & /i7
o16.oe = vcc
o17 = /i5 & o17 +
      i7 & o17 +
      i6 & o17 +
      i1 & i5 & /i6 & /i7
o17.oe = vcc
o18 = /i5 & o18 +
      i7 & o18 +
      i6 & o18 +
      i2 & i5 & /i6 & /i7
o18.oe = vcc
o19 = /i5 & o19 +
      i7 & o19 +
      i6 & o19 +
      i3 & i5 & /i6 & /i7
o19.oe = vcc

Then I converted them for a GAL22V10 (thanks to lapsus again for probing the PLS153 pinout/signal names).
GAL16V8 is unfortunately 1 output short and I have no GAL18V10 in my parts stock (was it ever used on any arcade PCB?).

Name U153_V1;
Partno PAL_CE;
Revision 01;
Date 01/05/2018;
Designer Apocalypse;
Company None;
Location None;
Assembly None;
Device g22v10;
/****************************************************************/
/* */
/* General File Comments */
/* */
/****************************************************************/
/*
* Inputs: define inputs in this section
*/
Pin 1 = db0;
Pin 2 = db1;
Pin 3 = db2;
Pin 4 = ga15;
Pin 5 = ad1;
Pin 6 = rom2;
Pin 7 = lwr;
/*
* Outputs: define outputs as active HI levels in this section
*/
Pin 23 = o19;
Pin 22 = o18;
Pin 21 = o17;
Pin 20 = o16;
Pin 19 = o15;
Pin 18 = o14;
Pin 17 = ce1;
Pin 16 = ce2;
Pin 15 = a16;
Pin 14 = a15;
/*
* Logic: logic equations in this section
*/
a15 = !ga15 & o14 # ga15 & o17;
a16 = !ga15 & o15 # ga15 & o18;
!ce2 = !ga15 & o16 # ga15 & o19;
!ce1 = !ga15 & !o16 # ga15 & !o19;
o14 = o14 & (ad1 # rom2 # lwr) # db0 & !ad1 & !rom2 & !lwr;
o15 = o15 & (ad1 # rom2 # lwr) # db1 & !ad1 & !rom2 & !lwr;
o16 = o16 & (ad1 # rom2 # lwr) # db2 & !ad1 & !rom2 & !lwr;
o17 = o17 & (!ad1 # rom2 # lwr) # db0 & ad1 & !rom2 & !lwr;
o18 = o18 & (!ad1 # rom2 # lwr) # db1 & ad1 & !rom2 & !lwr;
o19 = o19 & (!ad1 # rom2 # lwr) # db2 & ad1 & !rom2 & !lwr;

It made perfect sense to me (data bits are latched to create higher address lines).
Testing on my custom multi romboard revealed it worked pefectly fine.
lapsus confirmed it to be working on OG hardware too by using a small adapter to reroute a couple of signals as the PLS153 is DIP20 and GAL22V10 is DIP24:
- ground by connecting pin 12 (GAL22V10) to 10 (PLS153 socket)
- generated a15 line from pin 14 (GAL22V10) to pin 9 (PLS153 socket)
GAL22V10 pin 1 has to be aligned to PLS153 socket pin 1, pins 11/12/13/14 stick out:

PLS153 GAL22V10
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 14
10 12
11 15
12 16
13 17
14 18
15 19
16 20
17 21
18 22
19 23
20 24

15 Nov 2018

Tumblepop - Data East 1991 (repair log)

Board had apparent corrosion damage.


Surprisingly on boot up it worked mostly fine, only sprites were a diagonal garbled bar:



I probed the board and found two data lines on one of the sprite RAM were stuck low. I pulled it but it tested good. I continued probing the board and finally found a missing input on the LS157 @D4 (pin 3, signal I1a). I tried to followed the trace but it then disappeard under the custom chip '52' used for sprite generation. By deduction I found it should be connected to pin 13 of LS157 @11A. Restoring the connection made sprites appear at the right place but still garbled:


I went back to the stuck data bits on one of the sprite RAMs, it lead me trough bus transceivers, etc. And  finally to the '52' custom chip. On the other "side" of the chip were mask ROMs used for sprites so it was double or quits. Without much hope it checked connections between the custom chip and the mask ROMs and found two data bits signals weren't reaching the '52' chip. By exposing copper just before the pads of that chip I discovered connections were lost on the last half of a millimeter before the pads. If restored connections with a bit of solder and this time sprites were fully back:




Game fixed.