26 Jul 2017

Conversion SF2' to Carrier Air Wing (CPS1)

Originally the World version of Carrier Air Wing runs on a 89624B-3 B-board and 88622-C-5 C-board.

To use a different B-board, files need to be rearranged (merged, interleaved, ect.) and one of the B-board PALs (CA24B for Carrier Air Wing) must be adapated (handcrafted). This will not be covered by this article as I want to keep it at a reasonnable size (and prevent readers to fall asleep).

To use a different C-board, program ROMs must be modified to use different registers addresses and different layer masks.
I will try to give some useful information on how to proceed.

1) Modifying MAME source and recompiling


Carrier Air Wing originally uses a CPS-B-16 chip on the C-board while SF2' uses a CPS-B-21 chip with no battery.
Everything is detailed in MAME:
Carrier Air Wing (World 901009)                              1990  89624B-3   CA24B            IOB1  88622-C-5    CPS-B-16  DL-0411-10011  None
Street Fighter II': Champion Edition (World 920313)          1992  91635B-2   S9263B   BPRG1   IOB1  92631C-6     CPS-B-21  DL-0921-10014  C632    IOC1
In order to test my work in MAME I've modified the file cps1.cpp located in mame\src\mame\video
I've edited the following line:
{"cawing",      CPS_B_16,     mapper_CA24B },
To:
{"cawing",      CPS_B_21_DEF, mapper_CA24B },
This will force MAME to use the CPS-B-21 chip (no battery hence CPS_B_21_DEF in the line above) instead of CPS-B-16.

To recompile MAME you can follow the instructions on MAME's official website:
http://mamedev.org/tools/

2) Editing registers addresses


Again the needed information can be found in the cps1.cpp file mentionned earlier:
/*                     CPSB ID    multiply protection      unknown      ctrl     priority masks   palctrl    layer enable masks  */
#define CPS_B_16     0x00,0x0406,          __not_applicable__,          0x0c,{0x0a,0x08,0x06,0x04},0x02, {0x10,0x0a,0x0a,0x00,0x00}
#define CPS_B_21_DEF 0x32,  -1,   0x00,0x02,0x04,0x06, 0x08, -1,  -1,   0x26,{0x28,0x2a,0x2c,0x2e},0x30, {0x02,0x04,0x08,0x30,0x30}
The base address for registers is always 0x800140 for all CPS1 games.

So we can calculate the different adresses for a CPS-B16 chip (Carrier Air Wing):
Layer control = 0x800140 + 0x0C = 0x80014C
Priority mask 1 = 0X800140 + 0x0a = 0x80014A
Priority mask 2 = 0X800140 + 0x08 = 0x800148
Priority mask 3 = 0X800140 + 0x06 = 0x800146
Priority mask 4 = 0X800140 + 0x04 = 0x800144
Palette control = 0X800140 + 0x02 = 0x800142

And the same for a CPS-B-21 chip with no battery (SF2'):
Layer control = 0x800140 + 0x26 = 0x800166
Priority mask 1 = 0X800140 + 0x28 = 0x800168
Priority mask 2 = 0X800140 + 0x2A = 0x80016A
Priority mask 3 = 0X800140 + 0x2C = 0x80016C
Priority mask 4 = 0X800140 + 0x2E = 0x80016E
Palette control = 0X800140 + 0x30 = 0x800170

Now in the program ROMs of Carrier Air Wing we will replace address 0x80014A by 0x800166 (layer control). And so on for the priority masks and palette control.

But that's not all, base register 0x800140 is used to read the CPS-B chip ID, which is 0x0406 for a CPS-B-16 and -1 (0xFFFF) for a CPS-B-21.
Carrier Air Wing does read it several times and in different ways (sometimes as a word from 0x800140, sometimes as a byte from 0x800141 etc.).
So each time the game tries to read the ID we will have to make it to believe the chips is a CPS-B-16.
For instance
move.w  $800140.l, D0
will have to be replaced by
move.w #$406, D0 (followed by a NOP instruction as it needs only 4 bytes instead of 6).
For a byte
move.b  $800140.l, D0
can be replaced by
move.b #$4, D0 (first byte of 0x0406)
and
move.b  $800141.l, D0
can be replaced by
move.b #$6, D0 (second byte of 0x0406).

Once done game should boot in MAME but with the wrong layers enabled (as expected).

3) Editing layer masks


An other particularity of CPS-B chips is they used different values to enable layers.
Back to the MAME's source:
/*                     CPSB ID    multiply protection      unknown      ctrl     priority masks   palctrl    layer enable masks  */
#define CPS_B_16     0x00,0x0406,          __not_applicable__,          0x0c,{0x0a,0x08,0x06,0x04},0x02, {0x10,0x0a,0x0a,0x00,0x00}
#define CPS_B_21_DEF 0x32,  -1,   0x00,0x02,0x04,0x06, 0x08, -1,  -1,   0x26,{0x28,0x2a,0x2c,0x2e},0x30, {0x02,0x04,0x08,0x30,0x30}
So for a CPS-B-16 offsets are:
Layer 1 enable = 0x10
Layer 2 enable = 0x0A
Layer 3 enable = 0x0A
Layer 4 enable = 0x00
Layer 5 enable = 0x00
When 2 layers share the same offset it means they are simulteneously activated.
Here we can see layers 2 and 3 are activated together, so as layers 4 and 5.

