Nichibutsu Terra Force, repair by Womble

[frsj8112]

For backup from aussiearcade with embedded pictures (photobuck...sigh)

Felixthedog brought this board round a few months ago to test it in my cabinet as it wouldn't fire up properly at his house. It was missing some key parts and showed signs of being someones repair project / parts board before.







A couple of 74LS257s that decode the dip switches had been removed and replaced with (now empty) sockets, a decoupling capacitor that I am pretty sure was not original (the second board set doesn't have one) had taken a beating...







...the amplifier chip had been pinched from the back board...






...and there was a chip missing from the top board leaving an empty original 20 pin IC socket.






The last bit was the biggest concern, very few ICs on old boards were socketed, and 20 pin usually means a PAL chip. These are configurable logic ICs that take the place of what would be dozens of logic ICs if discrete chips had been used. This means they are highly specific to the board (or board family) and usually cannot be easily replaced. Even though they are programmable it is usually a one way process due to the security bit being set. This usually means a programmed chip cannot be read successfully, so you cannot read the config out of a good one to program another one. Your only hope is that they forgot to set the security bit that day in the factory, which is not very likely. I did fire the board up in my cab and it did precisely nothing, with that chip missing the board was a no hoper unless a donor board could be found so I didn't investigate it any further.



Fast forward 3 months and Felixthedog had sourced a donor PCB, another faulty PCB set but one that was complete. Initially that board set looked like a better repair candidate but not for long. This one had been someones repair project and they had made a mess in a number of areas. They had re-soldered all the PCB connectors and then over tightened bolts holding the board together. The soldering was messy and with the stress on the boards some of the pins had been forced through which tears the plate through holes, meaning a lot of the joints would be unreliable. The board also showed signs it had been wet at one stage, with corrosion and track damage under a number of the ROMs, and the ROM legs oxidised to the point that a number couldn't be read, ut it did have the PAL chip that was missing from the other board.



Swapping the PAL into the original board...





... and dropping in a couple of 74LS257s ...






...resulted in not much, basically a stone dead board. Oscilloscope time, hitting up the 68000 CPU showed I had clock, and that /HALT and /RESET were both high, so the board should be running. At the exact instant of power up the board did give a burst of activity on the CPU address lines at the ROMs but then went quiet, a good sign that the CPU is crashing, probably because it has no working RAM, or because the program code in the ROMs is corrupted. The main system RAM was a pair of Toshiba TMM2063 ICs with the shiny black tops...





...which are almost always dead on faulty boards, but as the ROMs were socketed I ran them all through the EPROM reader to check I wasn't looking for a hardware solution to a software problem. All the ROMs checked out and the output from the RAMs looked suspect.



On some data IO pins the signal looked healthy(ish)...





...but on others there was just a ragged mess...









...and while poking around with the scope the screen did spring to life...






... and on reboot, I did briefly get this...






...once, before it returned to being dead.



Which kinda suggests I was in the right area, the fact this board can barely even get this far isn't that surprising, the RAM/ROM check is itself a computer program running on the CPU, so if all the ROMs are dead then the test code isn't there, and if all the RAM is bad there is no space for the code to execute in. In this case the RAM is clearly almost totally dead.



The desoldering gods were not on my side that day, normally I like to get a chip off intact so I can test it off the board, but this was hard going, so I cut them off and removed the legs individually.












With two sockets fitted (about the only time I use sockets is for RAM and ROM) and two scrap board RAM ICs fitted I got.... a stone dead board again - the exact opposite of what was expecting.



Going back to basics I found I now had no clock at all at the CPU, until I touched the 16Mhz crystal. It was only hanging on by one leg, the other had rusted through, it showed signs that someone had tried to solder it back on, trouble is you can't solder rust so it was barely making a connection.






With no spare crystals of the right frequency I robbed the one from the other board set...






...and fired the board up.






Progress, shame about the colours, and the background, and the sprites, oh and it crashed a lot, sometimes instantly, other times mid-way through the attract mode cycle, or after a few seconds if you tried to coin up.



The colour fault was down to a totally dead TMM2015 SRAM chip at H8, one of the H8/H9 pair that form the colour RAM. This had activity on its address bus but its data pins were floating, which means you can piggy back another IC on top without any issues. It is as if the original chip isn't electrically there so it acts solely as an adapter. With a scrap TMM2015 chip from my stock piggy backed full colour was restored.






Not wanting to do any more desoldering I left the piggy back in place for later and moved on. The constant crashing was the main problem still, the graphics issues were secondary and were unlikely to be involved in the stability issues.



I had initially suspected bad contacts between the boards as being the cause for the lock ups, mainly because when it crashed it would not recover when the power was flipped off and back on, it would just power back up in the same wedged state.



After some poking around it turned out that pulling it apart and putting together just enforced enough of a delay between powering down and powering up for it to boot properly, it stopped me powering it back up too soon. This pointed towards the system RAM again as that is the only place the state could be stored temporarily, and as I had put a pair of mismatched junker SRAM chips it was possible they were not playing nicely together. Swapping in another combination, also junkers, cured the crashiness and also brought all the sprites back. These fly around the screen so rapidly its almost impossible to photograph them against a black background as the camera takes too long to focus on the bright spots.






It's unusual that the main system RAM has anything to do with the sprites on boards with separate graphics subsystems but this one seems to be an exception. It's lucky that the board was so crash-happy, if it had run fine just with mashed sprites I doubt I would have found my way back to the main system RAM as a suspect for that.



With every issue so far being SRAM related it was pretty easy to find the next issue, what turned out to be the foreground SRAM had a dead IC in the pair, and it responded to the piggybacking trick.






Lighting up the missing data lines.












Looks like progress to me, so it was desoldered and a socket fitted.












The one remaining issue was the overlaid band of pixels on the right hand side of the screen, my guess was that this part of the mangled the character layer as the text on the screen would glitch from time to time.






The culprit again was another pair of SRAM chips at E12 & E13...






...with the scope showing bus contention on the data pins, basically one chip has lost the ability to keep quiet and let other chips on the bus talk, so the two chips fight each other, giving the half way data levels. It could also be the ROM but as I had a second board I could swap the ROM, the chances both ROMs would have faults on the /OE pin were unlikely so RAM it was, at least one of them was going to be bad.






I picked the wrong one of the pair to desolder first...






...with just the bad one left on the board I was greeted with this...






...with the game running in the background and a wall of crap in the character plane on top.



With the bad SRAM chip replaced I got this, graphical perfection!









All the controls worked and the game could be coined up and played, in silence, amplifier time.



I had planned to pinch the amp chip from the other board set but the amp type was pretty common (handy to have a second board to check what it should be, there don't appear to be any schematics for this board out in the wild), so I found a replacement MB3730 on a scrap rusted out Midnight Resistance PCB.






Whoever removed the original amplifier IC had done a very good job of desoldering the original...






... so it was just a case of bending the legs, applying a drop of heatsink compoundt, bolting it down and soldering it in.






On power up there was still no sound, for about 30 seconds after which there was a massive pop in the speakers and the theme tune started to blast out. Whether the delay was the amplifier IC or the capacitors waking up after a long hibernation I can't tell, but it only did it once and the music and sound effects were fine, sadly the amplifier chip was not. It was getting roasting hot within 30 seconds of being powered on, which usually means it is oscillating. A voodoo blend of noise on the PSU, PCB layout, stray RF interference and component health can result in the amplifier oscillating, the first sign usually being a burning smell even though the audio may be fine. I had to assume that the PCB layout was correct and that it didn't do it from new, although it is possible that it was the cause of the original amplifier chip's demise. Logically the place to start were the capacitors, specifically the 470uF one between 12V and ground which is there to clean up the 12V power rail.






The ESR reading was about twice what a good cap should be, but ESR isnt major issue in this case. Anyway, a capacitor swap was easy enough, and it had no effect at all on the overheating problem. Decoupling for amplifiers power rails is usually achieved with a pair of capacitors, a very large electrolytic and a very small mylar capacitor. The large electrolytic provides power rail stability and mops up the low frequency noise, the small mylar mops up the high frequency noise. Digging up the datasheet for the MB3730 showed the recommended circuit for the IC with a 2200uF electrolytic and a 0.1uF mylar cap on the power rail. The PCB had no provision for the 0.1uF anywhere so I fitted one on the underside of the PCB across the 470uF capacitor.






Problem solved, the MB3730 would now only get warm and not overheat. So I swapped it into my cabinet for a game and blasted through the first level and called the board fixed!



Or not, the following day I had planned to find the right stand-offs for it and bolt it together finally, except on power up for another game I was greeted with this.

[frsj8112]

The game was still running as eventually it progressed to the demo mode and you could see the terrain through some of the squares of crap overlaid on it, and also part of the game title. No amount of power down rest, or reseating of boards, ROMs or RAMs would chase it away fully, although the severity did change from time to time. Going over the board with the scope didn't give any quick leads and as every section of SRAM on the CPU board had been partially replaced I simply went ahead and replaced all remaining TMM2015 SRAMs with sockets, and RAM that was tested and probably working. Some of the original RAM tested bad and some tested as OK, the OK ones went back into the board in sockets.



Testing SRAM ICs is rarely 100% conclusive unless you have a known working board to use as the tester. In most cases on-board RAM tests are basic and usually the board physically cannot test all the RAM chips as some sit behind dumb graphics sub systems that are not directly controllable by the CPU. Off board tests only test the IC in isolation, they do not prove it will behave when asked to share a bus with other talkers, or has the strength to drive actual inputs of downstream ICs, or that it can be driven hard and fast. Fitting sockets allows a new RAM chip to be fitted, and swapped around if necessary, and if there is no change the old RAM can be considered to be no worse and reinstalled.



A second thought was that this new fault may be located on the rear PCB, all faults so far have been on the top board, but there's no logical reason why the other board should be fault free. Of the SRAM on that board most of it was grey metal topped TMM2015 chips, which from experience are much more robust. In an ideal world I would have swapped the back board from the other PCB set except for some reason the gender of the connectors on the two boards sets is reversed. So I could plug both CPU boards together and both video boards together, but not mix the sets. I have no idea if they were made this way, or if the soldering evidence on the other set means they have been taken off and put back the wrong way round.



What really didn't help was the fact that the fault seemed to change regularly...












... and the nature of the faults seemed to suggest there were actually multiple faults at play.



In cases like this it helps to know which section of a board is involved in the producing the various graphics layers or planes. Most games in the arcade era did this as the overlaying can be done with simple logic and not require any input from the main CPU. This is why the CPU often cannot test all the RAM on the board, it physically has no direct connection to it.



Through poking around on this game I knew that there were 4 layers, which from top to bottom are...



4) Alphanumeric Character plane - Responsible for the Game Over, Copyright Notice and High Score Table.



3) Sprite layer - all sprites, player ships, enemy ships, anything you can destroy basically.



