I picked a Gundhara PCB recently on the forum, it was advertised as a bootleg but it strongly resembled the strange Daioh I got recently and obviously came from the same factory. I think the most likely explanation for these boards is that the factory actually making Allumer boards started making a few side projects of their own, probably without permission which would technically make them a bootleg even if all the parts are correct. That or they’re weird short runs for China or something.
Sadly one of the things that made the owner think it was a bootleg turned out to be the sound. It was sort of weak and muddled sounding, making odd thump sounds in time to the music where just drums should be, and so on. Before we talk about the issues, let’s take a look at the PCB. By the way, the ROMs are identical to a normal board, just split into smaller pieces.
Someone had definitely noticed the problem and worked on this PCB before. Extensively. The sound chip has been reflowed or replaced, the sound RAM had been socketed (badly), most of the caps and the op-amp had been replaced (badly). I’ve colour boxed a few of the components for discussion, but this is what the PCB sounded like. You’ll have to excuse the audio quality, my phone picked up the screen whistling as well as the audio.
After quite a bit of diagnosis I found two separate problems. Firstly some buzz was being introduced into the audio by a pair of 74LS273s which I’ve marked in purple. It was only slight unless placing my finger near either of the chips, the closer I got the worse the sound became. This one was actually a design flaw – someone forgot to actually hook up the clear pin on the 273s – as far as I can tell the tracks go nowhere. Won’t spend too much time on this part suffice to say that running a wire up to the other purple boxed 273 clear fixes this problem, it’s actually tied to the CPU reset circuit. Other pins to tap that from are closer, but that was the tidiest fix I could see.
So on to the real problem – what was causing the corruption? The RAM was fine and the ROMs verified to match the set in MAME when combined. Well it took me a while to spot but it was pretty simple in terms of the fault. The RAM, ROM and sound chip (bottom left yellow + red box, plus the quad next to them) share an 8 bit data bus. On a standard data bus only one chip can be actively in output mode while multiple can be inputs. The ROMs are controlled by an /OE signal (inverted Output Enable), which means that when /OE is pulled low the chip will start to output. ROM 30 was fine, but 31 was stuck low. This means that any time something went to read the RAM or ROM 30 on the bus, it also got ROM 31 mingled in too. I’m actually surprised the game even sounded like it did.
I traced the /OE lines and eventually found they both connected to a PAL chip also boxed in red. This is a programmable logic chip and therefore custom, they really can be the death of a board if you can’t find a working one and dump it. Problem is, as far as I could tell the components surrounding the PAL looked OK, and being a unique PCB there was no dump. I compared to Daioh but it was too different to be of much use, I actually thought the game was irrepairable at this point.
And while thinking about the problem, I had an idea. Proper control of ROM 31 was no longer possible, but logically the required behaviour was simple – ROM 31 needed to not output if the RAM or ROM 30 were. Flip that around a moment and ROM 31 could always output unless ROM 30 or the RAM wanted to. ROM 30 would be active when /OE was low, and the RAM would be active if /OE was low and /WE was high. And so I came up with this:
Using two chips, the above behaviour can be achieved. Firstly the RAM, we want to perform an AND function (/OE low AND /WE high), but AND operations require two signals to be the same. The first thing we do then is to put /OE through a 74LS04 which is an inverter. The two signals then go to one of the gates in a 74LS00 quad NAND gate. When /OE on the RAM is low and /WE is high, LS04/LS00 combination will output a low signal. The remaining step is that if the RAM is outputting OR ROM 30 is, ROM 31 must have /OE high, shutting it off. We take the combined RAM low signal and ROM 31 /OE and pass those through another of the NAND gates. The end result is that if either the RAM is active or ROM 30 is active (and therefore low signals), the second NAND gate will output high, but if both are high signals it will output low. Connect that up to ROM 31 /OE and we have a ROM which automatically outputs when neither of the other chips try to. Seeing the datasheets helps to understand this:
So I knocked up an extremely Heath Robinson looking prototype fix, and burned a replacement ROM 31 since I didn’t want to damage the original while bending the leg upwards to disconnecting it from the faulty PAL output.
And then I powered it on not really knowing what to expect, and … it worked. I haven’t played through the whole game or checked every possible combination of sounds, but the things which were obviously completely wrong actually sounded OK. Here’s how it sounds now. Again apologies for audio, got the volume wrong and the mic started to auto adjust during the recording, there aren’t volume drops in reality.
Feeling pretty smug with myself, the only thing left to do was pull the contraption off and make tidy permanent repairs. I managed to get the required chip count down to 1 additional chip by using an unused inverter on the 74HC04 boxed in yellow. Quite often if you hunt around on PCBs you can find unused sections in dual/quad chips. The rest has to be done with piggybacking and some kynar patch wire, and to make things tidier I found some unused jumpers on the board and turned those into through hole links rather than soldering to the socketed chips. The finished repairs look something like this:
Usually when I fix games it’s direct repairs to faults, this is the first time I’ve actually had to work around a component and had a happy end result. Of course not everything went to plan, after putting the final fix on and despite only a few weeks ago telling someone off for putting a ROM in backwards and frying it – that’s exactly what I did, and I ended up having to make a replacement ROM 31 anyway.
