Topic: Sega Shinobi (System 16A) Double Repair Log  (Read 5178 times)

Author Message

0 Members and 1 Guest are viewing this topic.

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1185
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
Sega Shinobi (System 16A) Double Repair Log
« on: December 01, 2013, 10:50:23 PM »
Hi folks, it's been a while but finally got round to polishing this one off.

Apologies in advance - this one is a monster, have had to split over three posts to avoid the 20,000 character limit  :o

I advise you to make tea before attemping this one....

At some point way back in 2011 I picked up a dead Shinobi board on eBay, according to my notes the seller said it had worked until recently, but then developed graphics issues. However when hooked up to my test bench via a System 16 - JAMMA harness it was completely dead, no video, no sound, no life. A quick scoot around with the scope showed that the lower board was completely powered off. Despite the 3 50 way ribbon cable interconnects between the boards the power supply to this lower board is via an external connector which through a combination of broken connector latches and badly re-soldered joints on both boards was no longer connecting the two PCBs

Someone had re-soldered this at some point but hadn't pressed the connector back hard up against the board and made a hash of the soldering, so the bad joints just broke again leaving the connector loose. A complete desolder and a proper re-solder on both boards fixed the issue. Even with the broken latches it can be fully engaged, its just a bit more of a faff.

The old faults as described by the seller were back, slight corruption on the title screen giving a blocky pattern around the ninja's neck...

... corruption on the building frontages, a Fisher Price colour scheme, plus a nice snow effect on the ground...

...and the bonus stage was almost completely red - nice!

Also when the main character was on the upper level of the 1st stage and jumped, all the foregrounds vanished until he landed again. Basically the background was drawn infront of the foreground and some of the sprites.

First thing to fix was the obvious damage, a number of decoupling caps had taken a beating and had legs wrenched out...

... or were completely missing, torn off the board.

Replacing those had no effect but they are there to increase the power stability of the board and if too many are missing or damaged it can make the board glitchy.

The board was pretty heavily populated with Fujitsu TTLs, and a load of 74LS157s which always seem to be the flakiest ones, so I went round them all with the logic probe looking for floating outputs. All of the above faults above, with the exception of the jumping background fault were caused by a single bad 74LS157 at IC40 which was sporting a number of missing outputs. It got desoldered...

... and replaced, which fixed up the graphics nicely.

The jumping background fault that still remained was one of those problem faults that are highly specific and only happen at certain times, which makes them very hard to find as most of the time the board is doing the right thing, and when it is doing the wrong thing it is fairly minor. Also the problem with dual PCB board sets is you always have the nagging suspicion that the board you are working on isn't where the fault lies, so you end up constantly flipping the board set over and never really getting anywhere. I went over both boards but found nothing obvious, half the issue was this effect only occurred for about 3 seconds every minute so I really needed another board set to narrow down which PCB contained this fault or I would be wasting hours watching the attract mode loop trying to catch the fault.

As it happened I did have another System 16A Shinobi board set that once belonged to "Leftjumpleft1P" in my scrap pile. Judging by the aborted repair log I had on it the PCB has been here since at least March 2010, it came in a parcel of faulty boards, some I was able to fix, others were wrecks. I had pretty much written this one off as a complete basket-case but it had never fitted in any of the parcels I sent back to him, so it had remained here in a corner.

Even though ideally I needed a complete working set to completely fix my PCB, what I actually had was my almost perfect Shinobi set which I could use to divide and hopefully conquer the basket case set. If I was able to get the other CPU board working I would see whether I still had the mysterious jumping background fault when paired with my video board. If I did then the fault was likely to be on my video board, and if the fault was gone then it would suggest it was my CPU board that held the fault.

I probably should not use the terms CPU and Video board, which are used so often for dual PCB sets, as they don't really apply to Sega System16A systems. A lot of the video processing happens on what is referred to as the CPU board and the CPU subsystem is not complete without the video board.

