Game didn’t boot and immediately shut down the power supply. Indeed, a meter confirmed only 2 or 3 ohms of resistance between GND and +5V at the edge connector, so something was shorted on the board. There’s really no easy way to find a short on a board like this. Removing all the socketed chips to eliminate them is a good first step as well as looking for physical damage, especially to capacitors that may bridge GND and +5V.
Luckily I found the fault fairly quickly – when I lifted one of the legs of the ZD1 component the short was gone and the board played correctly. I believe the design of the board is ZD1 provides some overvoltage protection by bleeding the +5V line to GND if required, however in this case it had simply failed and shorted +5V to GND.
Game ran but sprites were garbage – bad positions and lots of corruption.
I ran the self test before doing much more – and it came back with bad custom IC30. This is actually a math coprocessor, and the main CPU uses it for maths to position all the sprites in screen space – so if it fails sprites will be corrupt.
Luckily I had a spare for this chip from a Thunderblade parts board. Game was perfect after I swapped it in.
Game didn’t boot – and physical damage was the obvious problem – the PST518A reset controller was missing from the board. A replacement was taken from a scrap board and the game ran again.
No sound – again some obvious physical damage – the power amp had been ripped from the board. A brand new MB3730A was bought on Ebay and installed and the game was perfect again.
Board showed missing graphics on the title screen and blocks in game were often wrong.
After some diagnosis it became clear the scroll position on the tilemap was wrong – rather than actually anything wrong with the tilemap itself. The missing title screen graphics were instead horizontally scrolled off screen by 256 pixels.
The scroll position is controlled by the 137419-104 custom chip and this seems to have failed with the 256H line stuck high. Fortunately this chip is also on a few other Atari games, including Pit Fighter, so I pulled a chip from a corroded parts board to fix the Gauntlet.
The board had another fault I recognised immediately from another repair – sprites with ‘sparkly’ vertical lines down the screen. This is a failure of the resistor packs used to pull the sprite data lines high when erasing a scanline. These packs are at the corner of the board, so any flexing of the board can lead to hairline fractures. 470ohm resistors can be used as a replacement.
I’ve still been repairing but have had little time over the past year to write up any posts. I’ll still try to document the more interesting ones though.
It seems email to this site went down over the past few months and I didn’t notice. If you emailed me and I didn’t reply please assume I never received it!
This board had the original 35 year old battery backed suicide CPU still installed. When the battery dies the encryption key is lost and the CPU will execute garbage. Replacing this with decrypted ROMs and a plain 68000 was the first thing to do, and the board booted up with a graphics fault.
The SEGA letters were visible, just in the wrong place which suggested an addressing problem. I probed in the area around the tilemap RAM (IC113 in schematics) and found a LS367 @ IC128 with dead outputs. Replacing this fixed the tilemap.
The game was now mostly correct but some sprites were wrong/missing, the most obvious thing being most of the Sega logo on the title screen. The ROM board is packed full of ROMs but it’s really just 4 sets of 8 – each set supplies 8 bits at a time to the 32 bit graphics processor. I used MAME to disable each set one at a time and I found removing the 3rd ROM replicated the fault. The ROM tested good on the board but a probe showed one of the address lines was floating – presumably some kind of corrosion under the socket. The address lines are all shared between all the ROMs so this was easy to patch.
Just to complete the set of problems, the sound board had a bunch of missing and broken capacitors needing replaced – one in particular shorting +5V and GND.
This mainboard also still had the original 35 year old battery CPU and it booted up! It only lasted a few days though and needed replacement as per the other one.
This board had a weirder graphics fault on the video board – text appeared underneath sprites, sprites were wrong colour and seemed transparent in places. I found the video mixer part of the circuit in the schematics and found priority is calculated by a CK2605 PAL device. All outputs were dead, and this was confirmed by using the PAL from the working board. A replacement was ordered from RetroClinic to fix this board fully.
Very clean board but booted to corrupt screen with continual watchdog resets. Like most Konami games of this era the watchdog can be disabled by bridging the jumper near the edge connector. With the resets taken care of the 68000 CPU was stuck and not running – however it wasn’t stuck in HALT mode, instead it was waiting for a DTACK signal. When the 68000 writes to an address it waits for the receiver to signal it has received the data via DTACK. (Not all games do this, some just tie DTACK low and assume whatever was written got there).
There are no schematics for this game so I had to spent some time tracing out the board. DTACK is driven from the LS00 NAND gate at 4g. The LS00 is driven from the LS74 at 2g and the LS30 at 7g. A logic probe on these chips revealed a dead output on one side of the LS74. With a replacement soldered in the game was perfect.
Game played but had no sound. The audio amp (M51516L) was getting 12V ok, but produced absolutely no hum or hiss which is a good sign the amp itself has failed. Before replacing I tried the usual trick of attaching power speakers to the preamp outputs but this didn’t give any sound either. The audio CPU, ROM and RAM all tested good so I moved onto the YM3526 sound chip. The IRQ pin was pulsing which is a good sign it’s working as the CPU must program the IRQ timer for this to happen. However, a scope on the digital audio output stream showed it wasn’t trying to play any sound.
My next theory was the main CPU wasn’t telling the audio CPU to play anything – most games of this era use an 8 bit latch to pass sound commands. The main CPU writes the audio command into the latch then signals an interrupt on the audio CPU to signal command data is ready. A logic probe on the audio CPU NMI line showed it pulsing whenever a sound should play (such as coin insertion) so I took some guesses at what chip the latch was and found a nearby Fujitsu LS374 where the clock also pulsed on coin insertion (main CPU writing the command) as well as output enable (audio CPU reading the command). Sound worked with a known good LS374 piggybacked over the top, so the Fujitsu chip had failed and was likely passing 0xff (all 8 bits high) for all audio commands.
After the LS374 and M51516L were replaced everything worked again.
Game booted to a solid green screen or sometimes would not boot at all.
The first fix was simple – the ROM sockets and ROM legs were very dirty and oxidised. 1200 grit sandpaper on the ROM legs and Deoxit in the sockets cleaned things up enough that it would boot consistently.
The next fault was a real headscratcher – in the attract mode the screen wouldn’t scroll – the characters just ran to the right hand side and got stuck. Starting a game had a similar fault. This was clearly a program logic error – however the ROMs had tested good, and it was likely the RAM was good as well (piggybacking known good RAM made no difference).
The fault didn’t become clear until I started swapping the top and bottom boards with a few other working Desert Assaults. Desert Assault is a dual CPU game, with a 68000 on each board and in this case the top board had a different revision of the program than the bottom board. Someone must have tried to repair the board in the past with fresh ROMs but only replaced the top set (bottom set was still original). Reburning the top ROMs fixed the fault.