Golden Axe Repair Logs

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Repairer: channelmaniac

Symptom: Garbled/Missing Background Graphics

Swapped out the broken socket on IC21 with spare socket from empty IC23. Reset jumpers S1-S6 for proper ROM types on daughter board. Fixed a bent pin on the custom encrypted CPU to finish the repair.

Symptom: Graphic corruption

Game had garbled graphics that would get better if the ROMs on the daughterboard were reseated, then come back later. Resoldered IC3 on the bottom of the daughterboard and tested.

Board 1

Repairer: Womble
Forum Thread: Golden Axe PCB Repair

Got hold of a box of faulty boards lately, was expecting 2 boards but got 3, the third was a rather battered and sad looking Golden Axe.

Didn't hold out much hope for it as it had a number of signs of a hard life. Most obviously was a couple of ridiculously long wires soldered to the underside to repair damage.

The underside of the board was peppered with scratch marks..

...and one corner of the main board had been snapped clean off.

On the solder side the tracks were not near the damage but on the parts side it was a different story, more on that later.

Someone had also removed one of the RAM chips, neatly done but they didn't have enough of a grunty soldering iron to get the ground pin to come free as that was still in the hole and had been chopped off.

Also every single smoothing capacitor had been wrenched off the ROM board, leaving just the legs and the inner plates of each one on the board.

And finally a large number of pins in the service socket had been mashed together.

Oh yeh - and it was filthy.

The big black block in this photo is the FD109 decryption CPU block, inside is a modified 68000 CPU, some RAM and a tiny watch battery keeping the RAM alive. The RAM contains a decryption table that untangles the encrypted information stored in the program ROMs, when the battery dies the RAM empties and the CPU gets the encrypted program code direct from the ROMs, without being decrypted this is gibberish to the CPU so the board crashes. I assumed that considering the mess this board was in that the CPU would have suicided - I was wrong. Putting the CPU and the ROM board onto my own System 16 main board gave me a fully working game. Not bad considering that watch battery has been keeping the RAM alive for 21 years now.

Anyway - there was no point powering the board up in its current state, the bent pins risked shorting something out and with only half the system RAM it was never going to work. So I straightened all the pins out in the socket, cleared the remaining solder holes for missing RAM chip and fitted an old dual wipe socket for a 6264 chip. The socket was so I could easily get the chip back as I was not convinced this wasn't a pointless exercise.

I checked against my own board that the long wires soldered to the back of the board were actually needed, that the two endpoints should be joined on a working board and that the link was broken without the wires. You never know what work has been done on a board so its always wise to sanity check someone else's work before applying power.

To rule out any suicide crazyness I also removed the CPU block, installed the 2 decrypted EPROMs and a standard 10MHz 68000 CPU.

After all of that the board booted and ran!!!

Well kinda, it was mostly OK, it was worryingly silent and some of characters were doing odd things, which I put down to the total lack of smoothing caps on the ROM board.

Next step was the sound, that is after starting up a game to confirm the sound was dead and not just disabled by the dip switches when in attract mode (I could have looked up the dip settings but hitting coin-up was quicker and more conclusive).

First port of call was the Z80 CPU controlling the sound system,

I could see a healthy clock signal on the scope when poking at pin 6 and the RESET and HALT pins at 26 and 18 were logic high (i.e. the CPU enabled). Next was to see what the CPU output looked like, pointing a scope at the data lines showed a pretty messy signal.

Not a great sign but its amazing what crappy signals can still make perfect sense to the rest of the system when taken in terms of transitions between logic 0 and logic 1. Went on to poke the scope at the address lines and here the issue was very obvious, address lines A7, A8 and A9 were silent and low, yet lines A0-A6 and A10-A15 were active and looked good, either the CPU was totally shot or the address lines were tied somewhere else. The CPU was socketed so easy to remove and test, when put into my Galaxians board which has become my Z80 tester it proved that it was dead. I also suspected the RAM was shot too based on the crappy signals on the scope so I desoldered that but it passed the test on my EPROM burner so a socket was fitted and it went back on the board. With a new Z80 the sound system fired up perfectly.