2) Foreground layer - all upper levels of scenery, cloud, floating islands and the large enemy ship, any damageable sections are actually sprites sat on top of it.



1) Background layer - ground level, sea level backdrop.



Layers 1 and 2 scroll at different speeds giving the parallax scrolling, and the screen is laid out in a priority order. On a pixel basis the logic XORs the incoming data from the 4 layers to say if there is no pixel at layer 4 then show layer 3, if there is nothing at layer 3 then show layer 2 and if there is nothing at layer 2 then show layer one. At the point a sprite is drawn there will be nothing at layer 4, and a pixel from layer 3 which overrides any pixel data at layer 2 and layer 1.



Ignoring the fact the upper half of the screen was sometimes drawn twice and focusing on the fact I had repeating pattern or crap washed over the entire screen I could predict which layer was causing the problem. The repeating pattern had progressed through a number of technicolour options but was now pretty consistently a stone effect graphics tile






The sprites were OK, the alphanumeric data was OK, I just had stone effect texture underneath them. On rare occasions a square of ground/sea level data would scroll past which showed I had a foreground issue.






Something was causing the pixels on the foreground layer to be switched on 99% of the time across the entire screen. So either the data source (the ROM) was bad, or the RAM caching the data was bad, or the logic controlling the subsystem was bad. Poking around with the scope in the foreground section didn't show anything obviously missing at points in attract mode when the foreground system should be outputting data, but I could corrupt the entire screens worth of "stone" by shorting data pins on ROM 5. Removing ROM 5 from its socket removed almost the entire fault, by removing the source of the mishandled data.






