Status: Ongoing. Diagnosis began on 4/9/2023.
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.
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 U066 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.
At this point, I’m a bit stuck. If the 9842EX003 Sprite Custom has indeed failed internally for Address Pin 4 then my options are limited. These are my current ideas:
- 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.
- Cut into the custom die adjacent to the pin – perhaps the pin has become disconnected inside and it can be resoldered into place.
- 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.
- 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.
To be continued…