So I hooked my probably 99% OK video board to the other CPU board and fired it up. I got a black screen and the constant clicking in the speaker which is the watchdog system trying endlessly to get the board to boot. This was exactly what it was doing 2 years ago when Jump1Left sent it to me. The repair log I started was just a text file full of locations of suspect chips and notes that large sections of the CPU board were stone dead, along with a long list of damage to the video board. This board set had clearly seen some real violence it its past, probably someone plugging it in to a JAMMA harness and leaving it to fry.

When I originally received it the board had a standard 68000 CPU on it, but the ROMs were the original ones containing the encrypted code for the missing FD109 encrypted CPU block. I had burnt the unencrypted set for the board when it arrived so that was no longer an issue. I went back over the CPU board with the logic comparator and had tested all the Fujitsu TTLs present, only finding one bad 74ls30 at IC56 and a dodgy looking 74ls244 at IC33 using the scope. The problem was still that so much of the board was shut down that a large number of chips had no active input signals, so the chance of false negatives was high.

Now I at least knew the fault was somewhere on this CPU board so I pretty much started from the beginning.

The decoupling cap that had been torn off at C27...

...was replaced with a new 470uF 16V, it had minimal chance of causing the boot issue but again it is there for board stability.

Going over the board again with the comparator I found the 74LS161s at IC51 and IC63 had floating outputs so these were replaced with salvaged chips...

...I thought I had found a broken track under IC63, but there was no break, just oxidation under the lacquer. I scraped it back to the copper and put some fresh lacquer on the area before the new chip went in. None of this had any effect on the board's failure to boot. Also the four LS253s that take the control inputs from the edge connector were all flagged as bad but these would not cause the inability to boot so I ignored them and moved on.

Faced with an uphill battle I decided to wheel out the big gun, the Fluke 9010 and the 68000 Pod.

The Bus Test function gave me the following fault...

...which translates to the fact that the /HALT line and the /RESET line were causing problems. Poking round these areas of the board with the scope gave no clues so I told it to ignore all the errors and carry on. To my surprise it booted!

It doesn't look like much but the large yellow bar was flashing, and after a few seconds it changed to this...

...which looks worse, and then this...

... and then it repeated, this is actually the attract mode running. The flashing bar is the flashing "Insert Coin" area of the screen and the final image above is actually the wreckage of the high score table.

It is missing most of the actual data it is supposed to be displaying and the colours are missing blue but it was successfully running the program code.

When I disconnected the Fluke and put the old 68000 CPU back on the board it continued to do the same, happily running attract mode, very odd. Until the next day when it was back to the black screen and constant watchdog resetting. The culprit for all of this was the CPU socket. It's a machined pin socket so it should be bullet proof, but whether through dirt or oxidisation the CPU was not making good contact on all its pins. So I cleaned the CPU pins, bent them outwards slightly and reseated the CPU a final time to chase the fault away. The missing blue seems to come and go and wasn't a bad connection on the edge connector.

Clearly the board is very unwell but as a lot of it was running I could rule out a lot of the board and focus on the bits that were still doing very little. By pulling ROMs I was hoping to find areas where the loss of a ROM didn't introduce any new faults, or crash the board, and he fault remained unchanged when the three ROMs at IC93/94/95 were removed.

Pulling these ROMs on the working CPU board caused the background graphics to be missing so I figured I was in the right area. One obvious fault in that area was that of the pair of 2016 SRAMs at IC96 and IC97...

... the output pins on IC96 were a mess on the scope, almost like a city skyline, a classic sign of bus contention when more than one chip is talking on the bus at once and the signals are fighting each other. This chip did pass the off board tests in the EPROM reader but clearly it cannot operate on a shared bus as when I put a known good SRAM chip in its place I got this...

...background data, the board was slowly waking up.

Further poking around revealed that the collection of LS153s...

...nearby had a fair number of floating input pins. The silent inputs all traced back to a 74LS174 at IC102, pins 10, 12 and 15 outputs were all floating....

...oddly enough, so were the inputs to those gates, which went to outputs on a second 74LS174 at IC103.