The sprites had started to play up at this point but ignoring those for the time being it was clear that the graphics looked ok, except the foreground sections were completely missing.



ROM 5 still tested OK off the board, and burning a replacement EPROM didn't help either. The controlling logic for /OE and /CE was active and healthy looking so it wasn't due to the ROM being stuck on due to bad logic, or a bad ROM. This left the address bus, clearly the data bus was OK as the graphics element on the screen was made up of good data, just the wrong data and at the wrong time. Even though all pins of the address bus were active, the upper two lines A15 and A14 did not look right. These were driven by the Q outputs on the 74LS273 at H2.






When looking at the D inputs for the relevant outputs there didn't seem to be enough activity on the outputs.



Piggy backing a known good 74LS273 at H2 was a long shot...






... but it either annoyed the fault...






...or cleared it entirely.






Once desoldered, the original 74LS273 failed the off-board test, confirming it was shot.



With a new one soldered in the graphics were restored, complete with floating rocky islands...






...and non mashed cityscapes for the side scrolling sections.






With that complete I took it back to the cabinet for a play through, which progressed well until about 10 minutes into the game it froze. The music kept on playing meaning the main CPU had crashed suddenly leaving the audio CPU to carry on doing what it was told in the last contact it had from the main CPU. Something had glitched, and these issues can be a pain to track down as it could be as simple as a single bit error in a single byte in a torrent of data flying about, a needle in a haystack.



