Ghost'n Goblins (Bootleg) Repair Logs

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Repairer: Asayuki

Date: 6/Aug/2016

Symptom: Locks up at boot

As this game was one of the prominent titles on my wanted list, I was quite happy when I bought this board, which has been sold to me as a working bootleg. As it usually happens with "working" boards, I was expecting this one to show glitches and other minor issues once fired up. It came in on a monday with the courier but it had to wait until friday before I could turn it on.

I was extremely surprised to see how good this board was running, and it kept me entertained for the entire evening without showing any problem whatsoever. On the next monday I wanted to enjoy it with a couple of colleagues in the office which I know are particularly fond of this game, and that's when the board completely refused to start up. ...demo effect! I just got this black screen with vertical white stripes. Thinking it must have been something very easy I double-checked every connection and voltages, tried to reseat the EPROMs and ribbon cables and also searched for loose joints by hitting both boards everywhere with the handle of the screwdriver. Nothing; there was a broken part somewhere, and I wanted to get rid of the issue in no more than 30 minutes. Little I knew of the odissey I was embarking onto...

Hmpf! Ok, let's have a look around. The scope showed the presence of the sync as expected, and the pins of the CPU where all doing something. Clock was there, wide and stable at 6MHz. MAME says that the CPU runs at 1.5MHz which is true but misleading: the CPU internally divides the clock by 4 to derive quadrature pulses for accessing the bus; therefore the core is running at 1.5MHz but the clock signal at the input pin is 6MHz. A quick look at the reset signal gave me the impression that it was rising together with the sync signal, which is too early for my taste. No time for a proper investigation of the reset line; let's just replace this 10uF capacitor. The cap measured 8uF with an ESR of 5 ohms. I had a couple of 47uF parts around so I just smashed one in and flipped the switch. Nothing changed, but the reset signal was now rising around half a second later than the sync signal, which is good.

Thanks to some good soul who made them available a couple of years ago, the schematics for this board are available. The first thing that called for my attention was the IRQ# signal, which pulsed high when the board booted then went low and stayed like that. Now, according to the datasheet of the 6809, the BA and BS pin signal the internal status of the CPU similar to what the 68k does. In particular BA low and BS high means that the CPU has accepted an IRQ. The 74LS74 and the 74LS139 at 9J and 9K latch the interrupt coming from the hardware and clear it when the CPU confirms to have started serving it. This was not happening because BA and BS never went to the IRQ acknowledge state, but IRQ signals can be masked by an interrupt disable bit so this does not necessarily mean that the CPU is bad, and indeed interrupts are disabled by default when the CPU resets. The HALT# signal was high as expected, but the MRDY# signal was stuck low. According to the datasheet this is not good, because when this signal is low then the memory is (counter-intuitively) not ready yet and requires the CPU to stretch the access cycle. I followed that back up to the 74LS08 at 7K whose pin 8 was not reflecting the status of the input pins 9 and 10. Bingo! This must be it. I replaced the 74LS08 with a new one and got this.

Oh come on! Well, there are no other pins to check on the CPU, so maybe it can't execute code and crashes right away. The first thing I tried was to socket and replace the CPU RAM and the text layer RAM, without succes. I dumped the CPU code EPROMs, but they were all good. Ok, then it must be some addressing issue. Figuring out the addressing logic wasn't straightforward: Capcom has made some clever design there to allow the use of 27C128 memories as well as 27C256 ones. Looking at the schematic as it is doesn't make much sense: it seems that the top half of 8N and 12N is never accessed. That is actually not true because the chip that is mounted at 8L is not a 74LS08 as it seems from the schematic; it actually is a 74LS21 which is a quad input and gate. So the gates with the funny dots inside are actually paired when 27C256 memories are installed. In order to install 27C128 memories, the chip at 8L needs to be replaced with a 74LS08. With this notion the schematic finally made sense. The 27C256 EPROM at 8N contains the code from $8000 to $FFFF. The 27C128 EPROM at 10N contains the code from $6000 to $8000 and the area from $4000 to $5FFF is banked. There are 5 banks available, 4 of which are stored in the 27C256 EPROM at 12N while the 5th is stored in the remaining half of the 27C128 EPROM at 10N. The reset pointer at $FFFE-$FFFF points to $6000 and I needed to make sure that the CPU would read and execute the right thing. But before embarking in this debugging effort I tried replacing the CPU, which was on my suspect list since a while already. No luck: the problem persisted even with the new CPU. By using the reset timing diagram in the 6809 datasheet I first ensured that the CPU was fetching the reset vector.

