May 032019

A while back I got my hands on a cheap CPS1 set for Street Fighter 2 CE. The reason it was cheap was that the A board was not working. As we know by now, these A boards are dying quite fast and in some cases the culprit is the Custom CPS-A-01 chip for which there are no know replacements as of yet.

Let’s have a look at what we get on screen first

So it seems we’re only getting half the lines in the sprites and , while it’s not visible on a screenshot, the other half is flickering slowly too.

Looking at the schematics we can see the two parallel banks of rams processing each odd/even lines of sprites. These are coming straight out of the CPS-A-01 GPU IC. Let’s check out the DT/OE enable lines or the rams first.

Looking at them in with the scope reveals a couple of issues:

The bottom one is pin 21, and it’s not really toggling apart from that one regular jump, while we can see that the other line is toggling all the time. This is why we’re only seeing half of the sprites: one bank is not being enabled.

The other issue is this jump on both lines which is most likely why the entire sprites flicker regularly.
These are coming from Pin 21 and 47 of the cpsA .
bank A pin 21
bank B pin 47

Tying the enable line of bank B to bank A will restore the sprites but we still have the issue of the flickering sprites… in a nutshell, the CPS-A chip is fried and this A board is toast.

Luckily a viewer of the youtube channel (thanks Kris Ankers!) sent me a spare A & B board.

The board is in unknown working state . Checking the few remaining proms it’s another SF2 CE , not that it makes much difference here as we’re only interested in the A board. Let’s replace the A board on my other stack and fire this up

…nothing. board is dead.
A quick visual inspection reveals a few corroded badly corroded sockets on the BUF1 and ROM1 pals. corroded is an understatement here too since the socket were missing legs that had completely disintegrated.

Let’s put new sockets in place and see what we get.

Still no boot. I took both pals from my other set and dropped them in.
After some more swapping I found that the Rom1 pal is working so it was just the BUF1 pal that needed to be replaced.

Success!! The board is now booting and playable. Sound is also working fine.

But it seems we’re missing the red color.

A look at the schematics tells me me which ICs are handling the rgb output. We’ve got two rams outputting to 2 LS273 flip flops. This is then sent through ls07 and ls367 buffers, through resistor arrays before being output to rgb.

The difficulty here is that apart from the legs of the rams and resistor arrays which can be probed from the underside, the other ICs are SMD and hidden by the b board so I am not able to probe the legs. Time for some logical guess work :

Since the pairs of ls07 and ls367 are shared across the colors it’s unlikely one of those has failed or it would affect more than one color (still possible but unlikely)
Two resistor arrays are needed per color. If one had failed, we’d get some red at least but here it’s all gone and while it’s possible, it’s unlikely two are gone
So I’m first going to look at the RAM at 1C and the 273 at 4C
Probing the RAM seemed ok so I decided to remove 4C and replace it.


Behold a working (for now) Street Fighter 2 CE CPS1 stack. It’s a bittersweet victory though as there’s no telling when that CPSA chip will fail (not if but when) . But for now I’m going to enjoy some Capcom fighting. Thanks Kris for the PCB donation !

And for those who prefer the video format…

Last Duel repair log

 PCB Repair Logs, Repair Logs  Comments Off on Last Duel repair log
Jan 272019

Bought this game for personal collection but despite having declared working it had some graphic faults.

In particular the intro had blockly graphics and generally lacked shade of colours. The gameplay was in general fine at least for the first two levels.

I started to check maskroms and found LD13 and LD15 which handled the tiles of the intro. Maskroms were tested good on the programmer.

Data pins went to a 86s100 custom chip which usually is not very reliable ( see bottom right of the pic below)

At this point I decided to put a socket and change it with another one I took years ago from Poker Ladies.

Unfortunately the defect was still there but after another look underneath the board and I saw some borken traces which connected the custom to a 74ls273.

There were 3 traces severed but still the graphics were not fixed at all without a sign of improvement.

At this point I started to probe all the other ttl of the video board until I noticed a floating data pin of a 74ls273 which led again to the custom.

The trace interrupted at some point but I could not see any visible scratch until I noticed it near a silscreened text H1, not easy to find at all

After repairing this track the game was fully restored

Black Tiger repair log #2

 PCB Repair Logs  Comments Off on Black Tiger repair log #2
