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

18 Oct 2017

Conversions/Desuicide on Sega System 32 hardware - SegaSonic & Dark Edge (& more)

1) SegaSonic


It all started when i saw a conversion of Sega Sonic for sale for big $ on a french forum (seller asked 500€ for it). It seemed a lot of money to me for a conversion so I decided to have a look at the protection, expecting something terribly complicated, hence the price. It was not...

Using MAME I could see game stopped (actually MAME crashes) when starting a new game if protection was disabled (function sonic_level_load_protection commented in file segas32.cpp).
According to MAME driver game read/writes to the protection chip from/at 0x20E5C4 & 0x20E5C5

void segas32_state::init_sonic(void)
{
 segas32_common_init();
 /* install protection handlers */
 m_maincpu->space(AS_PROGRAM).install_write_handler(0x20E5C4, 0x20E5C5, write16_delegate(FUNC(segas32_state::sonic_level_load_protection),this));
}

I set a watchpoint when reading/writing to these addresses: wpset 0x20E5C4,2,rw

First stop was @ 0x006F3:

0006F3: mov.h   R0, 65C4[R25]
0006F8: mov.b   #6, 65D3[R25]
0006FE: mov.w   #0, 7050[R25]

This is where I inserted a call to a first subroutine to simulate the protection:

0006F3: jsr     1F600
0006F9: nop
0006FA: nop
0006FB: nop
0006FC: nop
0006FD: nop
0006FE: mov.w   #0, 7050[R25]

There's plenty of space at the end of ROM IC17.

Second stop was @ 0x00764

000764: inc.h   65C4[R25]
000768: cmp.b   #E, 65C4[R25]
00076E: ble     776
000770: mov.b   #E, 65C4[R25]
000776: test.b  70E8[R25]
00077A: bn      77F
00077C: bsr     1CF1

I inserted a call to a second subroutine there:

000764: jsr     1F700
00076A: nop
00076B: nop
00076C: nop
00076D: nop
00076E: nop
00076F: nop
000770: nop
000771: nop
000772: nop
000773: nop
000774: nop
000775: nop
000776: test.b  70E8[R25]
00077A: bn      77F
00077C: bsr     1CF1

First subroutine consists only in writing the expected value to the correct address and copies the move instruction I've noped caused the call to the subroutine needed 6 bytes when the original instruction needed 5 (therefore I've overwritten the first byte of the following instruction). Then it returns:

01F600: mov.h   7500[R25], 706E[R25]
01F608: mov.b   #6, 65D3[R25]
01F60E: rsr

Second subroutine copies overwritten instructions first then writes the expected value to the correct address before returning:

01F700: inc.h   65C4[R25]
01F704: cmp.b   #E, 65C4[R25]
01F70A: ble     1F712
01F70C: mov.b   #E, 65C4[R25]
01F712: movz.hw 65C4[R25], R0
01F717: mov.h   7500[R25](R0), 706E[R25]
01F720: mov.w   #0, 70BC[R25]
01F726: rsr





Finally I edited checksum of ROM IC17 which is stored @ 0x1F08C in ROM IC8 (changed to 0x74CC).




2) Dark Edge


Not that I'm a big fan of this game but I did it for an old acquaintance which owned a suicided copy.

I used the same method, setting watchpoints where reading/writing to the security chip (wpset 20F072,2,rw / wpset 20F082,2,rw / wpset 20a12c,2,rw / wpset 20a12e,2,rw):

void segas32_state::darkedge_fd1149_vblank()
{
 address_space &space = m_maincpu->space(AS_PROGRAM);
 space.write_word(0x20f072, 0);
 space.write_word(0x20f082, 0);
 if( space.read_byte(0x20a12c) != 0 )
 {
  space.write_byte(0x20a12c, space.read_byte(0x20a12c)-1 );
  if( space.read_byte(0x20a12c) == 0 )
   space.write_byte(0x20a12e, 1);
 }
}
WRITE16_MEMBER(segas32_state::darkedge_protection_w)
{
 logerror("%06x:darkedge_prot_w(%06X) = %04X & %04X\n",
  space.device().safe_pc(), 0xa00000 + 2*offset, data, mem_mask);
}

READ16_MEMBER(segas32_state::darkedge_protection_r)
{
 logerror("%06x:darkedge_prot_r(%06X) & %04X\n",
  space.device().safe_pc(), 0xa00000 + 2*offset, mem_mask);
 return 0xffff;
}

First protection caused missing flame effect before title screen:

01E2C2: test.h  7072[R25]
01E2C6: bne     1E2FD
01E2C8: test.b  206C[R25]

Replaced by:

01E2C2: test.h  7072[R25]
01E2C6: nop
01E2C7: nop
01E2C8: test.b  206C[R25]

Second protection caused a black screen when starting a new game however sound and controls were still working (game played blind):

