28 Dec 2017

Chelnov/Atomic Runner - Data East 1988 (repair log)

Some repairers have what they call a "too hard to repair" pile. I don't understand this concept, to me boards are either repairable or not.
Not repairable means a custom chip is faulty (so far I've always found a solution to circumvent faulty security chips).
Instead I have a "too long to repair" pile. In this pile you find boards I know I can repair but requiring a lot of time.
This Chelnov board was one of them.



First I swapped all the ROMs, PROMs and security chip on a Karnov board to confirm they were ok. Test was sucessful (meaning all ROMs, PROMs and security chip were good).

Then I started to repair the bottom board as it contains the only custom chip of the boardset, possibly being a repair killer.
The game was victim of the Fujitsu plague: I removed and replaced all Fujitsu TTL chips of the bottom board (only 5 of them) and then tested the board with the Karnov top board: it was now fully working.

This is where I left the repair for one year and a half. At this point I knew I could fix the board as all the ROMs, PROMs and security chip were tested OK, so as the only custom chip on the bottom board. I was left with a top board heavily populated with Fujitsu TTL chips and by probing few of them I could tell the damage was extensive...

When I got back to it I moved on the top board with the same treatment: I pulled all the Fujitsu TTL chips (probably 80+).
This took me several hours... (remember "too long to repair").
Out of curiosity I tested them on my programmer and 52 turned out to be bad...

Ok, after that game was still dead, showing only a garbage screen.
I found reset signal of the main CPU was too low to be considered as being a high level (below 3V): 68k was faulty and probably partially grounding/dragging down the signal.
I installed a new 68k, reset signal was now healthy but behaviour of the game didn't changed.

So I started to probe the data signal of the main CPU and found there was activity only for a fraction of second after power up.
To me this was a problem with code execution. All the TTL on buses were new now so I checked traces between the program ROMs and RAMs but they were all OK.
Last probable culprits in line were the work RAMs, unfortunately activity didn't last long enough to see anything on my old analog scope.
So I pulled them and both revealed bad on my programmer. Once replaced the game booted!



With sound, controls, texts and background but sprites were totally absent.
Probing TTL chips I found the outputs of the only 7425 (Texas Instruments) on the board were floating: sure enough it was bad.
I replaced it and finally obtained a fully working game.


Game fixed.


- 1 * CPU 68000
- 2 * work RAMs (6264 type)
- 1 * LS08 (Fujitsu)
- 2 * LS10 (Fujitsu)
- 1 * LS30 (Fujitsu)
- 3 * LS32 (Fujitsu)
- 6 * LS74 (Fujitsu)
- 1 * LS125 (Fujitsu)
- 1 * LS138 (Fujitsu)
- 9 * LS153 (Fujitsu)
- 7 * LS157 (Fujitsu)
- 1 * LS174 (Fujitsu)
- 3 * LS194 (Fujitsu)
- 11 * LS245 (Fujitsu)
- 4 * LS283 (Fujitsu)
- 2 * LS374 (Fujitsu)
- 1 * 7425 (Texas Instruments)

20 Dec 2017

Samurai Shodown RPG (Neo Geo CD) - English translation

This is a project I've started few years ago but never completed, I've sunk so many hours in it...
If I remember correctly scenario 1 is fully translated for all characters.
I estimate at least 100h are still needed to release a beta version with both scenarios translated. Then more time will be needed to fix bugs, typos, funny spacings, etc.

Download link (audio files not included):





13 Dec 2017

Sega Master System 2 (repair)

This console was given to me as faulty.
It wasn't doing anything (balck screen, no sound).
I opened it and was greeted by a sticker with hearts on it, someone weird had opened the console before and left a mark.


First thing I did was to check the voltage regulator: 5V, fine.
Then I started to probe signals on the CPU, work RAM, and BIOS ROM: pin 22 (signal /EXTM2 which I consider being equivalent to /CE) was floating on the BIOS ROM.
According to the schematics it's generated by the custom chip IC5 on pin 12 and is also connected to pin 11 of the cartridge connector:



Connection between IC5 and the cartidge port was fine however the one from the cartridge port to the BIOS ROM wasn't. I patched it with a piece of kynar wire :


And tested the in-built game :


And a catridge game :


Console fixed.

6 Dec 2017

Sega Mark III - Sega Sports Pad game hack


An other Sega oddity. As far as I know only 3 games were developed to make use of the Sega Sports Pad which is a kind of trackball device. Again, it's impossible to play them with a standard pad.
I've made a hack for Great Ice Hockey to be able to play with standard controllers (supports both players).


Great Ice Hockey:


Download link:



Cheksum has been fixed so the game runs fine on a US/EUR console (if someone ever wants to make a cartmod).


Technical part:
Horizontal speed for player 1 is stored in RAM @ $C018
Vertical speed for player 1 is stored in RAM @ $C019
Horizontal speed for player 2 is stored in RAM @ $C01A
Vertical speed for player 2 is stored in RAM @ $C01B

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).

