Repair Log: Guwange

[ShootTheCore]

I'm also documenting this repair at https://shootthecore.tech/repair/repair-guwange/

I got a good deal on a Guwange board because it was malfunctioning with both background tile and sprite corruption.


The board itself looked clean at first appearances, but close examination showed plenty of leftover flux around the large SMD customs from a previous repair attempt.



These boards are notorious for insufficient solder causing SMD legs to come loose, so reflowing the custom chips is a smart repair tactic. However, examination under the microscope revealed that the prior tech had left several pins bridged together.



It took some time, but I painstakingly reflowed each of the customs again, then did continuity tests to ensure that every pin was contacting its corresponding pad correctly and that no pins were bridged.


Powering on the board again revealed that reflowing and unbridging the customs had resolved some of the glitching, but not all of it.

https://shootthecore.tech/wp-content/uploads/2023/04/Img-7093-reproc.mp4

Next, I broke out the logic probe and focused on just the sprite section of the board.



Sprites are driven by four SMD ROM chips (left), a large custom chip with part number 9842EX003 (upper-middle), a Xilinx XC9436 CPLD (lower-middle) and two 32K SRAM chips (lower-right).

For reference, the part number on the 32K SRAM chips is BR62256F-70LL.

Probing the four SMD ROM chips didn’t reveal any obvious problems – the Address, Data and Control lines all seemed to be signaling properly. That said, the four chips are on a shared bus together, so it is difficult to separate the behavior of one chip from the others – I may end up desoldering and dumping the ROMs later to compare them against MAME.

Probing the two Sprite RAM chips revealed a problem – Pin 4 on both chips is floating (ie doesn’t read Low, High or Pulsing between Low & High).

According to the datasheet for this RAM, Pin 4 is Address Line 6 – a missing signal there would certainly cause the sprite corruption I’m seeing.



I traced Pin 4 to its destination. It’s shared between both SRAM chips and connects to Pin 153 on the adjacent large 9842EX003 sprite custom.

The meter showed continuity already between the pin on the custom and the corresponding pins on both SRAM chips, but I reflowed them and added extra solder to the SRAM chips just in case – unfortunately it didn’t make a difference.

I decided to look at the signals with my scope to see if perhaps there was a weak signal present on SRAM Pin 4 that was too low for the logic probe to pick up. Unfortunately, the scope doesn’t show a reading at all for Pin 4.

Pin 3 for comparison


At this point, I’m a bit stuck. If the Sprite Custom has indeed failed internally for Address Pin 4 then my options are limited. These are my current ideas:

1. Remove the two SRAM chips and test them out of circuit. Perhaps one of them has failed in such a way that it’s “soaking” up the signal being sent from the custom.
2. Cut into the custom die adjacent to the pin – perhaps the pin has become disconnected inside and it can be resoldered into place.
3. Address lines are often shared between different systems – perhaps I can tap into A4 from another system and run a patch wire over to the SRAM. I have my doubts this would work though since the Sprite Custom is copying data out of the ROMs to the SRAM and thus is likely driving the source address lines separately from the destination address lines without any bus sharing.
4. I could try to source a replacmenet sprite custom – either from another Guwange board with a different failure (difficult to find) or from another board running on the same hardware that came out around the same time. Gaia Crusaders came out just after Guwange and its sprite custom has a part number that isn’t an exact match ( 9918EX008 ) – but it still might work. Gaia Crusaders doesn’t use SMD ROMs for the Sprite data though.

I'd appreciate any feedback or suggestions from folks that have dealt with dead custom chips before.

 

[fuzzbuddy]

Reflow the Xilinx chip too.

 

[SB_Electronics]

1. Start with the SRAM chips, test A6 with them out of circuit. It’s a long shot but it might be as you said.
2. It’s unlikely you will be able to reconnect the internal wire under the die. Maybe as a last, kamikaze resort.
3. If A6 is floating and shared on the same system bus as the rest of the board, then it may be dead because of another chip (CPU?) not the ASIC. This would be an easier fix if the system uses a generic CPU. Maybe check the CPU A6 first.
4. Replacing with an ASIC that is a different model number is unlikely to work as its design will differ. You would need to find another chip with the same reference number.

 

[Neodogg]

Any updates?

 

[ShootTheCore]

I have a Uo Poko board here now to donate a replacement Sprite Custom chip to Guwange, but I’m working on another board for a customer at the moment. Once I get this other board finished, I’ll hop back over to Guwange.

 

[Monstermug]

I wish people wouldnt attempt to fix stuff like this themselves. (Not op) What could have been an easy fix has probabably fried the custom. Small pitch qpf also comes with very fragile pads which can easily be pulled off the pcb. Plus without the right flux and equipment and method, theres bond to be problems. Most important thing to remember is to flood it with amtek tacky flux and use a proper size hoof tip for multi leg soldering and a 48x scope both during and after to check for bridges and quality. I must go through multiple tubes of flux every month. Think i made a post on Chrisbeans guwange on arcade otaku valuation thread, with the theory operation on how the graphics layering works.