These outputs were fed by inputs that again were floating, which were fed by outputs of other gates on the same chip, again floating outputs. After hoping through 3 gates I got back to the first input to the 174s and found a healthy signal. Both 74LS174s were completely shot, and had died in the Fujitsu way, despite being SGS brand. Which explained why I hadn't found them with the logic comparator beforehand as I usually only bother the brute force method with Fujitsu chips due to the way they tend to fail.

Once these two were replaced...

... I had foreground text and sprites...

...even if the colours were still pretty unwell.

At this stage I knew I wasn't missing a colour channel on the output as I had white sections of graphics and to get white you need Red, Green and Blue channels to be working. So I focused on what I was assuming was the final stage of the video assembly in the bottom right corner of the CPU board.

I poked the scope at the Fujitsu 74LS125 at IC77

and its outputs looked fairly mangled so I dug up a spare on a scrap board to test the one at IC77 and it came back as having timing issues so the spare got soldered onto the board.

Nothing improved so I moved on, the original one may not have been an issue anyway but its a Fujitsu so I am never too bothered about retiring one prematurely.

At this stage I decided to put the board into test mode to see what it could tell me now I had video output and working text. The problem was that the service mode button did not work, the game would also not coin up so I couldn't even start a game for a play test. This was all down to the four Fujitsu 74LS253s lined up along the width of the the board by the edge connector, ICs 5,6,7 and 8. Replacing those brought back the ability for the board to register buttons and switch inputs.

Once into test mode I stepped through the tests and got the following report...

... which is a bit bizarre as IC90 is not a RAM chip at all, its a 74HC273. The SRAM chips are IC96 and 97 so unless that is a rather stylised "6" it is a typo in the main code. Either way, IC97 is a SRAM chip and it was reported as bad. This is the remaining chip from the pair that I replaced one of earlier, so I removed it and dropped it a known good one - no change. Its outputs looked fine on the scope but I noticed I could short out the data bus pins on that chip and have no effect at all on the screen. The address bus is shared so any shorts there caused the screen to go nuts. Clearly the data was leaving the chip, and presumably arriving too, so the egress path from this area to the downstream colour processing was not working correctly. As is fairly common on data buses there was a paired HC273 IC90 and an LS245 at IC98.

The 273 was an NEC chip while the 245 was a Fujitsu, guess which was the prime suspect?

The Fuj!

I actually replaced both IC98 and IC101 as they are a matched pair and often seem to be damaged as a pair too. The result was this...

Assuming it was finally fixed I hooked it up for a test play in my cab, the dip switches had always been set so attract mode sound was off so this was the first time I had heard it and it wasn't good. The sounds were horribly distorted, very over-driven and clipped, everything was present but everything was loud and mangled. I have met this fault a few times on boards and after checking the caps in the amp section you are really only left with two options, the main amp chip, or most likely the op-amp chip (often a dual or a quad op-amp) just upstream. It is usually actually the op-amp or in this case a pair of quad op-amp TL084s at IC2 and IC3.

I have had limited success pulling op-amps off scrap boards as often they are in bad shape too. Luckily op-amps are one of the few chips that are still commonly used today and therefore one of the few useful chips for arcade repair that Jaycar still sell, for the princely sum of $2.45 each. I could have got ten for that price if I was prepared to wait, but I only needed two and needed them now. So in went some sockets and the two new chips.

The sockets were mainly because I wanted to check if both the original chips were bad, the new pair was always going to be used as a pair but if one of the originals was OK I would have kept it. As it turned out both originals were bad so both were binned.

So finally I had two Shinobi CPU boards in apparent working order, the vanishing foreground issue when the sprite jumps was evident with both boards when paired with my video board, so it is highly likely that that fault lies on the video board, otherwise both CPU boards would have to have the exact same fault - pretty unlikely. So I could be fairly sure I had two perfect CPU boards, and of the video boards, one had a minor fault, and one still had major issues.
« Last Edit: December 02, 2013, 06:07:14 AM by Womble »
Sic Transit Gloria Atari

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1185
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
Re: Sega Shinobi (System 16A) Double Repair Log
« Reply #1 on: December 01, 2013, 10:50:55 PM »
Leftjumpleft1P's video board...