25 Oct 2017

Beast Busters - SNK 1989 (repair log)

A very good game, the last one SNK made before the launch of the Neo Geo. Hardware has a lot of similarities with its successor: 68k for main CPU, Z80 + YM2610 for audio, etc. Even the test menu looks like the one of MVS slots.

1) Getting the game to boot

After a first inspection I noticed someone previously worked on the board as two program ROMs have been replaced. Also one of the ribbon cables connecting the top board and the bottom board (there's a middle board too so a total of 3) was missing. I made one with old parts I had in my stock:


Then I powered the board and it got stuck on a PROGRAM ROM ERROR.


2) Fixing the program ROM error

Looking carefully at the two program ROMs that have been replaced I discovered they were 27C010 type (JEDEC) when the board needs 27C301 type (non-JEDEC). Out of curiosity I dumped them and they contained the right data. Only pinout was the matter. I burnt two fresh 27C100 ROMs (27C301 compatible pinout) and tried to boot the game again. This time self-test reported everything good:


But then got stuck on a black screen: this is typical of a failed gun calibration or corrupted calibration data.

3) Gun calibration

I followed the procedure that has been added at the end of the manual you can find online.


If you don't have the original positional guns you can hack a joystick.
For each player there's a 6 pin JST NH connector with the following pinout:
1 = GND
2 = X DATA
3 = +5V
4 = GND
5 = Y DATA
6 = +5V
Original potentiometers are 5k so depending of the ones in the joystick you plan to use it may not work.
Gun coordinates depend of the voltage on pins 2 (X DATA) & 5 (Y DATA) :
0V = most left/up
2.5V = middle/centre
5V = most right/bottom
An other solution is to desolder the 28C04 EEPROM located @ K7 on the top board and burn the file named bbusters-eeprom.bin included in the MAME romset on it.
After doing a proper calibration game booted:


But... Some sprites had jailbars over them and sound was crackling.



4) Fixing the sprite issue

With the help of the test menu I learned only "FONT 1" sprites (probably a misspelling of FRONT 1 by opposition to background) were affected.
The game shows 4 sprites in a loop, each being stored in a different ROM. So problem was probably downward in the video processing as it seemed unlikely the 4 ROMS were bad with the same jailbars.



According to MAME those sprites are stored in ROMs 11, 12, 13 and 14. They are located on the middle board so I looked carefully at it for broken traces when I noticed a factory defect: RAM @ C14 had its pin 15 not soldered at all. It was probably not a problem when board was new but with oxidisation and dust accumulated over the years connection became poor.



I resoldered it and sprites were restored:



5) Fixing the sound issue

Continuing playing with MAME I was able to reproduce the exact same crackling sound by blanking the sample ROM @ L5. However by using the sound test menu I discovered some samples/tunes were played perfectly while others were totally crappy, and after probing both PCM samples ROMs it revealed sound was perfect when accessing only to the PCM A ROM @ L5. So I burnt a replacement for the PCM B ROM @ L3 in a 27C400 EPROM and tried to piggyback it: that fixed the problem!
I dumped the faulty ROM and compared its content with the MAME file:


As you can see bit 8 is stuck low.

Game fixed.