I didn't feel like investing a lot of time to setup the logic analyzer (which I rather should have!), therefore I poked my probes to reset, the EPROM's CE# signals and one data line at the time to note down the contents of each bit fetched by the CPU. And yes, the CPU was fetching the reset vector and then reading at least 16 bytes of proper code from the proper EPROM. Well ok, but if this works then why is the CPU crashing or locking up? I fired up MAME using its -debug option to check what the code was actually doing. I knew absolutely nothing about this CPU, but the datasheet also has a list of opcode that seemed quite useful; plus, MAME has a detailed memory map of the board which has been very helpful.

$6000 orcc #$50

$6002 ldx #$1E00

$6005 ldy #$0060

$6009 ldd #$F8F8

$600C std ,X++

$600E std ,X++

$6010 leay -$1,Y

$6012 bne $600C

$6014 ldb #$64

$6016 sync

$6017 lda $3C00

$601A nop

$601B nop

$601C nop

$601D decb

$601E bne $6016

The first part of the code is basically filling the sprite RAM from $1E00 to $1F7F with $F8. Then there's this part I didn't understand which loops 100 times in a row the execution of a SYNC instruction and a read from $3C00 whose value is then discarded. By looking at the BS and BA signals I found out that as soon as the sync instruction got executed the CPU went into "waiting sync" mode, sensed an IRQ, executed the lda $3C00 instruction and finally seemed to die there. The sync instruction halts the CPU until an interrupt arrives, which is a nice way to synchronize with the video circuitry if your IRQ# line is wired up to the vertical blanking signal generated in hardware as it is the case with this board. Now according to MAME's source code the access at $3C00 is for the watchdog. No, this cannot be true; according to the schematic nobody can force the CPU to reset. So what does this memory access actually do? It triggers the sprite generator into updating itself!

The quite convoluted logic of the sprite generator at page 1 of the B board schematic sits there dormant until the CPU wakes it up by performing an access to $3C00 which ends up pulsing the OKOUT# signal. This triggers the sprite generator into sending a DMA request to the cpu via its pin 40 (HALT#) to then autonomously copy the contents of the CPU's RAM area $1E00-$1FFF into its internal 2114 RAM at 11E and 12E where it can access the data at will without disturbing the CPU any further. This also prevents graphic glitches on the sprites because the CPU can alter the sprite RAM anytime and finally apply the changes by waiting for the vertical sync and then asking the sprite generator to fetch the updated data.

Checking with the scope on a larger scale verified that all this was actually happening, but at the end of the DMA cycle the CPU wouldn't resume executing, which was puzzling. It turned out that at the end of the DMA cycle MRDY# was stuck low again. Thinking that the problem might have been on the B board, I disconnected it and fired up the A board alone. Surprise surprise, the CPU went on seamlessly without locking up, performed the ROM check and the RAM check, both checks passed and I got presented with the title screen. No sprites and background, of course, but the board booted! I turned off again, reconnected the B board and started considering what to check next while flipping the power switch. I wasn't even looking at the screen and was assorted in my toughts when all of a sudden I heard the game's main tune. WTF?!? The game was happily playing...

