29 Nov 2017

Twin Cobra - Taito 1987 (repair log)

Game was completely dead: black screen, no sound.



On this hardware many things can lead to this as it seems the self test requires a lot of things to be operational before displaying the RAM/ROM test screen.

1) Getting the board to boot

I started to probe the board and found many signals were absent on the top board. In fact they were present only a fraction of second on start-up. Long story short they were coming from various LS245s, themselves having their enable pin (/E signal) coming directly from address line A16 of the main CPU (68k). I was a bit lost so went back to the basics : RAMs.
One of them on the top board had all its data pins stuck high. I took the chance to piggyback it and game booted:


 
But with no sprites at all...

2) Fixing the graphic glitches

The concerned cicuitry is on the top board and probing the six 2148 RAMs I found one had data signals tied low. They were coming from a LS244 which in turn had inputs stuck low. This lead me to a LS74 and finally to a series of LS166 which had their shift/load pins shorted to Vcc.
Due to the corrosion of the board I wasn't able to determine the point of least resistance so I pulled the chips I identified were connected to this stuck signal:
- LS166 @ 13E pin 15
- LS166 @ 14E pin 15
- LS166 @ 16E pin 15
- LS166 @ 17E pin 15
- LS374 @ 23D pin 11
The last chip I pulled was the LS166 @ 13E and it was indeed the culprit.
Unfortunately I didn't have any in stock but I powered the board without it in hope for any improvement : sprites were back. Corrupted but back:


After I received the replacement part I put it back on the board and:



Game fixed.


22 Nov 2017

Ribbit- Sega System C2 - Palette hack

This is the last game running on Sega System C2 I had to patch to have a full patched set.
But Ribbit is one of the two games on System C2 which uses palette shuffling. For Twin Squash it was simply handled by offsets read from the program ROMs. Ribbit was really different, the
subroutine writing to the palette RAM is loaded in RAM and can be modified according to the security chip mode used.
I've identified 4 different subroutine but upon my trials I discovered they can all be used to display correct colours.
There are also 4 different palette shufflings used (well 3 as the first one is just no shuffling).







Whatever the subroutine used, it's always called at the same spot:


01F766: 4EB8 E274                  jsr     $e274.w


I simply dumped the first subroutine used:


FFFFE274: move.b  $c026.w, D0
FFFFE278: ori.b   #$7, D0
FFFFE27C: move.b  D0, $800201.l
FFFFE282: lea     $c124.w, A2
FFFFE286: moveq   #$0, D2
FFFFE288: move.b  #$ff, $c036.w
FFFFE28E: move.w  #$8b00, D0
FFFFE292: andi.b  #$4, $c021.w
FFFFE298: move.b  $c021.w, D0
FFFFE29C: or.b    $c020.w, D0
FFFFE2A0: move.w  D0, $c00004.l
FFFFE2A6: move.b  #$ff, $c03f.w
FFFFE2AC: bsr     $ffffe34e
FFFFE2B0: adda.w  #$8, A2
FFFFE2B4: bsr     $ffffe34e
FFFFE2B8: adda.w  #$8, A2
FFFFE2BC: bsr     $ffffe34e
FFFFE2C0: adda.w  #$8, A2
FFFFE2C4: bsr     $ffffe34e
FFFFE2C8: clr.b   $c036.w
FFFFE2CC: move.w  #$8b00, D0
FFFFE2D0: ori.b   #$80, $c021.w
FFFFE2D6: move.b  $c021.w, D0
FFFFE2DA: or.b    $c020.w, D0
FFFFE2DE: move.w  D0, $c00004.l
FFFFE2E4: move.b  #$ff, $c03f.w
FFFFE2EA: move.b  $c026.w, D0
FFFFE2EE: ori.b   #$6, D0
FFFFE2F2: move.b  D0, $800201.l
FFFFE2F8: tst.w   D2
FFFFE2FA: bne     $ffffe2fe
FFFFE2FE: andi.w  #$fc, D7
FFFFE302: or.b    $c02b.w, D7
FFFFE306: move.b  D7, $84000f.l
FFFFE30C: rts
FFFFE34E: move.w  ($6,A2), D4
FFFFE352: bne     $ffffe356
FFFFE356: moveq   #-$1, D2
FFFFE358: move.w  (A2), D7
FFFFE35A: rol.w   #6, D7
FFFFE35C: or.b    $c0be.w, D7
FFFFE360: move.b  D7, $84000f.l
FFFFE366: lea     $8c0000.l, A0
FFFFE36C: move.w  (A2), D0
FFFFE36E: andi.w  #$3ff, D0
FFFFE372: adda.w  D0, A0
FFFFE374: movea.l ($2,A2), A1
FFFFE378: move.w  (A2), D0
FFFFE37A: andi.w  #$c00, D0
FFFFE37E: adda.w  D0, A1
FFFFE380: subq.w  #1, D4
FFFFE382: lea     $fffe30e.l, A3
FFFFE388: move.w  A0, D0
FFFFE38A: lsr.w   #4, D0
FFFFE38C: move.w  (A3,D0.w), D0
FFFFE390: lsl.w   #4, D0
FFFFE392: lea     $8c0000.l, A3
FFFFE398: adda.w  D0, A3
FFFFE39A: moveq   #$7, D0
FFFFE39C: move.l  (A1)+, (A3)+
FFFFE39E: dbra    D0, $ffffe39c
FFFFE3A2: adda.w  #$20, A0
FFFFE3A6: dbra    D4, $ffffe382
FFFFE3AA: move.w  #$0, ($6,A2)
FFFFE3B0: rts



