Rainbow Islands Repair Logs
Repairer: Womble
Been a bit dead on the old arcade front, but recently something very tasty appeared in the post...
Got a faulty original Rainbow Islands board as part of a board swap deal, I like faulty, faulty is a challenge, when powered up it gave a blank white screen and did nothing else.
A quick visual check showed no signs of abuse, a couple of PALs had been resoldered which was a slightly concerning. There was one smoothing cap that had been wrenched to one side tearing its leg out, one of the SIP packages had been badly bent to one side and a stray ceramic cap was included as loose. From photos on the web it was clear that this ceramic cap should be strung between the ground a Vcc pins on a large Taito SPDIP chip, and there was remnants of solder on those pins so I put it back, also replaced the smoothing cap. These are really only there to fill in any ripples in the power supply and its extremely unlikely to be causing a fault on its own, the board is just less tolerant of crappy power without them. The only risk with a damaged cap is that it is shorted out internally, which is why I removed it straight off. Finally I removed the extra power cables that someone had added to the 5V and the ground pads on the jamma connector.
First port of call with a non-starter board is the CPU RESET pin, which on this board was slowly pulsing from logic low to high and back, this is the watchdog "barking". Its a small circuit that listens for activity on the CPU busses, if it sees no activity it assumes the board has crashed and issues a reset signal. This is designed to stop a crashed board sitting in a jammed state in a cab for hours and hours burning whatever image into the screen, and also to keep the coins flowing, a crashed arcade machine doesn't make much money. At this stage I dumped the eproms to check the software the board was trying to run was OK, no point looking for a hardware fault when the board is trying to run corrupt code, all the EPROMs dumped and were identical to the mame set rainbowo (Rainbow Islands Original). The mask roms are an odd pinout but they contain gfx data so would not stop the board from running, if they were bad the gfx would be a mess but the game would run.
Going round the CPU with the scope showed very little activity, the CPU was getting its clock signal but doing nothing. There were signs that the board had been wet at some stage around the CPU so I wanted to test that the CPU was OK, the only problem was that the CPU was soldered directly to the board so I removed it.
By desoldering the CPU I could test it in another board, and by fitting a socket I could wheel out the big gun, ie my Fluke 9010 and the newly arrived 68000 CPU pod. On a closed microprocessor system the CPU on the board can only run the instructions in the ROMs and has to obey all the signals given to it by the board. The Fluke 9010 with the CPU pod allows me to run various tests on the board to see what a real CPU would see, the only other way to achieve this would be to design specific ROMs for the board but as the board is faulty it may not be well enough to run any code at all.
The CPU turned out to be fine as it ran in my Golden Axe board quite happily, once I had fitted a large 64 pin CPU socket to the board I told the fluke to ignore the Reset pin, and to perform a bus test, all this does is see if it can toggle the data lines, the address lines and the IO lines. Any lines that are stuck indicate a fault with some other device on that bus, usually logic chips, RAMs and ROMs. The test passed fine, at which point I gave up for the night, the next time I fired it up the same test failed, then passed, then failed and then passed every repeat. The error reported was data lines D13 and D14 stuck.
By going over the board with the continuity tester (beep test) on my multimeter I narrowed down what was on the data bus, a bank of 4 EPROMs, 2 mask ROMs and 2 6264 SRAM chips. The EPROMs and Mask ROMs were all socketed so it was easy to rule them out, I just pulled them off the board and re-ran the Bus test, and got the same fault, so the fault was with the SRAM.
The 68000 CPU is a 16 bit CPU meaning it expects 16 bits of data for every address location it specifies. The ROMs and SRAMs were all 8 bit, meaning they have 8 data lines so when fed an address they can only spit out 8 bits. So the ROMs and RAM were wired in pairs and strung across the data bus, so ROM 10 contributes the higher 8 bits of data and ROM 11 provides the lower. Data lines D13 and D14 were therefore only on one of the chips - the Sony CXK5864-10 at location IC25. So I desoldered it and repeated the bus test, the fault never reappeared, it also helped that the chip failed the SRAM test feature on my eprom reader.
The Fluke 9010 hooked up to the CPU socket with its 68000 Pod, you can just see on the main unit screen "BUS TEST OK"
I soldered in 2x14 pin sockets to make a 28 pin socket for a 6264 SRAM from a salvage board and fired the board up, same fault, white screen no activity.
At this point I went off on a tangent, having the Fluke (which I am still learning to use) gives me a huge amount of test options, the most useful being using the actual board to confirm if the CPU can read the ROMs correctly. I knew the ROMs contained the correct data, but not whether the CPU could call up and read that data correctly. The 9010 uses a ROM signature code to determine if the ROMs are readable, there is an app to generate the fluke code from the rom dumps I took from the EPROMS. If the 9010 can read the ROM contents ok it will give me the same signature code. The trouble was it didn't and this is where I spent a lot of time, firstly I had to interleave the data from a pair of EPROMs to get a 16 bit image of the ROM, ie the HI and LO bytes interleaved correctly. Once I had this file I set the 9010 to work, obviously you need to know where the ROMs actually lie within the address space, and thankfully this info is contained within the MAME driver for games.
ROM_START(rainbowo)
ROM_REGION(0x80000, REGION_CPU1, 0)<----- This is the 68000 CPU section
ROM_LOAD16_BYTE("b22-10.19", 0x00000, 0x10000, 0x3b013495) - These two are interleaved
ROM_LOAD16_BYTE("b22-11.20", 0x00001, 0x10000, 0x80041a3d) - when view from a 16bit CPU
ROM_LOAD16_BYTE("b22-08.21", 0x20000, 0x10000, 0x962fb845) - These two are interleaved
ROM_LOAD16_BYTE("b22-09.22", 0x20001, 0x10000, 0xf43efa27) - when view from a 16bit CPU
ROM_LOAD16_BYTE("b22-03.23", 0x40000, 0x20000, 0x3ebb0fb8) - Mask ROM
ROM_LOAD16_BYTE("b22-04.24", 0x40001, 0x20000, 0x91625e7f) - Mask ROM
ROM_REGION(0x1c000, REGION_CPU2, 0)<---- This is the Z80 CPU and its address space.
ROM_LOAD("b22-14.43", 0x00000, 0x4000, 0x113c1a5b)
ROM_CONTINUE(0x10000, 0xc000)
So from the above I should be able to read data from address 0x0 to the end address of the ROM pair which is 0x1FFFF and get a valid signature back, except I didn't, it always came back with a differing sig code. Pointing the scope at the address and data lines while this was going on showed odd spikes, not really valid logic signals and these were always present when when the test was not running. I also noticed a distinct lack of life on the WR and OE pins on the RAM and ROMs, these tracked back to the PALs that had been resoldered, one of which had a floating output pin which I took to mean it was probably damaged, they had the original Taito part number on top but I had no idea why they had been resoldered, or even if they had been off the board. I was further discouraged by the lack of ability to get the fluke to read and sense from the RAM too.
The 9010 also has RAM test functions, again you specify an address range and tell it to go and read/write test to that address space, this test failed too. I was beginning to wonder if the 68000 pod was ok, this was the 1st non Sega system 16/18 board I had tried it on and have heard that it doesn't play nice with the Sega boards, so as I was not getting what I was expecting was either going to be due to the board fault, or a fault with the 68000 CPU pod.
The strange thing was that when I fired up a hex editor on my interleaved file and told the 9010 to get data from anywhere in the address space I always got the answer I was expecting. I tried dozens of loci and always got the right data back, right through the address space. So it looked like the board could be read but probably not at any great speed, which brought up the question of the odd spikes on the scope.
Had my desoldering iron not shat itself I probably would have desoldered the remaining Sony CXK5864 chip a lot sooner, it would have made sense seeing as its partner chip was faulty. Had a new desolder head on order from the US so I pulled the chip out as soon as it arrived.
The chip tested as very faulty and also turned out to be the cause of the noise on the bus. With a another couple of 14 pin machined pin sockets on board and a new SRAM chip the board.... booted!!!!
The game was up and running, but the colours were wrong, from the outset I had been concerned about a large SIP package called TC0070RGB - RBG suggesting it was involved in the colour system.
It had been pushed all the way to one side and some of the pins looked like they had been torn off. The video output was very sensitive to this chip being touched, getting far worse and or perfect from time to time.
These SIP boards are very fragile and often completely missing from old boards as they get bashed off. I tried re-flowing the solder from the upper side and although this changed the fault it didn't fix it, so I had to bit the bullet and remove the SIP package in its entirety.
A number of pins turned out to be totally unconnected and fell out of the board when the solder melted. In total 4 pins had not survived and as the SIP board is dual sided it looked like a number of pins only connected to onside of the board. Micro surgery time - I managed to reflow the solder on the remaining pins to bridge the gap between the two sides of the board, then had to make new legs out of LED leg cutoffs bent at the tip like hockey sticks.
Using solder as a structural material is never a good idea but in this case I had limited options, I considered mounting the SIP on a ribbon cable but I had no idea if the signals would like the extra wiring, so in the end I opted to make new legs and solder the SIP back in place.
I had to use a mini file to get back to non-oxidised metal on the leg stumps and carefully soldered the LED offcuts in place. I left the new legs longer than the old ones so I knew which ones I had to be very careful and quick when soldering into the board. Once it was back in, I connected the board, flipped the switch and...
...perfect!
Will probably have to make a case for this PCB, that SIP colour mixer package is always going to be very very fragile, but at least she works again :)