For a CPS-B-21 offsets are:
Layer 1 enable = 0x02
Layer 2 enable = 0x04
Layer 3 enable = 0x08
Layer 4 enable = 0x30
Layer 5 enable = 0x30

To enable/disable layers, game must write to the layer control register. As seen before this is address 0x80014C for a CPS-B-16 and 0x800166 for a CPS-B-21.
The value must contain a base offset of 0x12C0 (identical for all CPS1 games) then add the desired values.
Example:
to activate only layer 1 with a CPS-B-21 chip, game must write 0x12C0 + 0x02 = 0x12C2 to the register 0x800166.

Using MAME dissasembler with the modified program ROMs I've found Carrier Air Wing accesses the layer control register either directly:
000482: 33FC 12D0 0080 0166        move.w  #$12d0, $800166.l
Or indirectly:
001CDE: 33ED 004A 0080 0166        move.w  ($4a,A5), $800166.l

For the direct access it's quite simple: 0x12D0 for a CPS-B-16 chip corresponds to 0x12FE for a CPS-B-21 chip, so the line
000482: 33FC 12D0 0080 0166        move.w  #$12d0, $800166.l
Is replaced by
000482: 33FC 12FE 0080 0166        move.w  #$12FE, $800166.l

For the indirect access I had to set breakpoints and found the mask value is written to RAM @ 0xFF804A before being written to the layer control register.
So I searched for all the writes to 0xFF804A and modified the values being written according to the different offsets.
Example:
000606: 3B7C 12DA 004A             move.w  #$12da, ($4a,A5)
is replaced by
000606: 3B7C 12FE 004A             move.w  #$12FE, ($4a,A5)

Here are the different values I've found being used and their equivalent for the CPS-B-21 chip:
CPS-B-16 CPS-B-21
0x12DA  0x12FE
0x139A  0x13BE
0x06DA  0x06FE
0x24DA  0x24FE
0x18DA  0x18FE
0x079A  0x07BE

Then I ran the game but found 2 problems:
- incorrect layers enabled during attract
- missing Game Over text (again incorrect layers enabled)

By watching the RAM I could see the wrong value written to RAM @ 0xFF804A during attract was 0x12DA so I set a conditionnal breakpoint in the MAME debugger:
wpset FF804A,1,w,wpdata==12DA
This informed me the game sometimes uses the layer control offset as a mask:
000F3C: 006D 001A 004A             ori.w   #$1a, ($4a,A5)
Here the value used is 0x1A (all layers enabled for a CPS-B-16) which corresponds the 0x3E for a CPS-B-21 chip.
I replaced the line as follow
ori.w   #$3E, ($4a,A5)
and now attract was correct.
I followed the same procedure for the missing Game Over text (value 0x12D0 written).
This time value 0x10 was used (layers 1, 4 and 5):
001234: 006D 0010 004A             ori.w   #$10, ($4a,A5)
Which I replaced by
ori.w   #$32, ($4a,A5)
And game was finally working perfectly!

4) Material needed


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

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


5) ROMs and PAL burning


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

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

5.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/19 => 27C010
 - CAW_PAL_1A => GAL16V8


6) 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)!

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

6.2) If you use a 91635B-2 B-board (mask ROM)
 - Install the ROMs 01/04/18/19/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)


7) Test









19 Jul 2017

Rally Bike - Taito 1988 (repair log)

Inputs weren't working and game throwed a tilt error when entering in attract mode and just after rebooted:

 

This could have been a terribly difficult repair. Why? Cause on this harware inputs are handled by the sound CPU (Z80). Normally you wouldn't see the link between them. Luckily Caius form JAMMARCADE made a post about this. So I started with the basics in the sound section, I probed the audio RAM and found data signals weren't much healthy. I piggybacked the RAM and game didn't throw the tilt error anymore. After replacing it game worked perfectly:



Game fixed.
Big thank to Caius.

12 Jul 2017

Conversion SF2' to Strider and first donator!

First I'd like to thank my first donator: Daniel Ladner.
Your support is much appreciated.
To show my thankfulness here is the Strider conversion you were expecting.
Enjoy !

1) Material needed

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

1.2) If you use a 91635B-2 B-board (mask ROM)
 - 8 * 27C400 ROM (graphics)
 - 2 * 27C4096 ROM (program)
 - 2 * 27C010 ROM (audio)
 - 1 * 27C512 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/05/06/07/08/22/23 => 27C4096
 - ROM 09 => 27C512
 - ROM 18/19 => 27C010
 - STH63B.jed => GAL16V8