And moved it in the program ROMs space (there's plenty of space at the end).
I also inserted jumps to use the correct palette adressing depending of the mode used.


Here are the palette offsets used:


Mode 1 (no shuffling)


    0000 0002 0004 0006 0008 000A 000C 000E
    0010 0012 0014 0016 0018 001A 001C 001E
    0020 0022 0024 0026 0028 002A 002C 002E
    0030 0032 0034 0036 0038 003A 003C 003E


Mode 2


    0008 000A 000C 000E 0018 001A 001C 001E
    0028 002A 002C 002E 0038 003A 003C 003E
    0020 0022 0030 0032 0000 0002 0010 0012
    0024 0026 0034 0036 0004 0006 0014 0016


Which had to be recalculated as when using a different security chip palette shuffling isn't    supported (only the ones on Twin Squash and Ribbit! support it).
   
    0028 002A 0038 003A 0000 0002 0004 0006
    002C 002E 003C 003E 0008 000A 000C 000E
    0020 0022 0030 0032 0010 0012 0014 0016
    0024 0026 0034 0036 0018 001A 001C 001E


Mode 3


    0020 0022 0028 002A 0000 0002 0008 000A
    0024 0026 002C 002E 0004 0006 000C 000E
    0030 0032 0038 003A 0010 0012 0018 001A
    0034 0036 003C 003E 0014 0016 001C 001E


    Recalculated
   
    0008 000A 0018 001A 000C 000E 001C 001E
    0028 002A 0038 003A 002C 002E 003C 003E
    0000 0002 0010 0012 0004 0006 0014 0016
    0020 0022 0030 0032 0024 0026 0034 0036


Mode 4


    0000 0002 0008 000A 0004 0006 000C 000E
    0010 0012 0018 001A 0014 0016 001C 001E
    0030 0032 0034 0036 0020 0022 0024 0026
    0038 003A 003C 003E 0028 002A 002C 002E


    Recalculated


    0000 0002 0008 000A 0004 0006 000C 000E
    0010 0012 0018 001A 0014 0016 001C 001E
    0028 002A 002C 002E 0038 003A 003C 003E
    0020 0022 0024 0026 0030 0032 0034 0036















P.S.: This game doesn't seem to have an end




Yes, I've been that far, in fact the game just loops on the first 45 levels.







Also available:
- Columns
- Columns II
- Puzzle & Action: Ichidant-R
- Puzzle & Action: Tant-R
- Poto Poto
- Puyo Puyo
- Puyo Puyo 2
- Ribbit!
- Stack Columns
- Thunder Force AC
- Twin Squash (with joystick hack)
- Zunzunkyou No Yabou

15 Nov 2017

Conversion Street Fighter II: The World Warrior to Ghouls'n Ghosts (CPS1)

As you may know I do conversions on demand.

Recently I've been asked by a collector if I could convert Street Fighter II: The World Warrior to Ghouls'n Ghosts. SF2 WW is probably the cheapest game on the system nowadays and probably the easiest to come by too. However Capcom released many different versions of the game with of course different B chips (B-05/B-11/B-12/B-13/B-14/B-15/B-17/B-18). The most common is the B-17 and was what the collector had in its hands.

So first I converted the program ROMs to run using a B-17 chip instead of a B-01.
Then I handcrafted a new PAL to handle graphic chips addressing on a 90629 board.
Everything was tested in MAME and on real hardware (who doesn't have a spare SF2 WW board lying around?) with success.
It's a little less heartbraking to convert a SF2 WW rather than a SF2' CE or HF.



8 Nov 2017

Maju no Okoku (Devil World/Dark Adventure) - Konami 1987 (repair log)

When I started this repair I was a bit anxious, the hardware is complex (Twin 16), composed of two boards (sometimes 3 with an additionnal ROM board) and they were heavily Fujitsu populated...
After inspection I noticed one capacitor in the sound section was attached by one leg, same for the 640kHz crystal used for voice effects but this shouldn't stop the board from booting. I powered it: board was displaying a garbage screen flickering at fixed interval.


Clearly the game was stuck in a reset loop caused by the watchdog, probably because no valid code was executed. This can have many causes: bad CPU, bad RAMs, bad ROMs, bad TTL in between them, broken traces... I first dumped the program ROMs and my programmer reported the one @ 8S to have loose connections:


I burnt a new one in a W27C512 (EEPROM version of the UVPROM 27C512) to keep the board looking as close as possible as original (I find it most ugly to have only one ceramic ROM in the middle of plastic mask ROMs). This changed nothing...
It was time to probe the evil Fujitsu chips. I found a LS244 @ 6L on top board with floating outputs. I fitted a good one and... Game died completely: no RGB signals, no sync... Probing the edge connector revealed signals were all stuck low. They were going through a LS07 @ 1K (top board). It had all its outputs floating. Again, I fitted a good one and game booted to the RAM/ROM test:


Everything showed OK:


And game played fine:



Except for sound: I fitted a new capacitor (2.2nF) and a new oscillator (640kHz) and things were back to normal.

Game fixed.


1 Nov 2017

System 24 desuicide and floppy conversion to ROMs

An other system from Sega on the table. Before starting working on it I made a search online to know if any decrypted sets were availbale (some games have a suicide battery) or if there was alternatives to floppies. Answers were (as of today) no and no...

I first decrypted all games to get rid of the security chips with suicide battery.
Then I converted floppy based game to ROMs.

Everything was tested fine in MAME (expect high score saving functionality was lost due to the game obviously not being able to write to ROMs) but I wanted to test my work on real hardware.
I spent hours trying to find a game but they seem damn scarce nowadays!

So this is a call I made to anyone who could help me finding a System 24 game, even with a bad floppy or suicided.

Stay tuned for the test on real hardware (as soon as I find a game).