...totally prevents either of the good CPU boards from booting, giving pretty patterns of rubbish and the constant ticking of the watchdog timer again.

I went over the video board with the logic probe and found 15 chips with missing outputs, many other chips had missing inputs but those were likely connected to the missing outputs, so a bulk chip replacement was in order. All of the chips were common types easily found on scrap boards, except for the LS378 at IC110.

Have never seen one used on any other arcade board and my massive stack of scrap boards didn't contain a single one.

The datasheet for the 378 is shared with the 377 as they are almost the same chip, the 377 is an octal gate chip, while the 378 is a hex gate chip, ie 6 gates versus 8. The 8 gate 377 is fairly common but is longer than the 378

so I grabbed one from a scrap board and gave it a trim...

... made up some leg shifters from LED leg cut offs from another project...

...and moved the ground and clock signals from the board to the overhang...

... replaced all the other bad ones and fired it up.

Not the extent of progress I was hoping for. The problems on this board were clearly going to take a long time to chew through, and my video board had a fault that only occurred once every few minutes in attract mode and was also going to be a pain to find, so neither PCBs were high on my list of fun jobs. So they got put down and the whole project sat on a shelf for nearly two years.

Was having a clear out when I came across the boards again, and as some kind soul had found and published the Sega System 16A PCB schematics in the intervening period, I decided to have another go. Picking up where I left off I focused on my mostly working board set first, working from old troubleshooting notes is usually painful after significant time has passed so I started again.

A new graphics fault had crept in, the main sprite started off OK, but gradually got worse and worse as I went over the board with the scope. There were some sparklies in the bad guy sprites initially but eventually it was only the sparklies that were left...

... the Japanese calligraphy characters that swirls on the main screen is also a sprite and this was a mangled mess just the same.

Poking around with the scope I narrowed in on the area by shorting data paths and observing what I annoyed on the screen. Ended up at a set of four 74ls245s...

...with pretty ugly outputs ....

...two of which were running bloody hot. 74LS245s usually run pretty warm but not burn-your-hand hot, as they were Fujitsu brand I whipped all four off the board.

Two passed the off-board tests, but the overheating pair failed, all got binned and replaced with salvaged ones.

This brought back the sprite data almost entirely, but then it started to fail again, with large lumps of data wrongly drawn, rather than the earlier fault of the data just drying up entirely.

I tracked this down to a 74LS194 at IC19.

Corrupting its data pins made things worse... took it off the board. It tested fine so as I would have to desolder one from a scrap board that is very hard to desolder from I nearly put it back, despite it being a Fujitsu. Luckily I didn't as when it was replaced with a Hitachi one the fault was cleared and stayed cleared.

Finally I was back to the original fault, that the foregrounds vanished when the main character jumped on the upper layers. Ended up wasting an eternity of time due to many false leads. I even socketed one of the custom chips that ended up looking like a suspect. Logically the fault was with graphic plane priority, the graphics are in layers which have a hierarchy of priority. Any data for text on the screen has the highest priority so is displayed even if there any other plane data. Sprites come next so they glide over the background but don't overwrite the "Insert Coin" text, then foreground, then background. The fact the background jumped forward suggest something is wrong in this system. Trouble is everything looked OK on the scope. I could narrow in on an area of the board but couldn't identify the actual chip, ended up on a major wild goose chase before I ended up at these guys...

All were removed...

...and IC100 was faulty, all went in the bin.

Both were the next downstream from the blown LS253s I had replaced earlier - not a coincidence I think.

Once they were replaced the character could now jump on the upper level and the background remained perfect!!!

I now had one fully 100% Shinobi set, plus one working CPU board and the final basket case video board. So I started back on the second board set. I retested the second CPU board with my now 100% video board, only to find it faulty giving this.

Knowing the video board was fine I went over the CPU board looking for the missing data,  and found IC88 Fujitsu 273 TTL with 8 missing inputs, looking at the schematics this chip is fed from the 27c512 ROM at IC95, whose /CE and /OE are tied to ground, therefore it should always be active.