In an attempt to rule out likely connectivity issues I removed all the ROMs, polished their legs and reseated them - no change. I even refitted a decoupling capacitor as the board had one bodged in place, which suggests someone else had found the board a bit crash happy.



Initially this seemed to have cure the issue, but after a few reboots this old fault reared its head again.









Whatever was the cause was clearly playing up in the earlier photos where the game logo is vertically sliced up, so again it was a case of determining what plane the fault lived in. Which in this case is the actually the character plane, which is actually split across two ROMs the graphics components ROM 9 and what appears to be scroll and blanking data in ROM 10.



The nature of the fault is actually pretty telling in this case the board is pulling a graphical section from ROM for display, and then trying to get hold of the next section of data, but is getting the same data as before, this smells like an address bus problem. As the board gets a decent lump of correct data before that section repeats the fault is likely to lie with the upper address bus lines. Think of it as a theoretical block of data 64KB in length, the upper address line will control which of the 32KB blocks in ROM the board is reading, upper or lower. The other address lines control the finer level divisions down to the individual bytes, but the higher the address line the larger lumps of data it controls. If that upper line cannot be driven, or is ignored when driven, the ROMs will output the lower 32KB block twice, instead of the lower, followed by the upper.



For this fault I could completely remove the bad graphics elements by pulling ROM 9, the game would run happily with all the messed up elements missing.






Poking around the address lines on the RAMs associated with the ROMs...






... I found a stuck address line, and by introducing rubbish from a nearby pin I I could also annoy the fault, triggering 3 or 4 smaller blocks of the game logo to repeat. The outputs on the nearby 74LS245 looked pretty unhealthy too, so that chip was desoldered, and tested. It passed the tests, so I fitted a socket and dropped it a spare 74LS245, the outputs on that chip were just the same, so the original 74LS245 went back it. It acts as the bus transceiver for the large 64 pin SDIP custom IC, and the signals coming out of that didn't look too great either.



The SRAMs were the a pair of original ones that had passed the off-board tests initially, one now failed repeated tests so it was retired to the bin.



With a new one dropped in the issue was resolved, and once again the board moved to my cabinet for a play test.






Everything was going well until I got towards the end of the first level, at which point the game froze while the music played on. On rebooting the game was fine again, but eventually it did the same thing again, each time happening sooner and sooner after reboot.



Intermittant freezes are hard to track down, as the game does the right thing for ages, then the wrong thing for a split second and crashes the board. Once the board has crashed you tend to get all sorts of craziness on the system buses as the CPU sits there twitching to the tune of the clock signal. It could be anything, glitchy logic, intermittent connections on ROM sockets, flaky RAM locations, anything at all.



I had a poke around the 68000 buses and didn't find anything that looked too obvious. Thankfully as the fault got worse and worse, it got to the point that the board would often fail the initial ROM tests, barely getting past the first part of the attract mode animation where the pilot hops into his space ship before locking up.






Then it started to struggle with the ROM test, then the RAM test and after about a dozen reboots the board would consistently give the "RAM NG" message, suggesting something nasty was happening on the CPU's directly connected buses.






This smelt like the last of a variety of faults to curse this PCB, all of which were fairly intermittent and occurring randomly in amongst each other. I tried swapping in new RAM, and swapping in the ROM set from the other PCB (already dumped and confirmed working) but neither had any effect.






Not sure what the one green label denotes, possibly a mongrel collection of ROMs on the second board-set, but all were from the same version though.