01F716: test.h  7082[R25]
01F71A: be      1F74D

Replaced by:

01F716: test.h  7082[R25]
01F71A: br      1F74D

Third protection caused bad sprite scaling:

01F74A: sub.h   R0, R14
01F74D: add.h   7082[R25], R14
01F752: movs.hw R13, R13

Replaced by:

01F74A: sub.h   R0, R14
01F74D: nop
01F74E: nop
01F74F: nop
01F750: nop
01F751: nop
01F752: movs.hw R13, R13

[EDIT 2017/10/19]
Found an other protection where game would just hang when starting a 2 player mode:

005AF0: mov.h   #82, 212C[R25]
005AF8: mov.b   #0, 212E[R25]


Replaced by:


005AF0: mov.h   #0, 212C[R25]
005AF8: mov.b   #1, 212E[R25]







Now the last thing to do was to correct the cheksum for the ROM IC8 to pass the memory test.
It's stored in ROM @ 0x7F08C, I simply edited the value to 0x0F43 new value = 0x5BD5.




Patched files for sale, contact apocalypse-mods@outlook.co.nz


Also available:
- Golden Axe 2
- DBZ V.R.V.S.
- F1 Super Lap
- Air Rescue
- Burning Rival
- Arabian Fight
- The J.League 94 [EDIT]2017/10/25




[EDIT]
Golden Axe 2 can be downloaded for free here:
http://www.arcade-projects.com/forums/index.php?thread/2656-released-golden-axe-2-desuicide/

So as SegaSonic here:
http://members.iinet.net.au/~lantra9jp1_nbn/gurudumps/s32convert.html

I do not guarantee those files are bug free and won't provide any support for them as they were patched by other people.




11 Oct 2017

Conversion SF2' to Final Fight (CPS1)



An other CPS1 conversion. This is the US version of the game.


1) Material needed

1.1) If you use a 91634B-2 B-board (EPROM)
- 6 * 27C4096 ROM (4 for the graphics and 2 for the program)
- 1 * 27C010 ROM (audio)
- 1 * 27C512 ROM (audio)
- 1 * GAL16V8 (PAL)

1.2) If you use a 91635B-2 B-board (mask ROM)
- 4 * 27C400 ROM (graphics)
- 2 * 27C4096 ROM (program)
- 1 * 27C010 ROM (audio)
- 1 * 27C010 ROM (audio)
- 1 * GAL16V8 (PAL)

2) ROMs and PAL burning

Now it's time to burn the files on the appropriated devices.

2.1) If you use a 91634B-2 B-board (EPROM)
- ROMs 01/02/03/04//22/23 => 27C4096
- ROM 09 => 27C512
- ROM 18 => 27C010
- FF_PAL_1A.jed => GAL16V8

2.2) If you use a 91635B-2 B-board (mask ROM)
- ROMs 01/02/03/04 => 27C400
- ROMs 22/23 => 27C4096
- ROM 09 => 27C512
- ROM 18 => 27C010
- FF_PAL_1A.jed => GAL16V8

3) ROMs installation

All SF2' ROMs must be removed from the B-board.
The PAL named S963B at position 1A has to be removed too.
Double check you've put the devices the right way (the silkscreen should help you)!

3.1) If you use a 91634B-2 B-board (EPROM)
- Install the ROMs in the corresponding socket (ROM 01 in socket 01, etc.)
- Install the GAL16V8 in position 1A (where the S963B was)

3.2) If you use a 91635B-2 B-board (mask ROM)
- Install the ROMs 01/04/05/08/09/18/22/23 in the corresponding socket (ROM 01 in socket 01, etc.)
- Install ROM 02 in socket 03
- Install ROM 03 in socket 02
- Install the GAL16V8 in position 1A (where the S963B was)

4) Test



Patched files for sale, contact apocalypse-mods@outlook.co.nz

5 Oct 2017

Heated Barrel - TAD 1992 (Repair log)


Game booted but with a dominant green tint (forgot to take a picture) and was silent.
Concerning the colour issue I probed the colour RAMs (2 of them) and the one @ E4 (U096) had weak data signals. Piggybacking it cleared the issue so I replaced it:



For the sound problem I found the audio RAM @ C5 (U118) was dead too altough piggybacking it didn't make any change. This game uses a weird custom chip noted YM3931 (not sure it's linked with the Yamaha brand) for sound. I was sure of it cause it's connected to the audio RAM, the YM3812 and the OKI M6295. Anyway, many of what I thought were outputs were silent. This also isn't normal, the chip is a SDIP64 (shrink DIP with a pitch of 0.07" instead of 0.1" for standard DIP) and very few legs were active. Luckily my friend Kelvin found the chip somewhere online for $8 IIRC:



I replaced it and sound was brought back to normal.



Game fixed.