At the chip socket all outputs were dead, so I pulled the chip and dumped its contents, it read fine, putting it back on the board cleared the fault, so it was down to another dirty socket. Cleaning the legs and the socket contacts fixed the problem. When the video board was connected it was clear there was another new fault, the video sync was a mess, which wasn't an issue when I put it down the last time.

This would leave the screen a screaming mess most of the time, sometimes it would lock for a second or two, sometimes ten seconds but it was never what I would call stable. The sync signal leaving the board actually looked fairly healthy from a signal perspective, it was clearly mostly nonsense as far as the monitor was concerned. The actual output comes from pin 6 on 74LS86 at IC57, which takes Horizontal Sync on pin 4 and Vertical sync on pin 5 to create the composite sync output marked in red below.

I had pulses on pin 4 of the LS86 but not pin 5, which was mostly silent with the odd twitch. The twitch seemed to correspond with the moments that the screen sync would jump. It used to sync from time to time but had been getting progressively worse until the point where it hardly ever managed to sync. As the 74LS86 was a Fujitsu I just replaced it, which didn't give any improvement.
The initial concern was that the whole area involved a nest of 3 PAL chips closely interconnected, but as I had already swapped the PAL chips over to rule out issues on the other video board I knew they were fine. The only chance was one had just decided to die, so I swapped the sets back again and got no change in the fault.
The twitching Horizontal Sync tracked back to the output on the PAL at IC66 which takes its inputs from a stack of 74LS699 counter ICs, these were connected via the "carry output" pin so that the total count would overflow from one chip to the next in the stack, with the binary count outputs of all three fed into the PAL. Going over the 699s with the scope showed something smelly on IC60...

...the carry pin was not transitioning correctly, the pattern was there but the voltage never fell below 3.5 volts so would be a logic high at all times.

I guess on the odd occasion it did just dip below the low threshold which would explain why it sometimes did sync briefly. Once this chip was replaced the system could again count out the time intervals required between pulses and I had a rock solid image to work with again.
The image was now this...

...pretty messed up with none of the graphical elements correctly displayed. I was unsure whether this was due to a missing sprite plane, or another plane priority issue where the sprites were OK but behind the messed up background. So I started out at the Sprite 2148 SRAM chips and found of the data outputs on the four lefter-most chips were not transitioning healthily, they were mostly constrained low and so would never make it into the logic high threshold.

The options here were either the RAM chips were bad (but all four being bad seemed unlikely) or something on the bus was jamming their lines low. The opposite of something jamming them low, is a loss of their pull up, the lines on these 4 RAMs did not have external pull up resistors so they should in theory rely on pullup ability of something else on the bus. The outputs were striped across a pair of 74LS374 chips(IC63 and IC71), a single LS244 chip (IC55) and a trio of LS399 chips (IC77, IC81, IC89).

Of these only one, the LS244 was a Fujitsu , however this is not the mode by which Fujitsu TTLs tend to die. They appear to lose internal connectivity so their inputs should be unloaded not loaded down. Anyway the Fujitsu came off the board and tested as totally shagged.

The issue was this did not release the data lines as expected, even with the IC55 location unpopulated.

so I removed each LS374 in turn only to find they tested OK. A positive result on the tester is not as indicative as a negative result and I was still looking for the pull-up function that was probably the root cause of the squashed-low signals. The LS244 does not contain internal pull ups, but the LS374 chips do, so I was left with the situation that both the LS374s were actually bad when in a system requiring their internal pull up function. The LS399s on the bus were connected with their inputs so it wasn't very likely that both were bad, but I had two seemingly bad 374s in view, and 374s had been a failure on these boards before. So a salvaged 244 and a pair of 374s were installed and the data lines lit up again.

Sadly the onscreen result of this was zero, the outputs of the section I had restored was either being fed junk data at source, or its output was getting lost elsewhere.
So, faced with the knowledge of what was wrong with the other video board I moved on to the output stage, where the graphics plane priority was played out. Combined with Wombles 5th law of board repair (suspect the up and downstream chips from a chip you suspect died a violent end) I went onto the four 74LS374s at IC92/93/99/100 that were inland from the blown LS253s that I replaced in bulk many months before.