At this point I was getting pretty sick of it, and I still didn't trust the TMM2063 RAM ICs I had, even though they passed the off board tests consistently, they were the only matched pair of 100nsec skinny 6264 RAMs I had so couldn't rule them out entirely by replacing with another pair. The off-board tests are pretty low stress for an IC and don't test whether it can coexist on a shared bus and be driven hard.



Faced with a number of candidates I decided to bite the bullet, desolder the CPU...






... fit a socket...






...and wheel the Fluke 9010 and 68000 pod out. Actually I used two sockets, one machined pin directly soldered to the board as it was the only decent socket I had, and a crappy old salvaged socket to act as a temporary adapter. The Fluke pods don't like machine pin sockets as they are too tight a fit. I didn't want to risk breaking a pin on a $450 pod for the sake of a $1 sacrificial socket.






This wasn't actually as useful as I thought it would be, initially the bus and RAM tests passed without any issue, but the board would not run using the Fluke as the CPU, crashing in a colourful way.






The fault appeared to continue to get worse and the RAM checks started to fail at a variety of different address locations.









MAME comes in very handy at this point, not for the ability to emulate the game, but in the way it does it, the game driver files contain the full details of the memory map which is exactly the information you need to know when you are pretending to be a CPU with a Fluke 9010. This is taken directly from the driver.c file for this game, the bold sections are my own comments.



static ADDRESS_MAP_START( terraf_writemem, ADDRESS_SPACE_PROGRAM, 16 )

AM_RANGE(0x000000, 0x04ffff) AM_WRITE(MWA16_ROM)

AM_RANGE(0x060000, 0x0603ff) AM_WRITE(MWA16_RAM) AM_BASE(&spriteram16) AM_SIZE(&spriteram_size) 8KB Striped TMM2063

AM_RANGE(0x060400, 0x063fff) AM_WRITE(MWA16_RAM) 8KB Striped TMM2063

AM_RANGE(0x064000, 0x064fff) AM_WRITE(paletteram16_xxxxRRRRGGGGBBBB_word_w) AM_BASE(&paletteram16) 4KB 2x2K TMM2016s

AM_RANGE(0x068000, 0x069fff) AM_WRITE(armedf_text_videoram_w) AM_BASE(&terraf_text_videoram)

AM_RANGE(0x06a000, 0x06a9ff) AM_WRITE(MWA16_RAM)

AM_RANGE(0x06C000, 0x06C9ff) AM_WRITE(MWA16_RAM)

AM_RANGE(0x070000, 0x070fff) AM_WRITE(armedf_fg_videoram_w) AM_BASE(&armedf_fg_videoram)

AM_RANGE(0x074000, 0x074fff) AM_WRITE(armedf_bg_videoram_w) AM_BASE(&armedf_bg_videoram)

AM_RANGE(0x07c000, 0x07c001) AM_WRITE(terraf_io_w)

AM_RANGE(0x07c002, 0x07c003) AM_WRITE(armedf_bg_scrollx_w)

AM_RANGE(0x07c004, 0x07c005) AM_WRITE(armedf_bg_scrolly_w)

AM_RANGE(0x07c006, 0x07c007) AM_WRITE(terraf_fg_scrollx_w) /* not use in terrafu, 0x07c008 neither */

AM_RANGE(0x07c008, 0x07c009) AM_WRITE(terraf_fg_scrolly_w) /* written twice, lsb and msb */

AM_RANGE(0x07c00a, 0x07c00b) AM_WRITE(sound_command_w)

AM_RANGE(0x07c00c, 0x07c00d) AM_WRITE(MWA16_NOP) /* Watchdog ? cycle 0000 -> 0100 -> 0200 back to 0000 */

AM_RANGE(0x07c00e, 0x07c00f) AM_WRITE(armedf_mcu_cmd) /* MCU Command ? */

AM_RANGE(0x0c0000, 0x0c0001) AM_WRITE(terraf_fg_scroll_msb_arm_w) /* written between two consecutive writes to 7c008 */

ADDRESS_MAP_END



The address location 62726 in the error messages falls within the space that the two TMM2063 SRAM chips sit, but as the fault is in the middle of this space, and not at the stop/start section of the RAM, it suggests that this fault is not the RAM chips themselves. If it was a fault at that specific location then the off board tests would have found it, if it was an issue with them behaving on a shared bus the fault would have occurred at the very start of the space, at 0x060000 not so far in.