Apr 142018

Got a Black Tiger for a repair which had a colour problem on some graphics

It lacked some shades of colour

I decided to look around the palette rams @6C and 6D until I found a fixed address line

Tracing back I found an 74ls157 @5D with an output stuck low.

After checking the inputs I found one of them stuck low and according to its truth table, the output is always low.

Tracing back I found a 74ls273 witth Q3 output low and D3 input oscillating.

Piggybacking a good one restored the correct colours.

After changing it , the game was completely fixed


Black Tiger repair log #1

 General, PCB Repair Logs, Repair Logs  Comments Off on Black Tiger repair log #1
May 052017

A friend of mine sent this pcb to check why the background was all messed up

I immediately noticed  in demo mode that all the characters fell down in an endless loop because they couldn’t walk on the platforms

After searching for the fault in the video board for some days, I decided to test all roms starting from the program ones.

Program rom 04 didn’t match with anything in Mame and after checking the pattern I saw it was full of garbage.


After reprogramming with a good dump, the game was restored perfectly.

It seems rom 04 has only the layout of all levels because even without its presence the game is booting


Apr 232016

The game booted perfectly but was missing some parts of graphics , road and cars





Upon closer inspection, there was a missing bprom in position 14k.



Since I had a working Mad Gear, I borrowed the bprom and installed on the faulty Mad Gear just to see if the chip was taken away because the game had other problems.

To my surprise, with the bprom in place, the game was perfectly working with all graphics in place.

It could have  been an easy repair but bproms are discontinued since 30 years and nowadays they are nearly impossible to find empty: they are otp chips so once programmed they cannot be erased!

In any case I did a research on ebay and there was no one selling the same kind of bprom needed for Mad Gear which is a 82s129 (equal to 6301 or 7052, depending on the manufacturer).

Next step was to find a way to reproduce it.

Bproms have small capacity but they have a fast access time (less than 50ns) and for that reason they are used often for decoding graphics.

Some OTP roms, such as 27256 or 27512 , have fast access times and can be used in place of bproms by just burning the binary file into them but the problem is that you have to build an adapter because the pinout is different and also the size of the chip itself is much bigger.

The other solution , more elegant and less invasive , is to reproduce the content of the Bprom into a GAL (Generic array logic). This has been done before by other people to reproduce some bproms but they had programming skills which I don’t have.

My friend Caius some months ago pointed me to a blog of a guy who programmed an alternate software for the TOP2005 chinese programmer which had also the ability to produce equations for a GAL out of a  bprom file.

Turned out that this was exactly what I had been looking for!

So first of all I would like to give full credit for this wonderful program to the guy who goes by the name of Elgen.

His blog is:

Facebook page:

Most important the software to convert bprom to GAL equations can be downloaded from here:

Now back to the problem: my wish was to reproduce the bprom into a gal without building an adapter.

So I ran Elgen program on the bprom file taken from Mame which produced the GAL equations.

I then started the program WINCUPL by Atmel (can be downloaded free from here: ) in order to produce the JED file (fuses list) out of the PLD equations (source code)  so that a programmer could burn the GAL chip.

On the WINCUPL program I declared the inputs (addresses) and outputs (datas) in the same pinout standard of the original bprom chip so that I could avoid bulding an adapter:


We don’t have to worry about CE1 and 2 because normally they are tied to GND

After copying and past the equations produced by Elgen program into the PLD project of WINCUPL and minimizing the equations using Expresso algorithm I got this:


Since the equations were not complex in this case, I could use the smaller 20 pins GAL chip, a 16V8 instead of the bigger 24 pins 22V10.

You can see that the GAL file used only 2 data lines instead of the 4 of the bprom file.

At this time you can notice that the BPROM chip is only 16 pins while the GAL 16V8 is 20 pins.

After compiling succesfully I got my JED file to be used in a common programmer supporting PLD files:



With the way I declared inputs and outputs, I could install the GAL chip on the socket, leaving out 4 bottom pins.

In order to power it, I only needed to solder a jump wire from pin 10 to pin 8 for the GND! Very easy and less invasive!




Now the smoke test:





Game fully restored!

Again I would like to thanks Elgen, without his program I couldn’t repair this game, but more over, it’s a very important tool for everyone who has missing or broken Bproms because they are really near impossible to find empty nowadays