Flexing the ribbon cables affected the sprites and background layers in a very serious way and even managed to make the CPU crash. @#$%£&%!!!! I went and checked the ribbon cables, cleaned all the contacts and resoldered the receptacles on both boards and the problem seemed to be finally gone. Now, however, there were funny graphics glitches on the background and text layers. Two separate problems, one depending on vibration and the other only appearing when the board warmed up. SIGH! I decided to clean all the socketed EPROMs and dump them while I was there. All of them matched MAME's signatures for World set 1 and, after cleaning and reseating everything, the board became finally resilient to bending and vibration.

As the glitch on the text layer was heat dependent, I took the freezer spray out of the closet. Two integrated circuits proved to be heat sensitive: the 74LS74 at 4M and the 74LS194 at 11D. Once socketed and replaced, there was no more sign of glitches. I applied some more heavy vibration and bending punishment to this bootleg and then finally felt happy of the result. I let the board run while cleaning up the desk, played a couple of credits and then abandoned my game pad and started writing this log while still watching the board from time to time.

All of a sudden, the screen went black and the monitor started blinking its LED.... "No signal". WHAAAAT??? Poked the scope at the sync signal: stuck low. Poked the scope at the CPU: a corpse. Poked the scope at the 12MHz crystal: also dead. Was power reaching to the 74LS04 at 3N? Yes. I replaced the 74LS04 and the board started again. I left it running for another 4 hours and subjected it to more punishment, but without seeing any other issue. Happy ending?

Let's just hope I'm good with bad luck for the next couple of months! But hey, I own a Ghosts 'n Goblins board now! :)

Update: 19/Aug/2016

A few days after the repair, right when it was showtime, the board developed another fault. Every time I powered it up, the board would choose one of the following actions at random:

Play completely fine, and maybe crash 30-60 minutes later (most of the times).
Fail at boot with the message "ROM NO GOOD" and lock up.
Display random garbage, with colors changing about once per second while the speaker played a random sound effect from the game (or part of it).
Lock up in a completely white screen.

Wow! This would have been totally LOL if it wasn't for a subtle detail: randomly appearing issues are by far the most difficult to debug, because you can measure all you want without being able to find anything simply because everything works correctly except that one short moment which messes up everything. Let alone the fact that my previous repair lasted three days. I started to believe that this board was really possessed by the evil spirits contained in its ROMs, and they were haunting me! Needless to say, I have applied vibrations in all directions again and with several grades of force (from "let's check again" level up to "i'm really fed up" level). Obviously nothing, but it was worth a try. The "ROM NO GOOD" suggestion would normally be valuable, but at times it can be a false friend. Considering that there were times in which the board didn't even do anything else than lock up or display garbage without even taking the time required for ROM testing, I decided that the message was likely a side effect of the real issue rather than a direct consequence; otherwise the board would display it consistently instead of behaving this funny. But just to be on the safe side I redumped the program EPROMs one more time and also replaced their sockets which looked oxidized anyway. No cigar; the ROMs are still good. I also checked trace continuity from the EPROMs to the CPU. I found a couple funny looking spots on a couple of traces and decided to treat them as microfractures and bridge them anyway just to be sure. Still nothing. The CPU execution was however certainly falling into the void all of a sudden. But why? Also looking at the repair by Arcade King in this very same page, who had problems when the CPU accessed the work ram, I decided to replace all 74LS245 because they require quite some work to check and might be interfering with the CPU's bus at the wrong moment. All of them except one tested fine in my TTL tester, therefore I tought it was over. Played a game and after some time it crashed on me again. *SIGH*! Since the problem definitely was in the CPU reading crap from RAM or ROM all of a sudden, it must have had something to do with the addressing, therefore I socketed all ICs involved with the addressing path as shown on the first page of the schematic (see above 7L, 7K, 8L and 8K). I used the IC tester to verify them: all of the them tested good. I didn't believe that blindly therefore I replaced them anyway just to be on the safe side, but without result. Of course there are also banking bits coming from page 2, but all of them were toggling every now and then. I had however no way to know if they were taking the right values, so I wired up the logic analyzer to the three data bus inputs of the latch at 3C, the three banking bits at its outputs and triggered on its clock pulse.