On the scope I could see the inputs were all healthy looking but all the outputs were a low lying twitching messes.
« Last Edit: December 02, 2013, 06:10:31 AM by Womble »
Sic Transit Gloria Atari

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1185
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
Re: Sega Shinobi (System 16A) Double Repair Log
« Reply #2 on: December 01, 2013, 10:51:32 PM »
As I no longer had any trust in the 374s whether they passed off-board tests or not I opted to replace them all with salvaged ones. As expected the ones (IC99 and IC100) next to  earlier replaced multiplexer LS253 chips were shot, failing the off-board tests.



The inner pair did actually pass the tests but due to earlier concerns about loss of pull-up functionality they found themselves resting in the bin too.
With four salvaged LS374s (really should buy a load as these boards have chewed through almost all of the 374s on all of my scrap boards) in place...

...all the signals looked healthy, but the effect on the onscreen was not much, a slight change at best.

Faced with what looked like a working mid-path and a working end-path I now had to retreat back to the data source, the ROMs. The lack of background was slightly puzzling as the ROMs for that actually live on the CPU PCB, the sprites and foreground data lives in the ROMs on the video PCB.

So I hit the sprite ROMs with the scope and found the address bus on those barely alive. The majority of the address bus lines looks silent and twitchy, but when I pulled ROM 94 off the board they all lit up again, I wasn't sure if I had ever dumped or pulled the ROMs on this board so I pulled them all and read their contents, IC95 and IC97 gave bad reads. A while ago someone on AA offered me some salvaged chips they were going to throw out, in that collection was a bag of scrapped Shinobi chips, the old encrypted 68000 CPU, a Z80 and a set of EPROMs.

Most were not the same version as the set on this board, but the ones on the video board were all present and correct. So instead of swapping just 94 and 96...

...I swapped in the complete set and got no bloody change at all, despite the address bus now looking healthy again.

So now convinced the data source was fixed I went back to output stage, and noticed that on on IC99 and IC100 (74LS374 SGS brand) pins 15, 16 and 19 would regularly crap out and fall silent. These were outputs whose inputs looked OK except the clock on both chips was now silent and high. The schematic area for these chips was not lined up properly on the scanner so the line labels are off the edge. Only option was to buzz things through on the working video board, and the clock line went to custom chip (usually bad news but I knew it was good). It also went to IC50, a Fujitsu LS174, which is wrongly marked as IC59 on schematic as there is another IC59 on the same schematic page which is the correct one, a 74LS699.

Outputs of some gates on this chip feed back as inputs to other gates on same chip, pin 12 is the final output pin, whose input pin 13 connects to output pin 5, whose input pin connects back to a PAL. I knew the PALs were working so I could only assume it was a stuck input on IC50, the logic comparator didn't flag it earlier but if an input pin was stuck then the comparison chip would get the same stuck input and so the outputs would match.

The LS00 at IC 49 had rough looking outputs so it was retired at the same time as IC50 while the desoldering iron was up to temp.

The result was that the text was now tidied up, i.e. the right characters all the time rather than a random jumbled mess in the test system. So I could get the board to run its self tests and actually see the results. It came back that IC105 and 112 were bad.

This was actually easier to read in real life than the photo suggests, the RAMs it was complaining about were already socketed so I could test them off the board...

...they passed, I also dropped in replacements to completely rule them out but nothing changed.

Poking around with the scope I could see that sometimes D2 and D6 on both would just stop working or would hover around randomly.

The weird thing was that I could wake them up by shorting them to their neighbour pin and they would act normally for a while, then go quiet again. Following D2 onto the bus took me to pin 16 on the LS145 at IC108 and pin 7 on the LS374 at IC109. The 245 should be A-side input paired to its neighbour, picking up the pullup resistors along the way, mostly they all did and were busy...

...except D2 and D6, which were silent and had no continuity to their allocated pull up pin.

