PCB Repair Logs Pipi & Bibis
Pipi & Bibis
 |
|
| Manufacturer | Toaplan |
|---|---|
| Year | 1991 |
| PCB Image | Reserved |
| Pin Out | Jamma |
Repairer: Womble
Forum Thread: Pipi & Bibis PCB Repair
Picked up an old Whoopee board recently (english variant is called Pipi&Bibis but it still seems to be known as Whoopee for some reason) - very very bizarre game, its a puzzle game, the prize being the chance to see 1/4 of a semi naked cartoon chick after each stage - wtf?!? Those crazy Japs! There is even a dipswitch to put her clothes on if cartoon nakedness somehow offends.
Anyway - it was faulty, when powered up it did this, some degree of sentience, screen a bit of a mess but its clear that it thinks there is a "Sprite RAM Error".
First step was to give the board a good eyeball check looking for damage, aside from one region the board looked fine, but that one region looked very very nasty.
Amazingly enough, despite the major gouges, none of the tracks had been cut, all buzzed through perfectly.
So, onwards to the RAM! There are 3 pairs of RAM chips on this board, the pair nearest the CPU, at C5 and C7, I assumed were the system RAM, ie where the game program itself runs. That left the Sony CXK RAMs in the middle of the board at D8 and D9 and a pair of what turned out to be Seiko ones at G16 and G17.
I have seen a fair few Sony CXK5863s go bad (mainly on NeoGeo boards) so started there. You can see the Sharp LH51680 system SRAM chips to the left of the 02 EPROM.
The upper one looked alive but a bit wobbly on the scope, and the lower one had D3 and D4 stuck low - bad sign, either its the RAM chip thats lost the ability to drive the bus, or the bus is shagged so that the SRAM pin is tied low - most likely its the RAM chip. So I whipped them both out and but them through my VP280 tester. The upper one was fine but the lower one was knackered. Fitted 4x14 pin sockets to make 2x28 pin banks and dropped in a couple of spares from my scrap TMNT board that tested as fine.
Powered the game up and the game booted and went into attract mode, all was not well though, colour corruption and great chunky green bars across the whole screen.
Despite that the game happily ran, could be coined up and played.
The fact the game ran kinda ruled out a problem with what I suspected was the system RAM, in fact if I interupted anything on those chips the game would lock up - defo system RAM.
So I moved onto the other non-system SRAM chips at G16 and G17, going over these with the scope I found G17 had its D7 tied low, all the other Data lines were busy. Thought I was onto something so I whipped it out and tested it, it passed, desoldered its companion and that passed too!
While I had the chips off the board I could see how the tracks ran, by the way I always take photos of the area under a chip, its very handy to be able to see where the tracks run even after soldering a chip or a socket back in again. Taking the chip off the board can also be handy if you are not sure what the chip specs are. I couldnt find any datasheets for S2517RL chips, but the silkscreen says 6116 which are very common types - easy to replace if need be.
All the D lines ran back to a pair of 74LS245 and D7 didn't go anywhere else other than pin 9 of the 245. As the SRAM chip was fine I assumed it would be the 245 that was holding the line low, so I desoldered the 245 and that tested as fine too. I was actually so suspcious of these "passes" that I fitted sockets for the RAM and a socket for the 245 so I could bend legs out of the way to see what each chip was doing on its own. Replacing the SRAM chips and the 245 didn't change anything
By the way, when one of these SRAM chips is missing the board boots but gives a "Pallete RAM Error" similar to the orginal fault, handy to know for sure what the SRAM is doing.
When G17's D7 pin was bent out of the way and the chip socketted so that D7 sticks out everything worked as before (game ran with prison bar effect) and the hanging leg was held low - which suggests that the data output on that pin really is always a zero. When the RAM chip was put back in properly and the 245's ping 9 leg bent out of the way it booted up but gave a "Pallete RAM Error". Weird seeing as there is nothing on this pin but the SRAM chip.
Anyway - I wasted a lot of time looking at this chip - a missing data line could give the fault I was seeing so I spent too long trying to suss it out. In retrospect it kinda makes sense. There are 2 SRAM chips giving 16 data lines output, the data bus is not shared so it is a 16 bit wide bus. The fact that one of the SRAM chips outputs an 8bit binary number whose upper bit is always zero (the pin is held low ie a zero, its not floating) makes sense when you think that this is colour RAM and there are 3 colours, red green and blue. If you assign 5 bits to each colour you need 15 bits total, not 16, so the upper most bit of the 16 bits could be anything. This explains why injecting data into it gave no effect - the system ignores that bit anyway.
At this point I was beginning to worry it was the custom IC in the middle, despite the fact that customs tend to be very hardy I could not see what else would cause jailbars on the entire screen while letting the game run.
Was out with the dog when it occured to me that the sprites also had a similar bar through them, it could be the custom but it could also be the masks. I was so convinced I had a SRAM or logic fault I hadn't even bothered with the masks.
The mask roms turned out to be PROMs on closer inspection, thankfully had their type printed on top of them (TC538200) as well as their Toaplan chip ID so I was able to find the pinout for them.
They are 8Mbit PROMs that are pin for pin compatible with 27c800 EPROMs. On the scope there were a number of Data lines held low, again this could be the chips or it could be the bus or connections between the motherboard and the daughterboard they live on. To prove it wasn't stuck lines on the data bus, or bad connections, I pulled the chips and tried to dump them, my EPROM reader complained about bad pins, and when told to ignore them and dump anyway, the output did not match the MAME set.
The 03 ROM chip had 8 pins show up as "out of spec" and the 04 ROM chip had 1. While I had the 03 chip out I powered up the board and most of the jail bars were gone, the screen was still a blocky mess which wasnt that surprising considering half the data set was now full of zeros, but I was left with very thin 1 pixel wide jailbars, so the fat jailbars travel with the 04 PROM.
Looking carefully at the original fault its clear that there is a thick band of green about 8 pixels wide and a one pixel stripe alongside of white. The thin and thick are related to each mask ROM. When I shorted out the pin next to the dead pin and got some of its signal into the missing line then the jailbar would vanish altogether.
Simple task of finding the correct MAME set (most zips only have the program and sound data - no gfx dumps for some reason) and burning 2 new replacement EPROMS. Except I didn't have these chips in stock, had to wait 2 bloody weeks for some to arrive from an Ebay seller overseas.
When they did...
Fixed! Could have saved myself a couple of hours if I had hit the mask roms sooner but at least there was some logic to my wild goose chase. Sprayed some laquer on the regions I had worked in, and covered the area with the scratches up too, job done!
