GENERAL => ARCADE => Topic started by: Womble on March 25, 2011, 01:21:58 PM

Title: Midnight Resistance Repair Log #5
Post by: Womble on March 25, 2011, 01:21:58 PM
Brace yersel folks, this ones a long'un  :D

Got another couple of Midnight Resistance boards in a batch recently, one in a very bad shape, and one that looked pretty good. Both were stone dead, the good one looked like a fair prospect as there was minimal track rot unlike its partner.

Hooked it up on my test bench and got nothing, blank dark screen and no sound. On the solder side there was some scuff marks and some dodgy looking tracks but everything buzzed through ok except for one obvious blown one which I jumpered with some hookup wire. It's the rightermost track of the 4here, looks kinda roasted.


However the damage was a long way from the CPU, RAM and program ROMs so it was unlikely to be the cause of a dead board.

Going over the 68000 cpu with the scope proved the CPU was getting clock, it was not in RESET or HALT, it was just doing nothing, the address and data buses were silent. The most likely candidate in such cases is the RAM, but as the ROMs were socketed I verified those first. So, out with the SRAMs, both TMM2063's which are very common failures, both were confirmed dead by my ERPROM tester so sockets went in and a couple of equivalent chips were installed, Sony CXK5864s.

When powered up again, the scope showed activity on the two buses, but I still had a totally blank screen and no sound. Poking the scope at the JAMMA edge connectors showed I had sync but nothing on the RGB lines. Having fixed half a dozen MidRes boards I know my way around them quite well and the RGB channel output comes from a pair of 74ls174 chips at L21 and L22, usually Fujitsu brand and usually totally hosed. They did not disappoint, both chips were missing all their outputs and replacing these lit the board back up. I also replaced the final Fujitsu chip on the board, a 74ls367 that also tested as dead when removed.




I now had various screens from the attract mode showing up, as well as the backgrounds which scrolled around as they should. At this stage I also removed the sound section SRAM, another TMM2063 and another dead chip. Fitting a socket and installing another CXK5864 did nothing to restore the sound though. There were two remaining TMM2063 chips at A10 and A11 which deal with the foreground text and icons, again both these chips were dead so replacements were installed in sockets, which didn't actually change anything at this point in the proceedings.

By this point I had a house full of jet-lagged guests so managed to only grab a few brief anti-social periods in my toyroom, and the next time I got to look at this board it royally shat itself. Upon power up I was greeted with a very loud sound of zapping chippery, roasting tracks and a slow whine from the speaker. The board was dead again. I was fairly confident that most of the noise had come from one of the fat surface mount custom chips too, so it got slung back in the box it came in on a plume of colourful language.

I was pretty annoyed that I had wasted decent machined pin sockets on it at this point as they are next to impossible to get back off a board as their legs are so chunky. So after a few weeks I decided to see how bad it was, I hadn't actually seen any smoke or smelt any burning but whatever had happened had sounded pretty violent.

When hooked up again I could see that the address and databuses were running still, but the screen was once again blank. Several TMM2018 SRAM chips were now getting stinking hot too, one of a pair (B14) by the background mask ROMs and both of the screen pallet TMM2018s at J21 and J22. These were getting so hot that there was no chance they were going to pass any tests so I simply snipped the legs off each chip and desoldered the pins individually. As I was not convinced the board was worth losing any more decent sockets on I fitted a couple of tatty salvaged dual wipes and a couple of 6116 variant chips. This restored the display but the colours were even worse than before.



I ignored partner chip of the overheating one as I didn't have any more non-decent sockets to risk, so moved on to the other missing screen elements, the foreground text/icons, and the sprite field. The data for these layers are mixed into the gfx data stream by two 7425s, the foreground text and icons by the one at H22 and the sprite layer by the one at H21. Both of these were dead, healthy inputs but no output. Replacing them both restored their respective layers, however the colour issues seemed to be getting worse, the background colour choice was fairly random, sometimes green, sometimes grey.



The background data was also partially missing as the RAM in this section was half missing, half dead which made the colour issue even more severe.




I felt like I was getting somewhere again so I removed the TMM2018 that hadn't turned itself into a heater and dropped in two sockets and two new 2018 chips at B13 and B14. The backgrounds started to look a little better but now the foreground was rather dark and gloomy.




So I started to poke around the palette SRAMs chips I had replaced and found the problem, address lines A0 to A4 were silent and held low, these traced back to a pair of LS157 chips that had clearly been destroyed when the SRAM fried. Replacing these...


...finally fixed the colour fault once and for all.




The sprites were still not well tho..


.. and there was a chip in the sound section that was starting to get extremely hot.


So hot in fact that it was starting to smell, and as I didn't want the shite roasted out of the board I decided to focus on the sound for a while. Identifying the chip was fairly easy, a quick look in the MAME driver showed that the sound section had two CPUs, the small OKI 6295 by the amp and an HuC6280 made by Hudson Soft - the same CPU as used in the NEC TurboGrafx 16! Finding the pinout for that was a struggle but I finally found a text file version that confirmed it should have 80 pins and a clock signal on pin 10, which fit the bill for the chip that was cooking.

Finding a replacement was also easy, I had planned on pinching the one from the rotten MidRes board but that one also got roasting hot when powered on. I ran up a working MidRes board to confirm that the chip does not  normally run that hot so both boards I had got had suffered the same failure. In the same batch these boards came in was an utterly filthy, battered and corroded Tumblepop, also by Data East, from the same year and also with a HuC6280 driving the sound section.  Data East seemed to have bought batches of these CPUs ground the markings off and labelled them all as "45" as Tumblepop had the same sticker on the HuC as MidRes did. The Tumblepop board was also totally dead but the HuC did not overheat.