Next fault was the badly behaving characters in the game, in attract mode it wasn't that evident but when playing a game some characters would come back to life, especially the ones on the pink dinosaurs with the whip tails. When you killed the rider another dinosaur with another rider would appear and sit motionless on the screen. It was impossible to kill him or even touch him, all you got when you tried to attack him was an odd sound effect. The game still thought it was a legit character as you cannot complete the level when he has re spawned as the level is not clear. Impossible to show this with photos so I recorded (badly) it for a laugh.

{{#ev:youtube|6-Xrvdq_484}}

I put this down to the lack of the four 470uF electrolytic capacitors that are there to fill in any tiny ripples in the power supply to the ROMs, without them the board was susceptible to every flicker on the power rails so its not surprising the logic of the game was less than stable, am surprised it didn't crash to be honest.

Before getting to the caps I decided to straighten out a few mashed jumpers, a couple had been bent so far over that they just fell off as soon as I touched them.

Only one of the missing pair needed to be joined, the jumpers are there to set up the address and data lines for the specific games set of ROMs, different games on this board use different combinations of ROMs so the jumpers allowed Sega to easily use the same PCB for multiple titles. Rather than faff about trying to find the right size pins to put the jumper back I just bent the leg from an LED into a loop around a screwdriver and soldered it in place,

one jumper permanently jumpered!

I desoldered the remains of the old electrolytic caps and fitted 4 new ones, after which the game oddities vanished.

At this point I thought the game totally fixed, but when I went to give it a full test on my cabinet the graphics went nuts, the sprites were torn up and scattered all over the place.

The fault was ultra sensitive to touch, a light pressure on a number of areas of the board would cause it to come and go. Problems like this are a pain in the rear as it very hard to find where the sensitive area actually is as you get a lot of false positives. I thought I had tracked it down to the strangely socketed custom IC that was not actually fully pressed home.

The socket on the board is original but the chip shows signs of being soldered in so its probably not the original chip from this board.

A removal and reseat of this chip didn't improve the issue, but that area of the board no longer seemed to be involved with the issue. After a lot of trial and error I decided it wasn't really an area of the board at fault, more the orientation of the board, when flat on the floor it was sometimes bad, when upside down so I could poke at the solder side it was usually totally fine. I slowly came to suspect it was caused by the long wires on the underside, these were wedged between the pins at a few locations so I supposed there could be a short, or it could simply be cross talk noise. Taking the flying wires off seemed to fix the fault, I have banged and flex and tweaked the board but its rock solid. However without the wires the board was silent again.

The reason was obvious, the soldered one wires went from one of the ROM board connectors to an LS273 in the sound section. With the meter set to continuity beeper I found that of the 8 data inputs on the 273 only 6 went back to the sound EPROM on the ROM board, a couple of data lines on the 8 bit bus were missing, following the tracks for this set of 8 lines took me round the edge of the board straight to the damaged corner, the two outer tracks on the parts side had gone with the missing corner, the inner 6 tracks had survived.

The leads on the back of the board were never a good idea even if they were not shorting out or causing interference, they are far too likely to get caught on something, if the leads had actually followed the original path of the track then they would be 3 times longer as they went all the way round 3 sides of the board. A neater solution was to fix the issue at the site of the damage, a bit fiddly but the two outer tracks are now taken inland around the damaged area and join up again..

..this will be covered in lacquer ( as will the other scratches) so will be effectively set in concrete, no chance of it getting snagged or shorting out anything.

And that really is about it - the game has now been playing for hours without any issues at all, a bit of a marathon fix but well worth it for a classic.

Board 2

Repairer: Womble
Forum Thread: Golden Axe PCB Repair

This was the other board that came with Shadow Warriors and whereas that board was stored in dry newspaper, this one was wrapped in newspaper that had at some stage got very wet. The whole underside of the board is covered in a white powdery sheen of oxide, there are signs of corrosion on a few chips ...

... and around capacitors, plus number of resistor arrays have their solderside legs rusted away to dust.

The most obvious damage was to the edge connector on the parts side.

The burnt edge connector is not a major issue as the underside tracks are still intact but if left running for long periods the remaining ones may get too hot from drawing the current through a now much smaller area of copper.

However on power up the board did nothing, black screen, no sound, no life. As it still had its original FD1094 CPU block on board it was likely that this had suicided leaving the board unable to run the data in the encrypted program roms. So I removed the CPU block, installed a 10MHz 68000 CPU and replaced the 2 EPROMs with ones containing unencrypted code. To my surprise then board booted with only fairly minor graphics issues, still no sound but at least it ran.

The sprites and some splash screen elements had regular transparent lines through them, and whenever any of them walked into the rightermost third of the screen the colours were wrong too.

Interesting to see that the moving eagles eye is a fixed sprint overlayed on the background.

First task was to see if the fault was on the ROM board or the main board, despite it being in good condition I was half expecting the fault to live there. It looked very much like some data lines were missing from the ROMs containing the sprite data, although these lines do run from the ROM board, into the mainboard and onwards to wherever. Missing outputs are also more commonly seen with mask ROMs, which this board does not have. The fact that was was on the screen was correct suggested that the data bus was intact, any error there means all the output data would be wrong, not just a few slices of it. So I replaced the ROM board with a known good Golden Axe board and the fault remained, the issue was on the motherboard.

I spent a while looking for track damage but found none, aside from the really rusty component legs most of the corrosion was rather superficial and could probably be washed off. The three seriously rusted resistor networks turned out to be where the final RGB signals are assembled, the output of these looked like video channels on the scope and interrupting these changed the colours on the monitor and as the colours are fine these are actually in perfect working order.

Next step was to poke the various RAM chips on the board, System16 games have a test function that does test some of the RAM but such tests are never conclusive. As the ROM board stopped me getting at the chippery when the board is running I had to have the board upside down while going over the SRAM chips looking for crappy output signals but everything looked fine. While I was flipping the board upside down the sound also burst into life a couple of times.

To get any further I had to narrow down which chips were doing what, so I started to short out pairs of data pin to see what happened. Interruption on some SRAMs just locked up the board, some caused what was left of the sprites to be torn up and drawn across the screen, and others were clearly handling the background as it went nuts.

I did find some references in a text file...

| 315-5195 | System 16 hw custom square chip

| 315-5196 | System 16 hw sprite generator

| 315-5197 | System16 hw background/foreground tiles generator

.. that reckoned that the lower right custom would be dealing with the sprites, I had no way to test the custom but I could then check out all the tracks going to the SRAM chips that were associated with it. I spent a while going round the 4 SRAM chips checking that all the data bus lines were connected, which was harder than it sounds as with the oxide on all the pins even ones that were connected were often less than keen to show it.

This was a dead end anyway, everything that I thought should be connected was still connected and there was no damage in the area. All the data and address pins on the SRAMs were healthy looking and the chips were all enabled.

The biggest issue with System16 boards is that without the ROM top they don't do anything, but when the ROM board is in place it obscures half the motherboard which makes chip hopping with the scope on the hunt for something smelly difficult. As I had pretty much run out of options I decided to piggy back some RAM chips on this area. I dug out a Black Tiger board and pinched one of its socketed TMM2018 chips and piggybacked it on the upper most chip of the bank of 4, starting there was a lot of oxide dust around that chip. Put the ROM board back on and fired it up, no change at all. So powered down, pulled the ROM board off, moved the chip down to the 3rd in the stack, reassembled and fired it up again. Initially it looked like there was no change again, but the issues involving the colours on the right hand third of the screen were gone.

So I pulled another TMM2018 from Black Tiger and piggy backed it on the 2nd chip...

...and fired that up (see the water marks around the top chip).

Problem solved, so I desoldered the chips, with some difficulty - system 16 boards have massive 5V and ground planes, getting those pins out is hard work, even with the soldering iron at 450 degrees Celsius. Both failed the tests on my EPROM burner, one with an error suggesting that some address lines were not "in spec", this would make explain why I was not seeing any problems on the address lines or the data lines with the scope. The address lines were being driven correctly and the signals were reaching the chip legs, which is where I was seeing them, they just were not getting into the chip core for some reason, or the core is damaged in that area. Even when data lines are missing the SRAM chip sees that as a logic level, i.e. a 0 or a 1 in the binary pattern for the address, so its still a valid address, and it happily outputs the data it has in that location. The data outbound from the RAM chip is therefore healthy data, but the wrong data, with a scope you can really only see if the data signal looks healthy, not if the patterns are what they should be.

With the graphics fixed the sound problem was next and that turned out to be easy, the scope showed activity in the sound system, Z80 had clock, data and address buses buzzing away normally, even data going into the DACs and analogue audio was coming out, but the amp chip was stone cold, because it wasn't powered up. Due to the burning on the edge connector the 12V pin was badly tarnished, a polish with Br Brasso fixed the issue permanently.

I will tackle the burnt edge connector in a week or so, its possible to cut back to non burnt PCB material, build up the missing depth with epoxy resin (araldite glue), then sand it down and install new copper fingers, there's a good video on how to do that youtube so will give it a go.

I thought that was the end of it, but while test playing the game I would sometimes I would get very slight corruption in some sprites, mostly the axe wielding amazons and the blue dragons...

...similar to the problem before but to a much lesser extent, which was almost certain to be the other chip in the pair. I am pretty sure the 4 chips are two pairs actually, one pair is entirely devoted to sprite data and the other pair is divided between sprite data and colour. As I had sprite issues not colour issues it was probably the 1st chip in the bank of four which is paired with chip 2. So I removed it and dropped in a new chip...

...finally fixed!

Another working System16 for my collection, this probably won't stay a Golden Axe, as all the ROMs on the board are EPROMs rather than mask ROMs, and as the labels are in in a very bad way and probably not even original...

...I think I will turn this board into an Aurail, have a parcel with a load of EPROMs on its way, at least 20 27C1000s so combined with the erased original ones I can kit this out with a game I have never met before, one that really shows off what the platform can do apparently.

I actually wonder if this board wasn't an official Sega game change, the main board has two ID stickers on it, one for a virtually unknown baseball game called MVP and one for Golden Axe...

...both were 1989 games so I wonder if Sega were surprised by the popularity of Golden Axe and had to hastily change the games on a load of boards in stock to meet the demand.

Board 3

Had Dragonlee's Golden Axe board on the bench yesterday...

... was running but the characters and parts of the title screen were messed up.

Classic symptoms of a RAM or RAM logic fault.

The board itself was in good nick, fairly clean and had been de-suicided, actually probably converted from another game as all the ROMs on the board were non Sega ones.It had also been converted from System 16 pinout to JAMMA on the edge connector...

...not a fan of this personally, I much prefer boards to be kept as original as possible.

Anyway - on boards with a test function you might as well use it but on Sega boards you need a combination of the Service, Test and 1P start buttons to get into that mode and whoever did the edge connector mod hadn't connected these up. The wiring installed for the conversion was pretty tight and felt fairly brittle so to avoid having to find the end of a cut track under the wiring I just poked around with a grounded probe on the input buffer chips...

... until I found the right input for the missing controls. This got me into test mode and I fired up the RAM test. Stepping through the memory tests got me this

Sounds like progress but its not. What Sega call Scratch RAM is actually system RAM and if that really was bad then the system would not boot at all. What this is a symptom of is a board that has been desuicided, Sega used two protection methods on some ROM sets, firstly the FD1089 encrypted CPU and secondly a separate protection chip.

Some versions of Golden Axe needed this and others didn't, if you desuicide a board that used it with ROMs from a version that didn't then this chip somehow breaks the RAM test without affecting the games ability to run. This makes no sense but it seems to be the case. My own Golden Axe doesn't have this chip, it passes its scratch RAM test and runs perfectly, if I install this chip in the empty socket then the board still runs but the RAM test fails if you run it. Basically this chip is no longer needed so it came of the board, its not doing any harm there but it could easily waste a future repairer time trying to find a fault with the system RAM that doesn't actually exist.

The ROM fail tests were a result of a poorly socketed GAL on the ROM board, once that was re-seated all the tests passed, and I still had the original fault.

This is because the RAM test doesn't test all the RAM on the board Specifically it misses these...

... sprite and sprite palette RAM, which are highly likely to be the cause of the problem. They are also Sony CXK5814s which are known common failures. I went over them with the oscilloscope but they all seemed to have healthy outputs, but a RAM chip can be outputting healthy crap so all that proved was I couldn't narrow down which chip or chips were the cause.

In cases like this I would advise you start from the PCB edge, chips on the edge of boards seem disproportionately more likely to be bad than ones further in. Probably this is because of static laden fingers grabbing the boards at the edge.

So I de-soldered the pair of chips on the edge