PCB Repair Logs Wonderboy
Wonderboy
 |
|
| PCB Image | Reserved |
|---|---|
| Pin Out | Reserved |
Repairer: Womble
Forum Thread: Wonderboy PCB Repair
Bought this original Sega Wonderboy board on ebay recently as a buy-it-now-before-anyone-else-sees-it, seller said "nothing comes up on the screen when plugged in, good for scrap".
Was not really surprising as I could see it wouldn't work from this photo they put up.
Firstly there was a ROM missing, secondly 2 of the ROMs were in the sockets the wrong way round, thirdly it obviously had Mitsubishi double-decker ROMs in the graphics section. I have never found one of these Mitsubishi ROMs that still works, most appear to be fine but contain gibberish, if you can manage to erase one fully (tricky) and reprogram it (trickier) it will probably only hold the data for an hour or so before the bits start dropping away. There was also tape across the back of the board which had "bad graphics" on it - probably due to the Mitsubishi chips.
When I got the board one of the Z80 had fallen out during transit and the remaining Z80 on the board had "BAD" written on it in marker pen.
There didn't seem much point powering it up as it was. The EPROMs in backwards were always likely to be toast and my reader confirmed this, shame really as they were decent chips and I am short of that size. I was hoping someone had taken them off to test and then just put them back wrongly, if they hadn't powered up the board they would have been ok. My tester also confirmed that the Mitsubishi M5l2764s were shot, they read ok but WinRomIdent didn't recognise them.
The remaining ROMs did read and dump OK but all of the ROMs in the main bank were in the wrong sockets. So I burnt new ROMs to fill the gaps, and put the working ROMs where they should be. I also had to made up a JAMMA adaptor for the board, a simple one initially that had the power, RGB, sync and speaker connections. I then powered it up - and got a totally blank black screen.
The board was getting power, the Z80s were getting clock and were not in RESET or HALT mode so I started probing around. I initially went for the RGB lines and sync and found I had nothing at all, not even sync. There was some activity on the board but generally it was very quiet. I tracked back from the RGB to a set of 3 resistor networks, one for each colour channel and confirmed that the input to the network was dead on each one, the inputs all went to the outputs on a couple of 74LS175s at IC07 and IC08...
...which were always going to be doing nothing as their MR pin was held low, these were joined and tracked waaay back across the board to the Q (output) 74LS109 at IC69. These chips have 5 inputs, the RESET pin was tied high so the chip was active, the clock pin was getting a clock signal and the remaining pins (clear, J and K) were all tied together and attached to a track that went to a 7425 chip at IC90, this chip had pin 3 tied to 5volts via a current limiting resistor, pins 4 and 5 were also tied together which left pins 1 and 2 as inputs. These both went to custom chips, pin one to the 7114 PROM labelled PR5317 and pin 2 to a PAL with the Sega ID 315-5063, neither of which I could verify, but it looked rather like the video was not being initiated rather than there being a fault preventing it from working.
At this point it dawned on me that I was wasting my time as the board was probably missing something rather critical - the right CPU!!! I have fixed a couple of Wonderboys before but neither were quite as dead as this one, all had used stock Z80s so they arrived at my door with the unencrypted code already in the ROMs.
Sega originals usually used encrypted executable code, and to run that code you had to have the right CPU that contained extra circuitry that re-arrange the code before it was run on the CPU core, try to use a standard Z80 and it will crash because the ROMs contain gibberish as far as a normal CPU is concerned. This was to stop the operators from burning ROMs and upgrading the boards to a new game without throwing some coin to Sega. As they needed a hardware device (i.e. the right CPU) they had to pay for each game, copying your mates ROMs was pointless.
Luckily there is a decrypted version available for this board layout, Wonderboy came in a couple of variations in terms of ROM layout and the romset "wboyu" had the right layout for this board and only needed a few ROMs to be reprogrammed. As soon as this was done the board leapt into life, by the way the Z80 that had "BAD" written on it works perfectly so I don't know what that was about, perhaps a previous owner got the board after the CPU had been pinched, and only had one Z80 to test, thereby coming to the conclusion it was duff as it did nothing on the board. The death of the Mitsubishi EPROMs was probably the original fault, hence the masking tape message, and the CPU got pinched as a spare.
With correct code for a normal Z80 the game was now running but the title screen background was solid cyan, sometimes the whole screen..
.. sometimes just a thick stripe down the middle of the screen.
In the game things were much weirder, the colours where totally wrong for the in game graphics...
...so wrong it looked like the harness was wired up incorrectly, but the graphics for the health and life section of the screen were the correct colour.
The Wonderboy sprite was also a bit unstable, sometimes the "walking" sprite was torn up and only came good when he jumped or was on his skateboard. Probably the oddest issue was that the Wonderboy sprite was actually behind the background and was only visible when he jumped above the line of the red bushes or got out of the forest.
As the board has a smattering of Fujitsu TTL chips I started with those and found a couple of LS153s at IC9 and IC28 with missing outputs, when these were both replaced the background went black, better but it should be a beige colour.
The final crazy colours and the "behind the background" issues were traced to an 74LS377 at IC19...
..again it was a Fujitsu chip but it didn't have the usual give-away missing output fault, it was just hyper sensitive to touch, when its pins were touched the Wonderboy sprite would totally mess up, often be drawn as a torn up mess of horizontal lines, irrespective of whether he was jumping or not, the splash screen did this...
... which kinda gave away that the 377 was involved.
Replacing this chip had a dramatic effect, the colours of the landscape were suddenly correct, Wonderboy himself was back in the foreground again and rock solid again, the splash screen background was also the correct colour.
As the 377 and the pair of 153s were all in the same area of the board as 3 other Fujitsu 153s I replaced those too, nothing changed but those chips are almost certain to cause trouble in the near future so the board is better off without them.
At this point the game was almost perfect, the only remaining issue was that there was usually some lines of rubbish drawn on the screen down the left hand side, it seemed to come in 3 levels of "wrong". On some occasions the game would boot up and be perfect, on some occasions there were only a very few lines of crap but most of the time the rubbish was all down the left hand side.
Whatever state I got when I booted the game was how it would stay until it was powered off, no matter how many times the screen display changed, something somewhere was getting stuck.
To be honest these sort of problems are the worst to troubleshoot, when are board does nothing the difference between it and a good board is very obvious. When a board does 99.99% the right thing and is only 0.01% wrong it can be almost impossible to spot where the fault is. Nothing showed up on the scope as being unusual, there were a couple of crappy Fujitsu 245s left to replace but any interruption to these crashed the board so they were unlikely to be involved with a graphics fault. The fault looked like something that happened extremely briefly when the board was powered up, the junk on the screen stayed present throughout the game and never changed, on power cycling the board it would be present in one of the three degrees of faulty, perfect, nearly perfect or full screen side of rubbish as in the last photo.
So I tested the smoothing caps across the power rails and they were all fine and had a poke around the reset system looking for anything that might be starting the board too soon, nothing stood out. So I started at the beginning, the ROMs, probing around the board I could not find a single area that affected the graphics artefacts, I could aggravate it in about 5 different regions of the board. So I started at the beginning, and pulled out the entire bank of 6 ROMs IC61 to IC66 and powered up the board. A lot of things were missing, and blocks of colour were gliding about the screen instead of the actual graphics, but the fault was still there, so those ROMs had nothing to do with it. The remaining 7 ROMs on the board (ignoring the sound CPU ROM) were the only place this junk could be coming from.
I didn't expect to get very far in pulling these out one by one as the main game code lives somewhere in that bank, if by pulling a ROM you take out a lump of the executable code you end up with a board that wont boot, which doesn't actually help much in isolating a minor fault. It turns out the at the game code only lives in the 1st EPROM and I hit the fault before I got that far, by removing the EPROM at IC110 the fault vanished, along with a the Wonderboy and Girl figures on the splash screen and some in game artefacts. The first thing to do was to replace the EPROM with another one to see if it was the chip itself. So I burnt a copy of the relevant data into a new 27C128 and dropped it in, the fault came back.
Buzzing round with the continuity tester I could see the data and address lines were connected up in a sane way with nothing missing.
The only thing left was the method of enabling the chip to output its data. On all EPROMs I have ever seen from the 80-90s arcade era there are two pins that control when the chip can "speak". Usually you have multiple chips sharing the same address bus and data bus, therefore all the chips in the stack hear which address location the CPU is asking for information from, and each chip has a location referenced by this address. Only one chip must be allowed to use the data bus at any given time, if you have more than one talker the data gets corrupted.
The high address lines on the CPU usually go into a logic system which selects which chip the CPU is actually wanting information from, the logic drags that EPROMs OE(output enable) pin and holds all the other ROMs OE pins high, the chip with the low OE pin is the only one that can speak. The other pin is actually a blanket enable pin, often called E or G depending on the manufacturer. This pin determines whether the EPROM is actually enabled, when it is logic high the chip is in a low power standby mode, when low the chip is active. Often these E pins are tied to ground so the chip is always enabled, it takes far longer for a chip to come out of its standby mode than it takes for it to be told to shut up via its OE pin so its not normally used as a way to control the chips on a running board when data is needed in a hurry.
On Wonderboy the E pin on IC110 is not grounded, it is actually connected to the E pin on the EPROM at IC117 and then it goes off to a 40 pin Sega custom IC called 351-5011 (which combined with the fat custom 5012 next door are system controllers according to Google, pinouts sadly I could not find), finding customs in a fault path is never good, there's no datasheets on what they do, no way to test them and usually no spares handy to do a straight swap. Pulling out IC117 didn't help the fault at all, it just removed more of the graphics data but the issue remained.
Anyway as the E pin is the less likely candidate for the fault I focused on the OE pin, which went off to a 74ls74 at IC06, this seemed to be doing the right thing on the scope, in fact the line was active and healthy looking, the fact that this fault only occurred at power on and then remained suggested that pretty much everything was fine except for a very brief period. The E pin is held low at all times anyway, its just controlled by the custom chip rather than being tied to ground.
At this point I ran out of puff, the board sat on the spare bed for a couple of weeks, I had already spent about 8 hours on it to this point and the custom chip kinda discouraged me.
When I finally got back to it I picked up where I left off and pointed a scope at the E pin, this did connect to pin 38 pin on the custom chip, plus the E pin on the EPROM at IC117 but it also went to the E pin on a 2148 SRAM at IC100. The outputs on this chip looked ok on the scope but it seemed plausible that it was failing in a way that meant it took longer to come out of disable mode, or that the combined load of the 2 EPROMs on the E line meant the signal to it was now borderline. It was a simple theory to test, desoldered the DRAM chip...
...grabbed one off the badly scrapped Wonderboy board I was given a while ago (sadly the custom chips had already been robbed from this one), fitted an 18 pin machined pin socket to the board and dropped in the chip.
The fault was gone and stayed gone on subsequent reboots of the board, graphically the game was perfect again.
Next concern was that I still had not heard a single sound from the board. The JAMMA adaptor I had made had only the power, video and speaker wires connected, and the boards dipswitch was set to enable Demo Sound but it was silent. The amp seemed ok as I could introduce static by touching the underside of the board and its pins. Another issue was I could not set the game to free play either. I added the coin up and 1P start wires to the harness and started the game, and got sound, effects and music which confirmed the dipswitches were not working properly, mainly dipswitch bank B which handles attract mode sound and free play. These 8 dipswich blocks are often "read" by 74ls253 or 74ls257 chips on arcade boards, and these are known to die, presumably of boredom. On this PCB each bank had a 74LS257 connected up, both were Fujitsu chips. All of the outputs were active, but if an input had died this would explain the behaviour. I am now of the opinion that its not the chip core that dies on these Fujitsu TTLs but it is the microscopic wire from the pin to the pad on the chip core that fractures or corrodes away leaving pins disconnected. I took the pair of 257s off and tested them, , the 1st one was good but the one associated with dip bank B failed its test. When a couple of new (non Fujitsu) were put in it fixed the last issue, I can now set free play!
The game is finally fixed, only thing left to do is to print some labels for the EPROM chips! There are half a dozen Fujitsu TTLs left on the board, I will probably replace these in one shot, they will probably take down the board at some stage in the future, but for now she's healthy again
