PCB Repair Logs – Page 106

Captain Commando repair log

Nov 052012

This is one from quite a while ago that was forgotten about and I was only reminded of it recently by a a guy asking some questions about the PAL CCPRG I have here.
I got this game in a job lot of CPS1 stuff ages ago. It has the EPROM’s missing and 2 of the graphics maskroms were also missing.
First thing I noticed was the maskroms were in a strange order.
If you look at the MAME source code for the CPS1 driver you will see some comments next to the ROM order.

As the maskrom’s are not JEDEC, I filled the missing sockets with 27c4100 EPROM’s with the correct code.
As for the missing EPROM’s for sound and program ROMs, not including the two 27c4096 ones, the silkscreen said to use 27c301’s. Who am I to argue with that?
I burned all the remaining EPROM’s, modified the C board to run with the suicided code and fired it up.
Nothing!

C board was dead so fitted one from an old Street Fighter 2 CE and got this

I end up with most of the graphics being garbage and no sound.
This took me a while to figure out but in the end I should have ignored the silkscreen as the jumpers on board were set to accept JEDEC program ROM’s. I could have changed the jumper but decided just to burn new sound and program ROM’s instead. Now the sound and graphics were all fine.

I dumped the PAL’s that were on this too.
Fast forward to a few days ago and I get an email telling me the CCPRG PAL doesn’t work. Strange as it works for me. I reburned the GAL and tested but got nothing but a black screen.
Not sure what happened when I originally uploaded the PAL but I uploaded the wrong one. This has now been sorted and fully tested.
Thanks to Robotype for pointing this out to me and persisting with it when I didn’t really believe him.

Street Fighter Zero 2 repair log #2

Aug 192012

I wasn’t originally going to write this up but seeing as though I won’t have much time free in a few weeks I thought I might as well.
So, this game would hang at the Q Sound check at startup. After a quick check I found why.

I straightened the pin and the game now works.

Double Dragon repair log #5

PCB Repair Logs, Repair Logs 1 Response »

Jul 142012

This came up on eBay the other day and thought I may as well have a go at repairing it.
According to the listing it failed its startup tests and the picture showed this too however when I got it, it passed all startup tests no problem.
So, here is what I was getting at first boot up

Picture is upside down and garbage on the screen during game. There is also no music but SFX are present.
I removed and reattached the ribbon cables and that gave me this

The video board on this has been messed with before with some pretty bad soldering and not so great wire links added.

There are a couple of points here that are completely trashed, luckily though these are not used so I can ignore them. I removed the links and remade them which brought the screen the right way round again and fixed some colour issues.

There is now clearly a problem with the sprites, every other line is missing. I recalled that my friend Elgen had the very same issue on his bootleg board so asked him what lines he patched. He sent me some pictures but unfortunately it wasn’t my issue. It did however point me to the correct part of the board.
At location IC84 is a TMM2018 RAM. I noticed when my hand was near this chip, some of the missing lines on screen would appear. Checking the outputs from this RAM revealed some weak signals.

These outputs fed into the 2 chips that Elgen had pointed out to me so that confirmed what I was seeing.
I removed the RAM and replaced it with a 6116 I had which then gave me this

All graphics problems sorted. Now onto the music problem.
Going from previous experience I knew where to look.
The YM2151 is responsible for our nice FM sounds. I could see the inputs pulsing away but the outputs at pins 19,20 and 21 were all stuck high. Replacing this gave me that oh so familiar music.

Job done

Breywood repair log

PCB Repair Logs, Repair Logs 3 Responses »

Jun 082012

This game took me ages to fix and the fault ended up being something strange.

Anyway, the game booted to a frozen screen of garbage.
Checked the voltages, all were fine.
Checked the clock, reset and halt lines on both of the 6809 CPU’s, all were fine.
Pulled the ROM’s and checked them, all were OK.

I probed the work RAM and it looked OK but pulled it anyway just in case. No problem with that so back in it went.
Other than the fact it didn’t work, I couldn’t find anything wrong with operation. All the TTL seemed to be functioning as it should. The only thing that bothered me was the I8751 MCU in the bottom left hand corner. There is no dump of its contents available and the security bit has been set.

I did find on my probing travels that when I probed the DIRECTION pin (pin 1) of a group of 74LS245’s then the intro and music would play through as it should. Although the colours were messed up I could coin it up but the game would not start. This little find sent me on a wild goose chase for a day.

As I couldn’t find anything wrong I decided to draw up some schematics of the CPU’s. Everything seemed to be going where it should. I left it alone for a day after this because I was loosing patience with it.

So, today I started looking into the code with the view of writing some test code. The hardware is actually very easy to work with and had no problems doing some tests.
It seems the sub CPU actually does most of the work at startup. Here is what it performs:
1. Shared RAM clearing
2. VRAM clearing
3. BG data clearing
4. Sprite RAM clearing
5. Copies the Hi Score data into RAM
6. Sends the region information to the i8751 MCU
7. Stores data 0x01 into address $6 in RAM
8. Sends interrupt to main CPU

After step 8, the sub CPU continually monitors address $6 in a loop. When the main CPU sets this to 0x00 then the sub CPU will continue.
On to the main CPU then. The only thing that this does before restarting the sub CPU is set the palette RAM. Once this is done the game should start up.

I edited the sub CPU code so that it wrote 0x5050 to all the VRAM. This should will the screen with the letter “P”.
I also made the background into something to prove the BG data could be written.

In MAME I got this

On the real hardware I got this

Ignoring the colour difference I was happy with that result.

Next step was to bypass the need for the sub CPU to monitor address $6. Doing that should allow me to run the intro sequence without the main CPU fitted.
This would prove that the sub CPU is all working fine and the reason the game didn’t run was down to the main CPU playing up.

I wrote the new ROM and tested.

The intro now ran. The colours were messed up but that’s to be expected as the main CPU sets up the palette RAM and that’s been bypassed.
As the main CPU doesn’t really do a lot before the game is meant to run I came to the conclusion that it wasn’t writing address $6 with 0x00.

To cut a long story short, out of desperation I burned another program ROM for the main CPU.

All working. Despite the fact I could read the original ROM out, the hardware wasn’t happy with it.
Crazy fault nearly drove me mental

1943 repair log

PCB Repair Logs, Repair Logs Comments Off

May 312012

Got a few boards today.
One of them is an original Capcom 1943 board.

Game had no sound at all.
After a quick look over the problem became apparent.

The EPROM for the sound was missing its GND leg. I replaced this with a 27c512 (data doubled up) for now as I seem to be out of 27c256 EPROM’s.
Game is fully working now.

Older Entries Newer Entries