The attentive guys have probably noticed that the B board is missing from the photo. This game will reach up to the title screen without batting an eye even if the B board is missing, therefore I didn't need it. After quite some triggers showing up correct values I managed to spot what is depicted in the photo below. As you can see, the data bus (represented by D[3:5]) tells the latch to store the value 011 = bank 2, but the outputs (represented by D[0..2]) remained at zero. The yellow trace at the top is the clock pulse to the latch.

Whatever the internal issue of this 74LS174 could be, it latched its input correctly most of the times but sometimes didn't. No wonder that the CPU crashed "randomly". It actually did at random bank changes! Socketing and replacing the IC finally solved the problem.

Repairer: GameDude
Forum Thread: Ghost'n Goblins (Bootleg) PCB Repair

Got this one from the same pile of PCB's as RYGAR. Its Ghost n Goblins and in my opinion bootleg or not damn worth spending the time to fix and I did.

To start with it was in a sorry state, bodgy repairs, PCB tracks that were vaporized by the touch of the last solder iron (this is more to do with the cheap PCb used by the bootleg), missing audio parts and half an AMP missing.

Start with the usual power up see whats happening and got a picture that composed of backgrounds only, no sprites and the foreground picture was fading in and out left to right. Sometimes there was just a shadow style edge and sometimes after warm up most of the text was there however only white. Of course no audio as well but I will deal with that later.

Started with the 2114 sprite ram in the middle of the video PCB (11e-12e-11h-12h-11j-12j), two had been poorly replaced but I left them for now and concentrated on the rest, they were all different indicating someone had a problem here before.

I piggybacked the ram and on one I got sprites back but with jailbar effect... a good start! I decided that someone elses crap repair was not worth relying on so I de-soldered all 6 2114's, checked continuity on all pins and wire bridged any damaged tracks as it happened only that previous repair was bad/damaged. I socketed all 6 and replaced with known good ram and got sprites back with no problems.

Ok moving on to the forground text I concentrated on the CPU PCB as its responsible for basic stuff like this, I used a scope to watch what was in the lines and looked for a signal similar to the distorted graphics. I found the signal near the main program ram opposite side to the audio, I traced it back through the circuit until I got to a 74LS157 (10c) third row in right where the audio is pins 1 and 2 were pulsing but pin 3 (output) was stuck high. Swapping had no effect so I went one up the chain from the output to a 74LS174 (4f) roughly in the middle of the PCB and swapped that and BINGO foreground text is back.

OK Problem 3 is the audio, one of the YM2203 (14e) was missing as well as one of the Y3014 op amp (14d) and the AMP itself, replaced all this but no audio - oops amp was in backwards an easy mistake when nothing is labeled on the PCB . OK Audio is OK for FM effects but crap for digital seems wrong, turned out the second Y3014 (13d) that was still on the PCB was totally dead, swapping that gave back all sound YAY!.

Problem 4 was strange, all color was OK except the lives and the weapon box was there but missing a color and was purple instead of white and browns, since this was part of the foreground I figured maybe still a bad chip or trace somewhere here, spent a few hours on the IC's and couldnt find anything wrong, on a hunch I decided to check the color ram 2148 and piggybacked a good ram on each in turn, on the middle 2148 ram (7d) I got a positive result so de-soldered and socketed the position and tried the new ram. New ram worked and I also now got the ram rom test screen on boot, I noticed in MAME it was there but not on the bootleg but put it down to maybe different rom set DOH! Well it works now.