I had replaced the 245 at IC108 a long time ago during the bulk replace stage and I couldn't see any signs of track or pad damage, but clearly these two tracks had let go at some point, possibly as a result of the replacement, or at some stage in the distant past. Bridging the lines to the pullup pack remade the connection and fixed the background and foreground graphics in one hit.

Everything looked great, except there was no sprites, and during a quick semi-blind sprite-less play test in my cab I noticed the speech output was also corrupted, another fault.

In search of sprites I started poking around the area I knew to be involved from the earlier sprite fault on my video board, and hit upon the LS257 at IC26...'s outputs were silent despite healthy inputs, and by shorting an input to an output (i.e. passing the wrong signal onto the next chip) I could get garbled sprites to appear, this is called "annoying the fault".

Replacing the 74LS257 chip restored the sprites!

Next step was the speech, the voice should say "Mission 1" and the noise kinda sounded like it was saying the right thing but extremely muffled yet in time with the syllables. My first thought was something to do with the Op-Amp at IC8, a uA3403 chip.

The capacitor next to it didn't look in great shape, it was showing signs it had been wrenched to one side and then straightened up again, which leaves one leg torn off inside. A quick check with the ESR meter showed this cap to have and ESR of 42 Ohms...

...which is hugely out of spec, it should be around 1 Ohm, so it got replaced, but the fault remained. The other candidates were the Op-Amp and the 74HC244 chip which was connected to the ladder DAC so its outputs were somewhat tortured anyway. The op-amp seemed the most likely so I removed it, fitted a socket and dropped in a known good one, which didn't fix the fault. The HC244 at IC7 is the last digital stage before the array of resistors forming the DAC and was the only candidate left.

It was removed...

...and it tested bad on my EPROM reader.

I didn't have any HC chips so I temporarily dropped in an LS244 and fired it up, speech fixed! Added the HC244 chip to my Jaycar shopping list and called the board preliminarily finished. Except not quite...

I set about bolting both board sets together using some sw***y machined metal standoffs, spring washers and bolts and put both boards through a quick play test on my cab. My fixed board set went first and after ten minutes of play I swapped to the one I had just fixed. The rainbow coloured Shinobi title hadn't struck me as odd while I was working on the board, but having two working board sets side by side it was clearly wrong. On the first board set the title text flashes between red and white, on the second it is static with coloured stripes. Which do look cool but it can be hard to see sometimes against the background.

Also the high score table colours now looked wrong having seen the correct display with the other board.

I very quickly found I could annoy the fault at the location of what I thought was my clever attempt to make an LS378 chip from an LS377. Sure one is the octal variant (8 gates) and one is the hex version (6 gates). They hadn't just removed the gates nearest the far end of the chip, they had taken the middles ones out. Which meant the pin-out for the last gates on my modified chip was reversed, I had the data inputs and outputs the wrong way round on the gates at the far end of the chip. As 74LS378s are next to impossible to find on scrap boards and I wanted to verify the fix I re-modified the mod, chopped more legs off, fitted it in a socket and looped hookup wire to reverse the required pins.

Yep it's ugly, yep it worked, yep it was temporary, I ordered some LS378s the same day.

When the new 74LS378 arrived and the Jaycar-sourced 74HC244 were installed on the board I finally had two complete 100% working Shinobi PCBs.

The 4 year mega repair is done!

Aaaaaaah, the closure!!!  :)
Sic Transit Gloria Atari

Offline AndyRCM

  • >=))))º> GO FEED THE FISH! <º((((=<
  • Administrator
  • Amiga 4000
  • ******
  • Posts: 9590
  • Kudos 50
  • Gender: Male
  • Manic Jet Set Willy
    • View Profile
    • Retro Computer Museum
Re: Sega Shinobi (System 16A) Double Repair Log
« Reply #3 on: December 02, 2013, 12:11:37 PM »
As always a fantastic write up and amazing reading . . . bit of a bastard those though mate. Well done. :)

"I could see the faces of those who led pissing themselves laughing" - Funeral Pyre by The Jam