Picked up a couple of dead Sega boards recently, the first out of the box was one of the massive double PCB System 16A board sets - Shinobi.
When powered up it gave this...
...which wasn't surprising as it was missing the main CPU.
Most Sega System 16A and 16B board games use Hitachi FD1094 encrypted CPU modules, which contain a suicide battery, a drop of RAM holding the encryption key and a Motorola 68000 CPU core. The main program code in the ROMs has to be encrypted with the same key as is held in the CPU module so that the 68K can actually run the code. When the battery dies, the key is lost and the game bricks. The decryption system was worked out many years later and decrypted ROMs are available which need a normal 10MHz 68000 CPU to be substituted for the encryption module.
The usual assumption is that the suicide battery ran out of juice and the CPU was pulled/binned/lost.
The only sign of abuse was a PAL on the video board which had been crushed into its socket...
...but had survived with all legs intact.
With that straightened out, and a standard CPU installed...
...all it needed were two replacement ROMs in the main CPU ROM set.
Am not sure if the silk screening on this board is wrong, or the IC locations that have made their way into the MAME info is confused, but one of the ROMs I was supposed to replace was at IC27, which is an 8464 SRAM chip soldered in, some where the info is messed up.
With a couple of 27c512 ROMs from my stash wiped and programmed with the decrypted code...
...the board fired right up, almost.
I met a board that ran without sprites in the double repair log I did a couple of years back, which was pretty handy as the fault was partially the same and I could read where I had been.
I started off poking the banks of sprite RAM on the video board...
...three had a number of address lines with nasty looking signals, low twitching data lines and a /WE line that was tied low so the RAMs were always waiting for input on the i/O pins and never outputting anything at the right times, which is why the sprites were completely AWOL.
The holes in the address bus and the /WE issue were tracked to couple of 74LS157s at IC54 and IC62 with messed up outputs.
They looked nasty on the scope and the comparator agreed.
With those desoldered...
...and replaced the missing address lines lit up, and /WE was back in action, but there was no change on screen as the data I/O lines were still a mess low compressed transitions...
...which effectively means all data bits were set to 0 as the signals never reached the threshold to be considered a 1.
This was the same missing pull up fault on the 74ls374 bus data latches as found in the other repair log, except the cause is not actually a lack of pull up functionality, the data sheet I read stated that 374s are able drive a line to logic high without needing pull ups. Either way the issue is the same, the faulty latches take data in but can never pass it on.
There are three ICs that share the bus, the 74LS374s at IC63/IC71 and the 74LS244 line driver.
Its not uncommon for 244s to either cause damage when they fail, or be damaged by faults on their bus, so all three ICs were pulled...
...and all three were confirmed faulty. With those ICs replaced with working ones salvaged from scrap PCBs the sprite RAM I/O pins lit up again.
Progress but not a fix yet. I now had data being fed into the sprite RAMs and was now being written to the screen, but the data was either wrong, or was getting mangled somewhere.
The source of the sprite data is a bank of 8 ROMs on the video board...
...the data bus pins on these was a mess.
This is classic bus contention, where multiple ICs are trying to drive the lines at once, if both try to drive the line logic high you get a high, if they both want to drive low you get a low, but if they conflict you end up with a logic level somewhere in between. In this case there are four pairs trying to talk all at once so the resulting signal is a complete mess. The board should be able to turn the ROMs outputs on an off to ensure that only the right pair of ROMs has control of the bus at any given time, and this is usually achieved with an address decoder IC (usually a 74LS138 or 139). These take the most significant bits of the address bus and us them as signals to turn ROM's outputs on and off using their /OE (output enable pin). Looking for an LS138 or LS139 nearby found me this fella at IC32.
This is a dual decoder chip and all four output pins for the second decoder (pins 9/10/11 & 12) were constrained low and twitching. With all four pins firmly in logic low all four pairs of the sprite EPROMs had their outputs enabled and were trying to shout each other down, with the result being the mangled data written to screen.
Testing the 139 off the board gave no surprises either.
With a working LS139 dropped in the shouting match ceased and the corruption vanished.
That should be the end of it, but the next board out of the box was a dead Sega System 16B PCB, the PCB had the original label on it for Altered Beast and it too had an FD1094 CPU module on board. These usually still have their Sega part ID sticker on them which is useful as the code denotes the game and the version. Googling that code will usually take you straight to the decrypted set you need when evicting a dead FD1094. On any Sega system 16 board it is wise to start troubleshooting with the decrypted set and a normal 68000 CPU installed to rule out any suicide or partial suicide craziness.
The part number on that FD1094 was 317-0050...
...which is for the encrypted Shinobi Set 1.
Dumping one of the ROMs on the second board identified the ROM set as Wrestle War, the the board was a mix of a main board originally born as an Altered Beast, a Wrestle War ROM board and a CPU module from Shinobi - not surprising that it wasn't working. Even though the battery in these modules have been running since 1988 a small proportion are still hanging on to life, so I swapped back in the two original program ROMs, dropped in the CPU module...
...and it booted right up.
Clearly someone has been swapping bits around on these trying to get these two boards to work. Pretty happy to get a working FD1094 for Shinobi, my fetish for keeping things original means I prefer to have the suicide system and original CPUs intact. This means I have to replace the battery when I find one still alive, it is a bit of a faff but it keeps the board as close to 100% original condition as possible
Replacing the battery is fiddly and time consuming, any break in connection to the internal battery will instantly it the module, and you have to be careful of the tripwire they left for you. If you are too keen with the blade and you cut or nick the wire you risk bricking it too.
Basically with as wide a blade as possible you slowly lift and cut through glue around the edges...
...until the lid can be lifted.
The intent is to leave the top plate totally flat, if you bend it you will never get it to go back in place again.
Then it is a case of soldering a new battery in parallel with the old one, and cutting the old one out.
Leads fitted to new one and contact pin bent slightly to fit the case...
...and connections made in parallel to the old battery...
...allowing the old battery to be cut off, taking the lid and trip wire with it.
Smoke test time, the module goes back on the board and it is still working fine. If anything had gone wrong the module would be heading for the bin, there's no going back once they lose their RAM contents.
Still alive, and as the top plate is still totally flat it just drops back in place and the glue still has enough stick to hold it.
The date code on the old battery is for April 1987...
...a damn good innings for a standard watch cell, just over 10,501 days.
The new battery should be changed again in 10-15 years really, expecting another 30 would be pushing it a bit.