Problem 5 showed up after a little playing I noticed just when you get to the area with the lifts a flash of yellow and sometimes some misplaced graphics showed, the misplaced graphics also affected the on screen interaction so I figured I will check the background ram but it seemed OK. Seeing as it works well up until then I figure maybe a ROM but if its bad it should always happen and it wasnt so I checked voltage on the PCB and had a .2volt drop from 4.85 to 4.65, a little to low so I wire linked GND and 5volt from the edge connector directly to the video PCB and now get a more healthy 4.8volts and no more problems

As it turns out one of the 2114's that was replaced by the last repair was totally dead so 2 of the 6 were bad.

It was a big job and took most of my Sunday but it is worth it for this game I think...

Update on that last problem, seems the V+ was not entirely the problem, it happens less but still there so time to check more IC. I started on the video board left side (background data) and given the problem and its intermittent behaviour decided to piggyback sections of LSxxx chips and see what happens. A positive result! no more background corruption on up/down scrolling, I played to the second level, there is a lift that goes up and down so while there I slowly removed the piggybacked chips till the problem happened.

As it turned out a LS157 @ 9c was the problem, it even compared OK in the comparitor... just flakey old crap I guess... anyway that last prob is now definately FIXED!

I also labeled all IC locations based on an original board which is pretty much the same except the bootleg is more spread out.

Repairer: Arcade King
Forum Thread: Ghost'n Goblins (Bootleg) PCB Repair

PCB looks like somebody had a previous shot at fixing the board(gun shot approach that is), so theres quite a few IC's already been replaced.

Board was dead with a blank screen blank screen. Immediately found dead chips 74ls74(F) @ 4M, 74ls08(F) @ 5L, 74ls00(F) @ F7, 74ls273(F) @ 8H and 2 X 74ls367(GSS) hex buffers (colour) @ 8A and C (these things almost blistered my finger!

At this point I've got a green screen with some random garbage for a few seconds when I turn it on.

I can't really find any other obvious fault at this point so I've decided to pull some of these Fujitsu 245's out to see if they come up good on my programmer. As I suspected H10 and 11 were both dead, replacing these the board boots up but im getting random crashes and garbage. Turning down the voltage I seem to get a longer run out of it. Looking at the schematics I decided to pull the 245 @ B3 although it tested ok once it warmed up it would fail. I'm starting to see a pattern with these (F)ucked) Fujitsu IC's so I'm going to replace the whole lot of the 245's just to play it safe, I know im only going to have to replace them down the track anyway. After replacing all of them the game is up and running with no sound.

Starting to get shitty with this board fix one problem and another chip fails right in front of my eyes.

Problem: Missing red out of the lower half of the GnG title and weapon box at the bottom of the screen wrong colour.
Fix: bad 74ls174(GSS) @ 4F

Problem: board just died with green screen.
Fix: Bad 74ls174(GSS) @ C3

Problem: Colour in Topscore text is randomly fluctuating from red to white.
Fix: Another bad 74ls174(GSS) @ 8F

Problem: all the text and GnG title is split in half and showing the top half at the bottom.
Fix: ANOTHER faulty 74ls174(GSS) @ E8. Pin 2 was stuck open (high) Starting to see a pattern with these 174's

Ok board seems stable time to look at that sound.

The YM2203C's and YM3014's were both already socketed so this should make life easier. Probing around I noticed the inputs were dead on one of the YM3014's, removed the YM2203 connected to it and I had sound FX, replaced the faulty YM2203 and while I got the music back only half of it was there. Problem turned out to be the YM3014.

I don't normally spend so much time on a PCB but I beleve this game is worth saving. As usual the majority of bad IC's were F chips but there were a few GSS's 174's in there also. Usually When an F chip dies the outputs just go dead so the GSS chips were a bit trickier to find. PCB seems to be 100%, will leave on on for a few hours to make sure nothing else shits itself.

BTW you can interchange the top and bottom board on this bootleg with an original Capcom PCB.

Ghost'n Goblins (Bootleg) Repair Logs

Navigation menu

Search