2.2) If you use a 91635B-2 B-board (mask ROM)
 - ROMs 01/02/03/04/05/06/07/08 => 27C400
 - ROMs 22/23 => 27C4096
 - ROM 09 => 27C512
 - ROM 18/19 => 27C010
 - STH63B.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/19/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 ROM 06 in socket 07
 - Install ROM 07 in socket 06
 - Install the GAL16V8 in position 1A (where the S963B was)

4) Test






5 Jul 2017

Tatakai no Banka/Trojan - Capcom 1986 (repair log)

This game is part of a lot of games from Hell I repaired few months ago. Those games had so many faults I wonder what caused them... I would go for bad powering (over voltage).

So this the Japanese version of Trojan known under the name of Tatakai no Banka. It's made of two boards with hidden traces under a copper layer on both sides covering the whole board. Schematics are of course not available. It took me hours to figure out which signal was connected where...

1) First inspection, first hope, first fail...

As usual I spent some time to inspect the board for damaged chips, etc. I found someone previously worked on the top board and that the work RAM (6264 type wide) and the LS04 next to it (used as a crystal driver) have been put on sockets and replaced. I tested both and found out the RAM was fried (weird as I could see it wasn't a pulled part but a new one). I replaced it. I also noted that one of the flat cables between the two boards had wires severed. I fixed it too.
Ok that could definitely explain why the board has been given to me as faulty, I already found and solved two issues. I dug out my Capcom classic adapter and powered the board, full of confidence, only to be greatly disappointed by a black screen with no sound...

2) Fujitsu plague, as often

Ok that was disappointing but not enough to discourage me. The inspection of the board made earlier showed me there was some Fujitsu chips peppered on both boards. I probed them all and found bad:
- 4 * LS86 @ 3J/4J/5J/9K on top board
- 1 * LS32 @ 1E on bottom board
New hope, new fail... Black screen no sound.

3) Texas Instrument and Mitsubishi are partying too

Well, this time I dumped all the ROMs (25 of them!) but they were identical to the MAME romset.
Back to the basics. I probe the vital signals on the main CPU (Z80) and main RAM and found /CE signal was stuck high on the latter. This is where the hide and seek game begins. Traces being hidden I tested continuity of every single leg of every single chip on the top board and discovered the signal was coming from a LS139 @ 12F (Texas Instrument this time). I replaced it and tested the game: black screen with no sound...
I continued my investigation and found ROM TB01 had also its /CE signal stuck high. An other LS139 @ 7C was fried. At this point I thought it would be wise to test the 2 remaining LS139 of the board: the one @ 10D was dead. I replaced the 3 (out of 4) faulty ones and...Black screen with no sound...
I then moved on the data bus signals: some were weird. Found a faulty LS273 @ 10B. I replaced it and this time game booted with corrupted graphics and music was absent.
Ok this wasn't a victory yet but after all things had improved.

4) Fixing graphic glitches... And an other annoying fault

I jumped on my camera but before I could take a picture game died... Well not really. In fact it worked for 10 seconds and then stopped to a black screen with no sound. If you let it cool down it would work for an other 10 seconds. I first continued my investigation on the graphic problems: buildings were cut in half horizontally. An other Fujitsu chip had died during the repair, replacing the LS157 @ 12D on the bottom board cleared the problem.
Now I was left with a screen covered of spots:


The LS273 @ 9H on the top board was faulty. Graphics were finally correct:



Before a minute later text layer went crazy:


The LS273 @ 9F on the top board had decided to die during the repair too. I replaced it which restored the texts:



Now the annoying hanging issue: if I turned down the PSU to 4.5V game would play forever. Not an easy fault to troubleshoot. I didn't find any abnormally hot chip. So I started to piggyback every chip not related to graphics or sound. I found a faulty LS161 @ 1L on top board.

5) Fixing the sound and some new appearing faults

I started to probe the sound section and... Game died again: black screen no sound... Found a dead LS74 (Mitsubishi) @ 6J on top board.
Ok back to probing and... Guess what? Game died! Found a dead L157 (Mitsubishi) @ 5M on top board.
Self control, deep breathe. Back to the repair.
So music was absent and probing one of the two YM2203 revealed it had no ouputs. I replaced it but heard no improvement. However with the help of an audio probe I could now hear the music (distorted) on its outputs. So the fault was in the later stages of audio processing. I probed the two DACs (YM3014) and both had no signal on their output. I replaced both and music was fully back.
Game fixed! Game Fixed!

NOT!

Now the title screen was corrupted:


ROM TB23 on the bottom board kicked in the bucket.




I burnt a new one in a plastic EEPROM to keep the clean and tidy look of the board.

Game fixed.

Family portrait:


- 1 * YM2203
- 1 * 6264 RAM
- 1 * 24256 mask ROM
- 3 * LS273
- 3 * LS139
- 2 * LS157
- 1 * LS161
- 4 * LS86
- 1 * LS74
- 1 * LS32
- 2 * YM3014