Its interesting to see the reason behind the second fault here, where one of the palette RAMs was bad, producing only red graphics.



AM_RANGE(0x064000, 0x064fff) AM_WRITE(paletteram16_xxxxRRRRGGGGBBBB_word_w) AM_BASE(&paletteram16) 4KB 2x2K TMM2016s



That section of address spaces is the two TMM2015s were, and as this is a 16 bit system the two 8 bit SRAM chips sit side by side, one IC providing bits 0-7 and the other 8-15. Of the two chips one provides the 4 bit colour values for green and blue, as described by the GGGGBBBB, and the other provides only the red, with the first 4 bits of any read being ignored, as per the xxxxRRRR section. The original fault was a bad RAM chip causing the total loss of all green and blue data.



Anyway, at this point the fault had progressed to be very obvious when using the scope and running read/write tests with the Fluke, the 74LS374 octal latch at H4 ...






...now had horrific looking Q outputs...






... that should closely match the D inputs.






The output enable signal on pin 1 also looked like it was tied high, which came from the pin 17 PAL that was originally missing on this board. As it was socketed I pulled the PAL, and bent that pin outwards so it would not drive the enable line. I assumed it was left high due to the almost instant crash, with this pin now left low the fault on the 74LS374 remained, the chip should be acting very differently so clearly it was faulty, with the outputs tied high it was basically interrupting the data bus causing the CPU to crash.

[frsj8112]

Once desoldered it failed off board tests...






...so a new one was soldered in and the power flicked.









Fixed, again.



While I had the Fluke connected up to it I ran the RAM and ROM tests again, and noted the signatures that a working board gives. The calcsig application available online only deals with 8 bit pods, no one seems to know how the system calculates signatures for a 68000 pod so the only option is to do manually step through the ROM dump and do reads across the memory space to see if everything lines up. Slow and tedious work, so with another board set to fix I took the option to get the correct signatures from this one now it was a working board, and they are as follows.



00000-1FFFE ROMs 3Lo 8Hi SIG=A570



20000-3FFFE ROMs 2Lo 7Hi SIG=2A26



40000-5FFFE ROMs 1Lo 6Hi SIG=8A9F



00000-5FFFE Full Stack SIG=4F42



That wasn't quite the end of it though, I swapped back in the original ROM set from this board and the it would no longer boot, giving just a black screen. Something is clearly up with those ROMs, I'll need to re-dump them when I look at the second Terraforce PCB, possibly one has died during the repair process, or its the old "can't live on a shared bus" fault with one of them.



Once the board was bolted back together the volume control could no longer be adjusted, that turned out to be a weak pin in the PCB interconnect, which snapped off the second I touched it. For some crazy reason the designers routed the volume pot connections through from the amp on the back board to the front board. Actually that does make sense, as when mounted in a cabinet the amp would be on the inner face, which is why PCBs usually have the amp on the top board next to the edge connector, to avoid having to route audio signals long distance.



There's no easy way to fix this without replacing the entire connector, an its an odd type that you probably can't get easily anymore. So a single length of hookup wire can be the temporary long term fix if need be.



I was very glad to bolt this one back together finally, as it's boards like this that make fixing boards seem like work, rather than a hobby. To soak test I left it running on attract mode in my cab while I got on with some other things. It was fine for a while, until I glanced over at it and saw this.






It barely lasted half an hour, tops, she's down again.



The rubbish across the screen came went while the game ran underneath, ranging from sparklies...






...to complete wipe out.






The source of bad data is turned out to be ROM 9 this time, as when pulled all wrongly drawn data vanishes. Going over the EPROM with the scope it was obvious that address line A13 was not not behaving...






...A13 traces to Q4 (pin 12) on 74ls273 at D13...






...and I could see what looked like clock breaking through into the signal, in time with the flickering mess on the screen.






A similar signal was not seen on input D4, so that chip looked faulty, it was removed...






...tested bad, and was replaced.



This brought the game back to life, but not for long, mid way through the play test it froze again, on reboot it gave the familiar RAM NG error message, and on subsequent power cycles it didn't even get that far, giving just a black screen.



The game then ran for a few levels then froze, on reboot would either give RAM NG or sometimes just a black screen.



As I had just taken Fluke readings from it as a working board I threw it back on again...






...the ROM tests all passed, proving the ROMs and the /CS system, but RAM would fail a WR at 60010 or 60014...