The only complicating factor was this was a surface mount chip, time to crack open the ChipQuik and lose my SMD virginity!! QuikChip is basically a very low melting point metal alloy designed to allow the removal of SMDs without expensive hardware, I bought some ages ago but had never needed to use it until now. You apply flux to the chip legs and melt in a length of the alloy, the original solder dissolves and due to it's low melting point it take so long to cool enought to harden that you can get all the legs molten at once, the chip then can then be slid off, and it works...


Leaving the board in mint condition.


The donor chip got the same treatment...


...and was just as easily removed. Cleaning up the chip for reuse was straight forward, the QuikChip stay molten for so long you can just tap the chip on the desk and it mostly just falls off. A quick run over with the desoldering iron removed the rest.

Soldering it in place took a while until I changed to a chisel iron tip and used enough flux, then the new joints almost fell into place.


After going round with the meter checking for bridges, and fixing the two I couldn't see by eye, it was time to power up again.

No smoke, no sparks, time to coin up.... GUNFIRE, start the game...

..Music! Sound Effects! Wooohooo! At this stage I was one happy Womble!

The only thing between me and a working board now was the sprites. I have seen this fault effect on a few board, large blocks of colour floating around where the sprites should be, blocks far larger than the sprites themselves, this equals missing data, large lumps of data. The sprites are really blocks of screen real estate where an "on" pixel takes preference over anything else on the screen, therefore it is in the foreground, any "off" pixels do not get displayed and the background data is left unchanged. When you get large blocks like this you have far too many on pixels, basically large lumps of sprite data are no longer actual data, just lumps of FF in the ROMs. Or actually probably not in the ROMs, the ROMs often are no longer really ROMs, just a chip with jammed output pins which gets read as FF at all loci. The board is still driving the ROMs correctly but they are no longer doing anything, but board still takes their output as if it was good data, even if that data never changes. So you get the large blocks drifting around.

On this board the sprite data lives in 4 mask ROMs at A3, A4, A5 and A6, their outputs were all active and all their inputs looked good. The fault was either the ROMs themselves or due to upstream chippery being damaged. Everything looked ok upstream but the large 160 pin "MXC 06" custom chip was a bit of an unknown quantity. I decided to give the solder side of the PCB another going over by eye in this area first and the first thing obvious thing was the burnt track I had repaired at the outset. The track was the A15 line to the sprite ROM bank, and although it was now bridged with hookup wire it was clear that this area of the board had been shorted out somehow and that track had taken the full force of the power supply before it nominated itself as the fuse and vaporised in various places. This is the exact sort of treatment that ROMs really do not like, although whether it was a dying mask ROM that cause it or not I will never know. The track went to the last of the 4 mask ROMs, called "03' and then hopped to 02, 01 and 00. So I desoldered the directly connected on and put it in my eprom reader. I had to make a small adaptor so it could be read as a 27c100 chip. Mask ROMs are often shorter than their EPROM equivalent as the data is built into the ROM as it is made, there is no programming step so no need for a programming pin. Thankfully this board comes in a few variants, some with normal EPROMs and some with mask roms, which just sit in the same socket set back 4 pins. All I had to do was use an old socket and bend the 5V pin out of the way and connect it in what was empty space on the reader socket, but where the power pin of a 27c100 would be.


The chip dumped perfectly and came back as being a Midnight Resistance ROM ff03 - slightly disappointing. Chip 02 was desoldered and again read fine, however the dump was not recognised at all, and subsequent dumps all had differing checksums, a duff ROM!! The remaining two ROMs, 01 and 00 had been completely destroyed though, my reader flagged most of the pins as "out of spec"...


...and the chips just gave totally empty reads, all FF which is exactly what I was hoping to see.

With all four off the board...


... I powered it up, this shows what you get with completely blank sprite data, all the data lines are held high by the pull-up resistor networks as there is no ROM data to pull them down., so all bits in the sprite area are on and take preference over the background for all RGB channels giving bright white blocks.


So, as the board can take either the shorter 28 pin mask ROMs, or 27c100s (32) pins all I had to do was clear the solder from the previously unused 4 holes per chip, fit some sockets and drop in three 27c100s containing the MAME data and the one remaining mask ROM that rhad survived, which you can see set back in its socket slightly.


Time for some power....



... I love it when that happens :)

Board fixed!
Title: Re: Midnight Resistance Repair Log #5
Post by: porchy on March 25, 2011, 02:01:47 PM
you sure do love those MidRes boards.
Excellent repair log, cheers, and take some kudos for good measure
Title: Re: Midnight Resistance Repair Log #5
Post by: Amiga Man on March 25, 2011, 02:09:04 PM
WOW....You are Born to Mod the Arcade  ;D ;)
Title: Re: Midnight Resistance Repair Log #5
Post by: AndyRCM on March 25, 2011, 10:54:28 PM
Bloody fantastic mate - as you already know - one of my favourite games . . . ;) A
Title: Re: Midnight Resistance Repair Log #5
Post by: Womble on March 27, 2011, 02:55:48 AM
you sure do love those MidRes boards.
Excellent repair log, cheers, and take some kudos for good measure

Hehe cheers, I do love the old MidRes boards, extremely well made, great game and usually well behaved patients. I don't seek them out tho, they find me :)

Has RCM got the one I brought over up and running yet?