...giving intermittent random hex data at the low RAM chip...






...the blurred characters on the display are the result of the test being set to loop, and getting a variety of results back. The SRAM chip tested OK on my reader but the Fluke was a more comprehensive test. I managed to find a couple of 6264s on a long forgotten scrap board so a single replacement 6264 at H7...






...fixed the issue and the board would then pass all tests again.






RAM "short" meaning the short RAM test, as opposed to the Fluke's long RAM test, and not a shorted RAM.



I retired the other TMM2063 in the pair too, bloody 2063s!






Again it went back to the cab for a play test, and again it ran fine for again for a couple of levels, then the foreground graphics started to glitch and break up, giving a variety of effects...









...including a blacked out alien ship which is actually foreground data with sprites placed on top as the damageable areas.






This was much the same fault as one a while ago, in fact the fault was the second 74ls273 in the pair at H1.






It had looked ok on the scope earlier, but now had what looked like the same clock signal bleed through as the others. It was removed, failed off board tests and was replaced. The board was again 100%, again it didn't last.



Three levels into the game all the sprites just vanished as I transitioned to the water level at about level 4.






There are a number of options for this kind of fault, either the sprite generation area of the board has failed in a way that has shut it down, or the sprite data is no longer getting fed into the system (although this usually gives coloured blocks in place of the sprites), or the layer priority system has gone haywire so the sprite data no longer has priority over the background data and never makes it to the screen.



I was slightly suspicious of this fault as the majority of the sprite system is contained on the back PCB, which so far had not had a single fault. I could partially confirm this as I could interrupt a load of data signals on the board and cause no visible effect. I assumed that the sprites would be mangled by this if they were present. Also sections of this area would shutdown during portions of attract mode that displayed no sprites, so it seemed to be behaving normally.



As the fault happened suddenly I was really looking for a single chip failure, specifically something that would take out 100% of the sprite data in one go. So I focused on anything that sits on the data buses and could take out all data bits at once. This narrowed it down to the larger chips such as 74LS273, 74LS244, 74LS374 ICs and the ones controlling the SRAM chips in what I suspected was the sprite system, specifically the /OE, /CE and /WR pins. Poking around with the scope showed no signs of any failure on the back board and no ICs that were missing any /enable inputs.



If the sprite system was apparently running fine then the only real options left were that it was being fed null data, or that the sprite priority in the final screen assembly was wrong. Without the schematics it is hard to work out what parts of the board are doing this, but it seemed logical that the final assembly would happen either on the back board or on the front board close to the DAC that converts the data into the RGB signals. The DAC on arcade board are usually easy to find as it is a load of discrete resistors bunched close together, forming a ladder DAC. These are a set of 5 resistors of increasing value tied at one end to the video colour channel output. Their resistances allow each bit to have an increasing influence on the voltage that is put on the common output if the input is logic high.



Poking around the area I found that I could deselect the background graphics plane in part by shorting pins 1 and 2 on the 74LS153 multiplexers at K12-K16. By shorting data onto the /enable pin I would randomly "disable" the outputs, blowing holes in the background data being written to the screen...






...and underneath the background plane were the sprites.









Poking around further it didn't take long to find the 74LS273 at J6 which had a number of outputs doing nothing.






Piggy backing a working 74ls273 on top lit up the missing data lines ...






...and the sprites pinged back on top of the scenery again.






It got desoldered...






... and replaced, to fix the game, again!



So far this front board has lost over half the 74LS273s, clearly the ones from that batch are all at the end of their service life. I doubt any single event could take out just those chips but leave the rest of the board intact, so I ended up just bulk replacing the 4 remaining originals. In fact i removed all the random 74LS273s I had fitted as I worked through this and replaced them all with a matching batch of bullet proof Hitachi brand ones I salvaged from a scrap board. Out of the four untouched original 273s only 3 passed off board tests, at least one of them was about to cause another fault.






A new Hitachi 74LS374 from Jaycar replaced the rather tatty one I had fitted earlier on at B4 to close out the repair.






The final tally of parts replaced is pretty impressive for a single game PCB repair job.






It has been stable for about a week now, with repeated plays and power cycles so I am fairly confident that this is finally fixed and staying fixed.

[geotrig]

wow ,what a repair ,great read thanks for sharing , I have to give it to you have some tenacity shown there , I would have burned it to the ground !

[emphatic]

Wow, you don't give up easily. Great read.