Arcade Otaku Wiki - User contributions [en-gb]

Frogger Repair Logs

2017-02-19T16:17:32Z

Asayuki: Fixed a typo, added three sentences at the end

'''Repairer:''' Asayuki

'''Date:''' 18/Feb/2017

'''Symptom:''' Too many frogs on screen.

I have acquired this board from a seller who wasn't saying absolutely anything about it. Sure it must have been broken somehow, yet the price was very nice; expecially considering that it's definitely an original, manufactured by Sega under license from Konami. The board required me to wire up an adapter, which I did quickly enough. While doing so, I noticed an empty socket in the bank of EPROMs for the CPU code and a torn off 8 pin IC at position U1 on the sound board. I was already fearing the worse, therefore I went looking for schematics before even turning on the board. The schematics show U1 is actually an µA741 op-amp which preamplifies the audio before feeding it through the volume pot to the power amplifier. Though, even with U1 missing (which requires -5V to be present) the 5.1k feedback resistor should allow the sound through. About the EPROM bank for the CPU code, MAME came to the rescue by highlighting the need for only three chips instead of four. Therefore the empty socket is actually meant to be empty, and maybe the torn off U1 is a factory patch. Very reliving. Anyway, once finished wiring up power, ground, video and speaker I finally powered up the board and got greeted by a swarm of frogs trying to march their way to take on the world!

[[File:Frogger_original_too_many_frogs.jpg|800px|frameless|center|Frogs trying to conquer the world (and failing miserably).]]

As you can see from the picture, the sprite of the frog trying to cross the street was repeated over and over again on the entire column (remember that the screen is vertical). Cars, crocodiles, logs and all the rest however looked fine. The reason why they looked fine is very simple: all those are not sprites! As MAME shows when pressing F4 and navigating to the layer display, most of the elements on screen are actually part of the background. The Galaxian hardware on which this game has been based most likely has the ability to vertically scroll each background column independently, which is a very interesting feature for the time. The only sprite used on screen is actually our frog hero.

To solve this riddle I needed a deep understanding of how the sprite rendering logic works. Thankfully this is very carefully explained in the comments of MAME's video driver for Galaxian. As it can be seen on the schematic, the sprite RAM is 256 bytes only, and is read each and every line in order to render a line worth of sprite data. Through a lookup in ROM the data is then fed directly into the line buffer (256 pixels, 6 bits per pixel), where some logic mixes it with and prioritises it against the background data. The line buffer is then rendered on screen and erased at the same time, ready for the next raster line. A quite convoluted mechanism that runs at about 6MHz and wouldn't have been easy to uderstand if it wasn't for MAME's documentation.

The entire logic is highly optimized to save costs, to the point that the comparison of the vertical sprite coordinates against the raster counter isn't easy to spot. The scope showed, as expected, sprite data being drawn every line endlessly. Tracing that back brought to IC78, a quad input NAND gate 74LS20. Its output was correct but extremely low in amplitude, which caused IC97 (74LS157) to never register a high logic level on pin 5.

[[File:Frogger_schematic_portion.jpg|800px|frameless|center|Schematic of the vertical position comparator.]]

The attentive ones among you surely noticed that the part is marked IC73 instead of IC78. That's a mistake on the schematic, and it unfortunately isn't the only one I've found...

[[File:Frogger_original_broken_IC78.jpg|800px|frameless|center|Guilty IC located.]]

Replacing the 74LS20 with a new one has elegantly solved the issue. And now that the graphics were fine, completing the adapter allowed me to finally play the game. Luckily the sound was absolutely fine, which proves that U1 has been intentionally removed by the factory. Great, because this means I won't be needing -5V for this board. :) All inputs are also fine, as proved by playing a game in cocktail mode. That seems to be all, then. It has been a quite interesting evening; now let's save some frogs! :P

[[File:Stage_clear.png|332px|frameless|center|Stage clear]]
[[File:LUCK-.png|332px|frameless|center|Lucky bonus]]

[[Category:Repair Logs]]

File:Frogger original broken IC78.jpg

2017-02-19T16:00:12Z

Asayuki: Frogger's video board. Highlighted is IC78, responsible of a fault.

Frogger's video board. Highlighted is IC78, responsible of a fault.

File:Frogger schematic portion.jpg

2017-02-19T15:57:06Z

Asayuki: A portion of the frogger schematic showing the CPU's RAM and ROM bank, the video RAM and the vertical coordinate comparator for the sprites.

A portion of the frogger schematic showing the CPU's RAM and ROM bank, the video RAM and the vertical coordinate comparator for the sprites.

File:Frogger original too many frogs.jpg

2017-02-19T15:35:32Z

Asayuki: A Sega / Gremlin Frogger board showing way too many frogs.

A Sega / Gremlin Frogger board showing way too many frogs.

Repair Equipment

2017-01-16T22:03:34Z

Asayuki: Added link to logic comparator

==Tools of the Trade==

===Basic Tools===

''These are items that every arcade fan should, and likely will, have readily available.''

#'''Soldering Iron''' - with as fine a tip as possible
#'''Solder Sucker/Desoldering Braid''' - this makes removing items from boards that much easier

===Basic Board Repair Tools===

''These are items which are fairly essential to the board repair process; and you will find the potential scope of your repairs somewhat limited without them.''

#'''Multimeter''' - if you are buying one, ensure it has a beeper for continuity testing. Checking tracks is hard enough without having to look up at the meter screen every time to see if you have a connection. If it beeps, its good and you can move on. Until recently, the ultra-cheap multimeters didn't have this audible feature, but reasonable meter's including this feature can now be had from eBay for as little as 6GBP at the time of writing (2010). The symbol for audible continuity on a meter is usually represented by the diode symbol plus a small picture of a speaker.
#'''Logic Probe''' - this sounds daunting and expensive but really isn't. It connects to the power-supply you are feeding the board with and the LEDs on the probe will tell you if the probed pin is high/low/or flipping between the two. A floating pin will show up as nothing, neither high nor low; on some chips this is normal, in other places it’s a fault. See more in the [[Logic Probe Guide]].
#'''[[EPROM Programmer]]''' - one that can test TTLs and SRAM is very useful. Checking ROMs is essential to prove you are not trying to find a hardware fault when the issue is bad software.
#'''ROM Puller''' - these are inverted U-shaped bits of sprung metal with little inward facing lugs at the end of the legs, and are supposed to ensure chips are pulled straight out of sockets without bending/breaking pins. You hook them under the chip and pull upwards, but balancing the force applied is often difficult and sometimes one end of the chip springs out and the other end suffers from lots of bent pins. Some people swear by these, but if you have concerns then a viable alternative that finds favour with a lot of our techy friends is to use a small flat-headed screwdriver to "lever" the chips out a little at a time at each end until they chip is out of its socket. Unfortunately this too has it's pitfalls in that it is easy to accidentally gouge the board underneath the chip with your screwdriver, potentially cutting traces. No-one said this would be straight-forward... Your choice!

===Advanced Board Repair Tools===

''These are items which are by no means essential (or in some instances even necessary) for successful board repair, however they are highly valued additions to the tool-set that can make your life easier in the long run.''

#'''Oscilloscope''' - These are used to display the waveform of a signal on a screen for the user to view. Whilst logic probes are cheap and useful; if a pin is active you have no idea what the signal looks like without an Oscilloscope. Duff RAM chips often remain active but the signals are utterly mashed, easy to spot with a scope, impossible with a logic probe. All a logic probe can tell you is if the chip is totally dead or not, but unfortunately most RAM chips struggle on so without an oscilloscope you are left with the blanket replace and retry option. ([http://www.doctronics.co.uk/scope.htm Using an Oscilloscope])
#'''Desoldering Station''' - This makes getting chips off boards a breeze, its good to be able to check a chip is ok once it’s off the board so not having to cut its legs off is a bonus! This also means you are less likely to roast the chip you want to use as you take it off a scrap board to re-use elsewhere. See our [[Desoldering Guide]] for further insight.
#'''[http://wiki.arcadeotaku.com/images/c/c6/Asayuki%27s_logic_comparator.pdf Logic Comparator]''' - This is a "poor man's logic analyser" but achieves much the same goal. You give it a known good chip and clip it onto the suspect chip on the board, then it compares the outputs of the onboard chip to the test chip when given the same inputs – any differences get flagged up.
#'''Logic Analyser''' - A Logic Analyser will rarely provide any epiphany-style break-through when trying to identify a fault; but the LA helps to confirm what you already suspect e.g. you're getting decent signals on /E for a 139 but not the proper outputs.
#'''ESR Meter''' - Similar to a multimeter, but used to measure Equivalent Series Resistance (ESR). This useful gadget will not only let you spot the bad electrolytic caps, it also allows you to use caps from scrap or smashed TV PCBs which you can test as being fine (or not!).

===Sundries/Consumables===

''The below items are the sort of items you may require to fix some of the problems you may across during your repair attempts.''

''As there is no knowing what will be needed and when, it may be worth just ordering what you need in an as and when basis, though this delay can be frustrating if you want to get on and fix the board ASAP!''

#'''Solder''' - For soldering!
#'''Kynar Wrap Wire''' - This is extremely thin single core wire and can be used to repair traces or replace broken chip legs.
#'''Trace Pen''' - Essentially a conductive paint pen that can be used to redraw broken traces.
#'''Flux''' - This is used during soldering. It is acidic, so when applied to a surface you wish to solder to, it removes any oxidization in place, leaving a good clean surface to solder to. Additionally, flux allows solder to flow easily on the working piece rather than forming beads as it would otherwise.

===A Note on Buying Equipment===

Much like game boards themselves many of the items used in their repair, such as Oscilloscopes, have been in production for many years. As such, they are often available on eBay and bargains can be had if you know what you are looking for.

One thing to take advantage of is the general public's general stupidity in that they often fail to do something as basic as check their spelling!

Be sure and search the listings for:

*Oscilloscope (correct)
*Osciloscope
*Oscillescope
*Oscilliscope
*Osilloscope

etc. You get the idea. Hopefully you'll stumble across a gem such as a badly listed Tektronix 'scope with lots of nice accessories which no-one else will be bidding for!

Naturally the same applied to everything (e.g. analyser/analyzer), but you are more likely to turn up a hit on items with complicated names. Give it a go.

Caution: Whilst old equipment can be a bargain, it is usually wise to choose en example from a company that is still active and/or well respected in their field. For Oscilloscopes and Logic Analysers, you're talking Tektronix, Hewlett Packard and Fluke. This way, you still have a company able to calibrate and service your device, plus they usually still sell compatible probes etc. Buying a cheap item from a long dead company may prove to be a false economy!

If you are unsure of what to buy, a good rule of thumb is to ask on the various forums where techy types hang out (UKVAC, Aussie Arcade, Arcade Otaku) and hopefully someone will advise!

[[Category:Technical]]
[[Category:Repairs]]
[[Category:Tutorials]]

File:Asayuki's logic comparator.pdf

2017-01-16T21:58:40Z

Asayuki: Open source logic comparator by Asayuki

Open source logic comparator by Asayuki

Kid No Hore Hore Daisakusen (Bootleg) Repair Logs

2016-12-22T22:45:26Z

Asayuki: Minor spelling errors

'''Repairer:''' Asayuki

'''Date:''' 22/Dec/2016

'''Symptom:''' Seller claims the board to be "cleaned".

I have found this board for sale at a very nice price. Although it is a bootleg, it's not that easy to find this pearl of Nichibutsu's portfolio around. As with every arcade purchase that comes at a nice price, no way this board was going to be working; but at least the seller didn't advertise it as such. He just mentioned that he cleaned it. Here's a couple of photos before even touching it.

[[File:Boobhack_cpu_board.jpg|800px|frameless|center|An overview of the CPU board just before the repair.]]

[[File:Boobhack_audiosprites_board.jpg|800px|frameless|center|An overview of the audio & sprites board just before the repair.]]

Once the board arrived, the first thing that struck my eyes was the look of it: main connector, presumably jamma, on the bottom board and ribbon cable connectors not aligned with one another thereby forcing the cables themselves in a strange slanted path. Very fishy, so I took the stack apart and decided to start verifying things around first. I started by checking that the pinout was really as Jamma as it was looking. +5V and GND on the CPU board were going to the right places, but +12V was not reaching the power amp which is located on the audio/sprites board. Enough of a confirmation that the audio/sprites board had been flipped and therefore connected the other way around. Connecting it the right way magically connected the +12V pin of the Jamma connector to the power amp's supply pin. :)

It was now time to apply power and see what other problems would pop up. Luckily the game started, did not crash, had perfect sound and it was even perfectly playable. It just had the sprite colors messed up, not to talk about the ugly title screen which is characteristic of this specific bootleg.

[[File:Boobhack_title_bad_colors.jpg|800px|frameless|center|The color palette of the sprites is all messed up in the title.]]

[[File:Boobhack_ingame_bad_colors.jpg|800px|frameless|center|The color palette of the sprites is all messed up even in the game.]]

Very easy theory: the seller had a perfectly working board, which was however kind of dirty. He therefore decided to separate the boards, thoroughly clean them one by one and then reassemble the stack. Too bad he didn't remember how the boards were connected together, and he ended up connecting the audio board flipped with respect to its original position. Result: the moment he applied power he fried the game. As the game was now mostly working, it was very easy to prove this theory: I searched the ribbon cable connector for the exact position where +12V was reaching the audio/sprites board, and located two pins used for this purpose. By mentally flipping the board I figured out were +12V had been wrongly connected to on the audio/sprites board when the game got powered up after cleaning, which traced down to pins 9 and 12 (two outputs) of the 74LS157 at F3. Luckily no unreplaceable component was involved. I took my comparator out of the closet and...

[[File:Boobhack_f3_faulty.jpg|800px|frameless|center|The comparator, showing the bad pins as predicted.]]

Bingo! Pins 9 and 12 completely fried. Just think of those poor totem pole outputs trying to impose a low logic level to a low impedance +12V power source! Ouch! That hurts! This fully confirmed my theory and almost made me roll on the floor laughing. I socketed and replaced the guilty IC and ...

[[File:Horekidb_ingame_good_colors.jpg|800px|frameless|center|The colors are back to their full Nichibutsu glory.]]

Voilà! Game fixed. Now there was one last disturbing thing: that ugly title screen. According to MAME, this is just a graphics hack which involves EPROMs 1-M and 1-O. I dumped them and they fully matched the ones of the set boobhack. A little bit of erasing and reprogramming those two chips finally brought this game really back to life.

[[File:Horekidb_title_good_colors.jpg|800px|frameless|center|This game is finally back to life.]]

Nichibutsu has a very useful service mode screen in this game, which allowed me to quickly configure and test all dip switches as well as test all user inputs and the sound generator. I wish all repairs were this easy and lucky! To those who have never played this game, I highly suggest to give it a go; once you learn the mechanics and the several tricks it allows, it becomes a lot of fun.

[[File:Stage_clear.png|332px|frameless|center|Stage clear]]
[[File:LUCKY.png|332px|frameless|center|Lucky bonus]]

[[Category:Repair Logs]]

File:Horekidb title good colors.jpg

2016-12-22T22:33:44Z

Asayuki: Kid No Hore Hore Daisakusen, bootleg, perfectly working.

Kid No Hore Hore Daisakusen, bootleg, perfectly working.

File:Horekidb ingame good colors.jpg

2016-12-22T22:31:46Z

Asayuki: Booby Kids bootleg board, working fine.

Booby Kids bootleg board, working fine.

File:Boobhack f3 faulty.jpg

2016-12-22T22:30:17Z

Asayuki: Asayuki's logic comparator showing a faulty 74LS157 on a bootleg Booby Kids board.

Asayuki's logic comparator showing a faulty 74LS157 on a bootleg Booby Kids board.

File:Boobhack ingame bad colors.jpg

2016-12-22T22:28:30Z

Asayuki: Booby Kids, bootleg, bad sprite color palette.

Booby Kids, bootleg, bad sprite color palette.

File:Boobhack title bad colors.jpg

2016-12-22T22:26:58Z

Asayuki: Booby Kids, bootleg, broken sprite colors.

Booby Kids, bootleg, broken sprite colors.

File:Boobhack audiosprites board.jpg

2016-12-22T22:23:56Z

Asayuki: Booby Kids italian hack, audio and sprites board.

Booby Kids italian hack, audio and sprites board.

File:Boobhack cpu board.jpg

2016-12-22T22:23:01Z

Asayuki: CPU board of the Booby Kids italian hack.

CPU board of the Booby Kids italian hack.

Lady Bug (Bootleg) Repair Logs

2016-12-02T20:52:45Z

Asayuki: Added a new repair

'''Repairer:''' Asayuki

'''Date:''' 29/Nov/2016

'''Symptom:''' Seller claims the board to be non-functional

There is not much to say about this repair. By just having a look at the board, there were a lot of parts that needed replacement. The board was also covered with crud, so I had to wash it. I hate doing this because it's always a risk, and doesn't do any good to all elctromechanical parts like dip switches, volume pots and similar.

[[File:Lady_bug_boot_before_repair.png|800px|frameless|center|An overview of the board just before the repair.]]

A very careful look at the entire board highlighted several capacitors which went broken or missing due to mistreatment and carelessness. A tantalum cap which was generating the delay for the RESET# pulse was also broken. No way this board would have started, in the conditions I received it, therefore I didn't even bother turning it on before having replaced all required parts. Also the quartz crystal caught my attention, because it had been soldered from the top side instead of from the bottom. Looking closer, the quartz was reading 12MHz, which is way above of what the processing units of the time could handle. A quick check on MAME confirmed that the board needed a 4MHz quartz crystal instead. Obviously some noob attempted to repair this board and failed. I had no 4MHz crystal on stock so I decided to borrow one from a Solomon's Key board I still have to look at, and buy a few while I was there. There was an area of the circuit, around the 556 double timer circuit, which had torn off components. Since timers were often used to generate sound back in the days when this board has been produced, I feared this was part of the audio generation and therefore I needed the exact values if I wanted to have faithful sound. Luckily the schematics of this board are available, and shown that the 556 was not part of the audio generation but rather served as monostable circuits to handle coin inputs. Being able to read the missing values from the schematic, I was able to populate the missing parts faithfully to the original. I hadn't applied power yet, and I already had a cemetery of components on my desk! :)

[[File:Lady_bug_boot_component_cemetery.png|800px|frameless|center|My little new cemetery.]]

The board was now finally ready for powering up, therefore I quickly built the required adapter and switched it on. The board booted, passed RAM/ROM checks and went into a working attract mode but was plagued by these horizontal white and blue lines... Also, vibrations would make it crash. Meh :/

[[File:Lady_bug_boot_graphics_problem.png|800px|frameless|center|The screen as it showed after having replaced all those parts.]]

Luck came immediately to the rescue: by rebooting the board, a RAM error pointed me in the direction where to look: the socketed RAM had dirty pins. Not much of a problem: a bit of cleaning and reseating got rid of the RAM error. The graphics defect was changing with time, and letting the board warm up made the issue even worse while letting it cool down returned the issue to its original look. I took the freezer spray out of the closet and it didn't take long until I ended up freezing a 74LS273 that immediately reacted to the temperature change.

[[File:Lady_bug_faulty_273.png|800px|frameless|center|The component guilty of generating those appalling white lines.]]

Bingo! By replacing it, I finally got a nice looking game.

[[File:Lady_bug_working.png|800px|frameless|center|The board is finally showing flawless graphics.]]

I played some credits to test the sound and all controls for both players in cocktail mode and all controls and coin slots proved to be ok, as well as screen flipping. I however found out that the sound was coming and going. As expected after washing it, the volume pot was to blame; so I soldered a new one in and finally the sound was fixed and enjoyable. Repair complete! A very fun evening on a game that is always worth playing when you need some random relaxing entertainment.

[[File:Stage_clear.png|332px|frameless|center|Stage clear]]
[[File:LUCKY.png|332px|frameless|center|Lucky bonus]]

[[Category:Repair Logs]]

File:LUCKY.png

2016-12-02T20:50:45Z

Asayuki:

File:Lady bug working.png

2016-12-02T20:47:08Z

Asayuki: A working attract mode on a bootleg Lady Bug board.

A working attract mode on a bootleg Lady Bug board.

File:Lady bug faulty 273.png

2016-12-02T20:46:12Z

Asayuki: Lady bug bootleg board, 74LS273 responsible of generating unwanted lines over the screen.

Lady bug bootleg board, 74LS273 responsible of generating unwanted lines over the screen.

File:Lady bug boot graphics problem.png

2016-12-02T20:40:33Z

Asayuki: A bootleg Lady bug board showing unwanted horizontal lines over the picture.

A bootleg Lady bug board showing unwanted horizontal lines over the picture.

File:Lady bug boot component cemetery.png

2016-12-02T20:39:02Z

Asayuki: A group of broken components extracted from a faulty Lady Bug board.

A group of broken components extracted from a faulty Lady Bug board.

File:Lady bug boot before repair.png

2016-12-02T20:34:51Z

Asayuki: A bootleg lady bug board, as it came in from the seller.

A bootleg lady bug board, as it came in from the seller.

File:LU---.png

2016-10-25T04:16:51Z

Asayuki:

Wardner (Bootleg) Repair Logs

2016-10-25T03:53:57Z

Asayuki: Typo

'''Repairer:''' Asayuki

'''Date:''' 25/Oct/2016

'''Symptom:''' Locks up at boot with a "CRAM ERROR" message

This bootleg seemed to suffer from one of the most common issues in the world of arcades: bad RAM. The seller told me this board was broken and displayed a RAM error message, and yet the price wasn't as nice as a broken bootleg can be. This is not a game one finds for sale so easily, therefore I accepted the price and purchased it. There it is, before even turning it on.

[[File:wardner_boot_overview.jpg|800px|frameless|center|An overview of the board just before the repair.]]

When I connected it to the monitor on the examination desk, I could just confirm what the seller said: the message "CRAM ERROR" was the only visible thing on the screen, written in scary red letters.

[[File:wardner_boot_cram_err.jpg|800px|frameless|center|It must be an easy fix, right?]]

As the message was appearing consistently at every boot, I trusted it and went on searching for the chip to replace hoping in an easy fix. Sure, there was only one problem...

[[File:wardner_boot_overview2.jpg|800px|frameless|center|This photo shows what's under the bootleg patch boards. It looks almost identical to the real thing.]]

25 RAM chips scattered all over the place, including under the patch boards, and of course no help whatsoever from the internet! Good luck finding the right one! MAME documents this hardware in a still incomplete way, and unfortunately does not mention what all RAMs are called like. I mean, sure it knows of video ram, palette ram, sprite ram, etc. but doesn't mention the cryptic four letter codes used by the program ROM to describe them on screen. In order to avoid desoldering everything, I needed to dig deeper into the code to understand what "CRAM" was supposed to mean. Using MAME's font display feature, I translated the ascii for CRAM into the corresponding video codes required by the hardware to display that text on screen. No "CRAM" string was to be found in the code EPROMs either as ascii or as font-oriented video codes. ...my usual luck.

Thanks to MAME I made a list of RAM areas available to the system and with a little debugging effort made MAME stop execution during the test of said areas. I altered those areas on purpose to make the RAM test fail and see what message appeared on screen. I experienced SRAM error, FRAM error, MRAM error, etc. and of course also finally a CRAM error. Thanks to this, I now knew the address where the CRAM is available to the system and from MAME's memory map I could easily tell that it was the audio CPU RAM. Great, because it's obviously going to be located beside the audio CPU. Therefore desolder, socket, replace, fire up... CRAM ERROR. Because of course! *SIGH*

Provided the processor was good, there was only one possibility: the addressing logic had an issue somewhere. The RAM I was trying to debug was sitting on another bus, which means the main CPU needs to request access to the audio CPU bus in order to fiddle with its RAM, therefore I poked my scope to the BUSREQ# signal of the audio CPU. As suspected, no request ever came to the audio CPU to release the bus, which means the main Z80 was not even able to reach the target memory. I needed to dig deep into the addressing logic of the main CPU, and this is where things started to get funny.

[[File:wardner_boot_cpu_addr.jpg|800px|frameless|center|The portion of schematic I have noted down properly while reverse-engineering the hardware.]]

As you can see from this schematic portion I reverse-engineered from the board, the main CPU differentiates addresses in a very fine way. The bottom of the memory, from 0000 to 6FFF is always mapped to the program rom, then there is a ram area at 7000-7FFF connected through buffering while the rest is banked in a very convoluted way. Also, as the addressing space is too crammed with stuff, the main CPU uses a ton of I/O accesses to communicate with the rest of the housekeeping circuitry around. Toaplan exploited every single bus feature the Z80 could offer; including wait states to keep everything in sync. Through this scheme, the main CPU can basically address every single RAM all around the board, thereby being able to provide quite some debug information before booting. That is the reason why the boot sequence takes so long. As most of those RAM devices are located in high speed circuit portions which are normally read and addressed in hardware, there was a need to arbitrate the main CPU access to the bus.

To this purpose, Toaplan resorted to a wait state circuitry around the main CPU that with every single CPU access to every single resource on the board (even dip switches and joystick ports!) tells the CPU to WAIT#, determines whether the resource can answer immediately or not and finally gives the CPU a go signal once the resource is ready. Furthermore, due to the way the board has been designed, the CPU accesses most of the resources using a 16bit data path. Wait... the main CPU is a Z80. How come 16bits? Because the designers were forced to use 16bits data paths due to how the graphics circuitry works. This board uses three custom chips which look a lot like predecessors of the T.T-2 used in Twin Cobra and Flying Shark (no wonder: Wardner has been released just a few months before them) which I already got to know intimately in [[Twin Cobra Repair Logs|another repair]]. Those customs always need to access the RAM as 16bit in order to provide all the nice hardware features and colour depth required for this game.

In order to facilitate debugging, and to protect themselves from piracy, Toaplan gave the main CPU the ability to read and write from any RAM around, plus they moved the sprite handling routines from the main CPU to a factory-programmed DSP chip: the TMS32010. This design approach requires the TMS32010 to be able to read from and write to the addressing space of the main CPU. It actually does read from and write "only" to both the main CPU RAM and the sprite RAM. This implicitly allows the protection code to talk to the main CPU and is made necessary by how the code is structured in order to be able to move sprites around. The TMS32010 could also theoretically access the audio CPU's RAM through the main system bus, and the audio CPU can indirectly talk to the rest of the system because its private RAM is shared with the rest of the board. ....an addressing mess, most of which is 16bit wide also because the DSP itself has a 16bit bus. Most RAM areas are made of two 8bit memories exactly due to this reason: so that the DSP and the graphics hardware can access 16 bits in one go.

Given that Wardner is the first Toaplan game to implement a DSP design on board, but is also the only one to do it with a Z80 as a main CPU, it seems obvious that they should really have used a Motorola 68000 as a main processor instead (which they did, starting from their very next board: Flying Shark...). Be it cost reasons, be it the 68000 being still totally obscure to their programmers, be it tight deadlines, be it stubborness... Wardner ended up being a uselessly complicated hybrid 8/16 bit system. As their next two products testify, Toaplan regretted their decision.

In a nutshell, I was getting fed up. I decided to proceed in a different way and quickly rule out most of the logic mess without reverse engineering all the details of it. But for that I needed a tool I was lacking in my arsenal: a logic comparator. Of course HP's logic comparators are a pain to find on the internet, and the prices start from around 350 euros. Add to that the need for all those pesky reference chip boards and the fact that it's 30 years old hardware bound to fail anytime soon. No way! I preferred to design one myself, Asayuki style of course!

[[File:asayuki_logic_comparator.jpg|800px|frameless|center|My brand new logic comparator]]

Thanks to the comparator, I managed to find an issue on one of the ports of an OR gate. Although the part itself was good, I was seeing discrepancies with respect to the reference IC because of the parasitic inductance and capacitance of my comparator's probe. That sounded very funny, because it shouldn't be happening if the signal is properly driven. By tracing back the signal that was driving that input pin I found out that it was the CPU's IORQ# and it was very low in amplitude: about 1V. Replacing the CPU didn't help, which meant there was a heavy load on that line. A short search by desoldering here and there highlighted a 74LS08 that had low impedance in the input pin to both ground and VCC.

[[File:wardner_boot_cram_fix.jpg|800px|frameless|center|The gate guilty of causing the CRAM ERROR message]]

Bingo! I replaced the part, fired up the board and this time the screen stayed black. No error message whatsoever, no nothing. By scoping the Z80 I saw it was completely stuck, with the WAIT# line low. Now the defect moved to the wait state generation logic. Another logic mess which was reaching out to the entire board. So... back to reverse-engineering.

The signal which was required to tame the waitstate logic and let the CPU resume executing is coming from a 74LS133 (a NAND gate with a whopping 13 inputs!), whose inputs were "helped" by further AND and OR gates all over the place. There was no other way to proceed but to trace each and every input back to the logic that was driving it, and check if that was the circuitry that was getting stuck: a daunting process that was bound to take a very long amount of time on top of the time I had already invested so far. Luckily, so to speak, I stumbled almost immediately on the right signal, which brought me to a huge shift register bank organized using 11 (!!) 74LS299. A closer look to them highlighted an issue that slipped through the first visual inspection...

[[File:wardner_boot_LS299.jpg|800px|frameless|center|The fault caused by the one who has tried to repair this board before me]]

As it turned out, this board suffered a failed repair attempt based on guesstimation and a profit-driven trial and error approach. The person who did this is the kind of guy nobody would ever want to entrust an arcade repair with!

The pins you can see cut in the photo are the output enables of this shift register chain. The main processor uses them to write and read from and to the various graphics RAMs, therefore the boot process cannot proceed without them. The wait state logic waits forever for the shifting to be complete, because the outputs are always disabled. As a result, the CPU got stuck as soon as it tried addressing the memories in that area. Thank God, repairing the damage solved the issue. The board went through the long sequence of boot tests without problems and greeted me with a working attract mode, complete with sound. Just out of curiousity, I tried swapping back in the LS08 I had replaced before, and the CRAM ERROR came back as I witnessed it the first time around. This confirmed that whoever attempted the repair didn't have the slightest clue. He just started cutting here and there hoping in a lucky shot. A careful look all around the board didn't highlight any other cut pins, so I tought it was over.

[[File:wardner_boot_fixed.jpg|800px|frameless|center|The game finaly boots and works as intended]]

I played a couple of credits and ended up noticing that the picture looked dull and flat, as if there were not enough colors on the display. Also, the audio sometimes went silent due to a loose joint under the output capacitor of the power amp. A quick comparison with MAME confirmed my suspects: I had a video DAC issue. Fortunately Toaplan had put a gird & colour bars pattern generator into their code, so I flipped dipswitch 1 bit 3 and rebooted the board.

[[File:wardner_boot_color_issue.jpg|800px|frameless|center|The issue with the colour DAC]]

There! Definitive and very helpful proof. This issue was extremely easy to fix but also extremely funny. This board's video DAC is the usual weighted resistor thing, with 5 bits per channel for a total of 15bpp. As bootleggers need to save money, they always use 5% resistors of the most common values: 220, 470, 1k, 2.2k and 4.7k. In a nutshell bootleg DACs are non-linear and the response is different from channel to channel, which explains why the greyscale in the photo looks reddish. Fair enough, but the resistors were fine yet some of the green coulour bit weren't output correctly. While fearing an issue in the DAC driving logic, I had a closer look at the PCB to see if all channels were identical and using the same resistor weights. That's when I figured the real issue out: the green channel had two of the resistors properly connected to the output, while the other three ended up on a common net that was completely isolated: no trace, no wire, no nothing. They actually forgot to route that node up to the green channel! ROFL! The solder joints looked so original that some of them were even cracked and about to go loose, and this means that this board always displayed dull and flat ever since and nobody ever cared. Beautiful! Solution? Well...

[[File:wardner_boot_color_fix.jpg|800px|frameless|center|My patch was quick, easy and straight to the point. ...literally!]]

Toaplan wanted to deliver a cutting edge 16bit platform, but failed. The bootleggers wanted to create a 1:1 copy and failed. The guy who attempted the repair before me also failed big time. And considering all the time I have invested into this, I also failed. Picard's facepalm is not enough to describe all this. But Wardner is a nice little game and deserved to be saved. After all, I replaced just one component... *grin*

[[File:Stage_clear.png|332px|frameless|center|Stage clear]]
[[File:LU---.png|332px|frameless|center|Lucky bonus]]

[[Category:Repair Logs]]

File:Wardner boot overview2.jpg

2016-10-25T03:23:59Z

Asayuki: Overview of a bootleg Wardner board with the patch boards removed to show the hardware that sits below them.

Overview of a bootleg Wardner board with the patch boards removed to show the hardware that sits below them.

File:Wardner boot overview.jpg

2016-10-25T03:22:31Z

Asayuki: Overview of a bootleg Wardner board. Can you spot one of the issues?

Overview of a bootleg Wardner board. Can you spot one of the issues?

File:Wardner boot LS299.jpg

2016-10-25T03:21:22Z

Asayuki: An fault caused by a failed repair attempt carried on a bootleg Wardner board

An fault caused by a failed repair attempt carried on a bootleg Wardner board

File:Wardner boot fixed.jpg

2016-10-25T03:20:18Z

Asayuki: Fixed bootleg Wardner board, now running the attract mode

Fixed bootleg Wardner board, now running the attract mode

File:Wardner boot cram fix.jpg

2016-10-25T03:19:13Z

Asayuki: Component replaced to fix a CRAM error on a bootleg Wardner board

Component replaced to fix a CRAM error on a bootleg Wardner board

File:Wardner boot cram err.jpg

2016-10-25T03:18:33Z

Asayuki: CRAM error on a bootleg Wardner board

CRAM error on a bootleg Wardner board

File:Wardner boot cpu addr.jpg

2016-10-25T03:17:54Z

Asayuki: Excerpt of the main CPU addressing logic in a bootleg Wardner board

Excerpt of the main CPU addressing logic in a bootleg Wardner board

File:Wardner boot color issue.jpg

2016-10-25T03:17:11Z

Asayuki: Video DAC issue on a bootleg Wardner board

Video DAC issue on a bootleg Wardner board

File:Wardner boot color fix.jpg

2016-10-25T03:16:22Z

Asayuki: A fix for a facepalmed colour DAC on a bootleg Wardner board

A fix for a facepalmed colour DAC on a bootleg Wardner board

File:Asayuki logic comparator.jpg

2016-10-25T03:15:23Z

Asayuki: Asayuki's own self-designed logic comparator

Asayuki's own self-designed logic comparator

Gemini Wing Repair Logs

2016-09-22T05:29:28Z

Asayuki: Linked to the repair logs category

'''Repairer:''' Asayuki

'''Date:''' 21/Sep/2016

'''Symptom:''' Missing drum sounds

This repair effort started in a LOL, and I'm not even sure any more whether I should call it a “repair” or something else. I had found a Gemini Wing board at a nice price advertised as working and decided to buy it. When I fired it up and started playing the game I felt there was “something missing” in the audio, but couldn't really point out what it was. Puzzled, I fired up MAME for a comparison and realized that the digital drums were the missing part. A quick look at the audio section of the board, compared with the list of audio chips reported by MAME made me laugh: the entire digital audio section was not populated and I didn't realize so far!

[[File:Gemini_boot_nosamples.jpg|800px|frameless|center|The board before the repair.]]

Ok, bootleggers need to save money, but omitting an entire section of the circuit is pushing it a little bit too far. This dark omen could only mean one thing: the bootleggers had made a mistake on the PCB big enough to render the entire area useless. Unfortunately this later turned out to be correct.
As I have a friend who owns a similar bootleg board where that area is populated, I asked him to shoot a photo from which I could see what parts were supposed to be there. But that wasn't enough of course: I needed to find out what was wrong with the design of my board before I could assemble the missing parts. Time for reverse-engineering! Luckily the total absence of components or sockets made it easy to follow the traces and figure out the schematics.

[[File:Gemini_audio_schematic.png|800px|frameless|center|The schematic to the audio samples section.]]

The way this section works is very straightforward. The heart of the system is the MSM5205 at W8. It generates a sample clock based on the 400kHz ceramic resonator whose frequency is then divided by 64. As a result, VCK is about 6kHz which in turn means the hardware can only play back audio up to around 3kHz worth of bandwidth; very low fidelity indeed but enough for the drums and for the thunder sound for level 4. The LS157 mux at X8 forwards sample data from the 27C256 EPROM at W7 to the OKI DAC 4 bits at a time. The flip-flop at U8 takes care of alternately selecting the high nibble or the low nibble. The addressing of the EPROM is split in two parts: the lower 8 bits are coming from the LS393 counter at U6, while the higher 7 bits come from the LS191 counters at X6 and W6. The two LS85 at X5 and W5 compare the higher 7 addressing bits to a constant value provided by the LS373 latch at U5. Once the two values match, the LS74 flip-flop at U8 flips from the play state to the stop state. The rest of the logic allows the audio CPU to set an 8 bit end address into the latch at U5, an 8 bit start address into the counters at X6 and W6, and a 4 bit volume level which controls a 4066 switching different resistors into the feedback path of an operational amplifier to control the volume of the sample playback. Samples therefore do always start and end on memory addresses multiple of 256. In order to prevent audio glitches, the CPU shall first program an end address and then a start address, because this last operation also triggers the start of the playback. Reasonable and cost-effective.

As you can see from the schematic above, the bootleggers made two big mistakes: first of all they shorted together the address lines A9 and A10 of the EPROM. Once I had completed the schematic of this area it was no problem to cut the trace in the right place and fix the issue with a wire. Second: they wired pin 3 of the DAC to ground; doing so makes the DAC ignore the 4th bit coming from the LS157 mux, which is very important as it is the sign bit. Just for the sake of curiosity I tried leaving pin 3 of the DAC as it was and the audio samples were garbled and very low in amplitude, confirming that the right setting is to pull this pin high. A little more cutting and wiring fixed this as well. Here are two photos showing the patchwork and the assembled sockets.

[[File:Gemini_socketed.jpg|800px|frameless|center|Sockets have been added to the board.]]

[[File:Gemini_patched.jpg|800px|frameless|center|These are the patches needed to fix the issues introduced by the bootleggers.]]

My board was now finally playing samples as Tecmo intended. ...or maybe not. While playing the game I experienced some very weird issue with samples: the samples themselves would very rarely play out garbled and “farty” with no apparent reason; by converse they were playing fine most of the time throughout the game. The issue was appearing almost exclusively in level 4, therefore I tried dumping and checking the romset: everything matched the gemini set documented by MAME except two bytes of the main CPU's program code. By searching on the internet, it turned out that [http://www.arcadeitalia.net/viewtopic.php?t=21707 someone else] already reported the same differences in his own board.

This confirmed that my EPROMs were fine and I was just using an undumped version of this game. By the way, the difference between the two sets seems to be just the missing territorial warning screen.
A careful investigation of the sample player was needed. With the scope I could see the DAC emitting saturated waveforms, probably coming from wrong input data. As this DAC is ADPCM, the input data gets summed to an internal 4 bit accumulator to determine the output value. Input data is therefore signed and represents the positive or negative offset from the current voltage level to the next one. If random data comes to the input, the accumulator will likely get out of control, overflow and roll back to 0000 or underflow and roll up to 1111, thereby producing very high amplitude square waves which sound like digital farts.
The cause of this behaviour is yet another design mistake of the bootleggers, much harder to spot in comparison to the other two. You see, when the sample player has finished reproducing some sample, the play/stop flip-flop triggers to the stop state and makes the player ready to accept a new sample. But what happens if the CPU tries to start a new sample while the previous one hasn't finished playing yet? The flip-flop ignores the start command, because it's already playing, and as a result no reset pulse informs the rest of the circuitry about the sudden change of plans. Everything keeps running happily, except the start address and end addresses for the player have changed. To make things worse, the new start pulse from the CPU comes completely asynchronous to the clock of the DAC. This results in the output data bits of the EPROM changing value while the DAC is acquiring them. No wonder the DAC was misbehaving!
In order to fix this, I needed to present a reset pulse to the circuitry every time a new play request came in; but I needed to preserve the important start/stop logic as well as comply with the timing requirements of the DAC which needs a reset pulse at least 4 VCK pulses long in order to successfully reset the internal circuitry. The solution I have come up with in order to solve this problem is the circuitry below, based on an LS161 and an LS00. The basic idea is that this small patch circuit replaces the LS74 at U8, therefore I built a patch board which plugs in place of the IC at U8, hosts the LS74 which I removed from the main board and integrates it with the LS161 counter and the LS00 gate.

[[File:Gemini_patch_schematic.jpg|800px|frameless|center|Schematic of the patch board.]]

As you can see, the LS74 is almost directly connected to its original socket. The main difference is that its signal is helped by a stretched reset signal coming from the LS161. The LS161 starts counting from 0 up to 4 at the rate of one LSB per VCK pulse whenever a new start pulse arrives. Its output is NANDed with the output of U8. This way U8 can enforce the long standing reset that is required by the stop state, but the LS161 dictates that any reset pulse must be at least 4 VCK pulses long to ensure that the DAC's internal register gets cleared before accepting new data. Furthermore, the LS161 always reacts to all start pulses and can therefore enforce a reset even if a sample is still playing. This certainly delays the start of the playback, but with a clock frequency of around 6kHz the whole delay will be less than 0.7 milliseconds and therefore not detectable by the human ear.
Here is a picture of the patch board and the completed work.

[[File:Gemini_patch_board.jpg|800px|frameless|center|Physical construction of the patch board.]]

[[File:Gemini_working_board.jpg|800px|frameless|center|The final assembly.]]

One last very important step: Pin 1 of the IC at T7 should be cut from the trace it is connected to, and connected to the STARTADD# signal instead (pin 13 of the U8 socket). Without this important change, the now longer reset pulse generated by the patch board would keep the LS174 latch at T7 cleared while the CPU writes the new volume value to it for the upcoming sample; as a result all samples would be muted. You can see this last change wired on the above photo.

My fix was successful, and my bootleg Gemini Wing board is now always playing samples correctly, just as the original designers intended. And this game's awesome soundtrack is now fully enjoyable. I know what you are thinking: this was totally overkill for a bootleg and not worth investing time or money into. You are definitely right; yet I had a lot of fun doing this, and I am sure this article will prove useful to all owners of Gemini Wing bootleg boards with farting or absent sample playback. ;)

Needless to say, the endeavour wasn't over yet. While enjoying the awesome music of this shmup over a few credits, I let myself so carried over that I actually completed the game and got to the ending sequence. And that's where the actual surprise came in. Every single part and detail of this game was now beautifully perfect up until the final bit of the ending sequence where I got something I really wasn't expecting. See [https://www.youtube.com/watch?v=ALe75EQQJ0w this video].

OH NO! How am I going to debug this now? MAME to the rescue! Except MAME was displaying something so incredibly different that made me fear it wasn't emulated correctly. You can see MAME's difference in [https://www.youtube.com/watch?v=G0qlCqhTYjo&t=28m30s this video], as well as many others; I couldn't find any video of the ending sequence shot on real hardware.

No other choice but to start studying the code of the game. MAME has been a precious help here, because its powerful debugger makes it the ideal tool to investigate these kinds of issues. By displaying the isolated contents of each and every single layer I was able to establish the first fact: this effect only occurs on the background layer. The foreground layer is completely transparent, and the text layer is used to frame the display to the same small rectangle used for the horizontal flight scene where the credits roll. No sprites are used, therefore what I was looking for had to do with the background layer. As MAME states, the background layer has no special features apart from scrolling; there is a 16bit register for horizontal scrolling and an 8bit register for vertical scrolling.
But as you can see from my video a zooming effect is clearly visible.

Note that the game has vertical orientation, therefore the monitor is rotated to the right by 90°. This means that from the user perspective the raster beam runs vertically from top to bottom and the screen is scanned column by column from right to left. It's not so easy to wrap one's mind around this concept, so I will describe this pretending the monitor is in the wrong non-rotated position. The play field is therefore scrolling from left to right instead of from top to bottom.

The use of a 16 bit register for horizontal scrolling is more than justified: this is used to scroll the quite long play field from the start to the end of each level. However, there is no place in the game where the play field scrolls vertically. Tecmo released two other games which run on a similar hardware: Rygar in 1986 and Silkworm in 1988. Vertical scrolling is never used in Silkworm, and Rygar only has a few places where vertical scrolling is used (namely the areas where you climb a rope up or down, with frogs trying to hit you with their tongue). Gemini Wing is from 1987, which means the hardware is very likely to match Rygar to a great degree, and to maybe be a slightly improved one.

Vertical scrolling is controlled by the register at 0xF805, and by asking MAME to break execution when that register is written makes the game run just fine up until the ending sequence where the faulty effect starts; that's when the code first writes a value other than zero there. The code that takes care of implementing the effect starts at 0x1391 and is triggered through a flag via the interrupt signal that comes to the CPU at the end of each frame when the vertical blanking interval starts. The code does not use any other timing reference apart from this sinlge interrupt, and this makes it extremely time critical. What it internally does is to compute two rough half sinuses and poke the horizontal and vertical scrolling registers with the computed values every few raster lines. This is called “raster effect”; I remember doing a lot of this stuff when I was a kid coding intros on the C64... The target basically is to cheat the video hardware into behaving differently on a line by line basis in order to achieve visual effects that would otherwise be impossible for the platform. Gemini Wing uses the horizontal scrolling register to tear the picture on the screen. You can clearly see from the video that odd slices go up and even slices go down. The vertical scrolling register is instead used to impose a different vertical position to every line. By choosing the vertical position wisely, it's possible to display the same graphics in two adjacent lines, thereby stretching the image. It is also possible to skip graphic data from one line to next, thereby making the picture shrink with respect to its original size. The real hardware responds to register changes on the fly line by line, while MAME was only updating the screen once per frame, which kills the effect as you can see in the above video recording.
That's the second proven fact: this raster effect is created solely by using the scrolling registers, and the interrupt pulse is of paramount importance to its timing. This explains what can be seen in my video, compared against MAME, but doesn't solve my issue: the effect on my board still looks very broken as I would expect some clever zooming-stretching-tearing effect.

By tracing the address decoding circuitry I managed to find the 74LS273 which responds to the address 0xF805, removed it from the board and put a socket in there. Then by tracing the data bits from the CPU to the register I mapped all eight bits to the input pins of the latch where they belonged. Then, with the latch removed, I stimulated each and every (now missing) output. By imposing a level 1 or 0 one pin at a time I could make the background shift by 1, 2, 4, 8, 16, 32, 64 and 128 pixels. Against all odds, the hardware is behaving exactly as MAME describes, scrolling the background vertically by the given amount of pixels, therefore my issue obviously was in the amount of time the CPU took from one register write to the next.
Trying to figure the issue out, I also noticed that MAME was running the main processor of the game at 6MHz, while the CPU on my board runs at 8MHz. MAME also says that the video circuitry is clocked at 24.000MHz, while my board has a 24.180MHz oscillator. I patched my board to run the main CPU at 6MHz (24MHz divided by 4), which resulted in the audio CPU and the sound generator running at 3MHz instead of 4MHz because the board simply divides the main CPU clock by 2 and uses this to clock the audio area. I have shot [https://www.youtube.com/watch?v=gpPVDQkgiXU another video] with the board patched this way. The audio is way slower due to the clock frequency change.

I also tried 8MHz CPU clock but with 24.000MHz video clock, but that didn't improve the situation over my initial setup. Video [https://www.youtube.com/watch?v=oR7yiPBWaE8 here].

No cigar. I couldn't proceed any further without knowing the exact clock frequencies I needed to use, and the only way to know them is to look at an original board which unfortunately I don't own.

I would like to thank Leonard Oliveira and Angelo Salese, who helped out without hesitation. Leonard has asked his friends and found out a person who owns an original Gemini Wing board and would be willing to provide informations about the clock frequencies of the original board as well as a video showing how the ending sequence is meant to look like.
Angelo needed no explanations; he figured everything out on his own starting from my videos, implemented raster effects for MAME's Tecmo driver, added my undumped romset to MAME and corrected the clock frequency and display timings for the game according to the ones my board is generating.
Suprise surprise, with these changes implemented, MAME started behaving exactly the same as my board does. This confirmed that my hardware was actually fine, but is just as far as one can get without verified data. As soon as Leonard's friend will post back the video clock frequency and the main CPU clock frequency as used on his original board I will be able to patch mine with the right crystal and oscillator to obtain the same result as the original; provided my board doesn't hide other issues, that is. And of course these data will also end up in MAME for the good of the community.

NOTE: the changes have been applied to MAME's source code just a week ago. If you want to try them out immediately then you need to get the source code from GIT and recompile MAME yourself. Otherwise you need to wait until version 0.178 is out.

[[Category:Repair Logs]]

File:Gemini working board.jpg

2016-09-21T11:55:50Z

Asayuki: Bootleg Gemini Wing board, hosting the patch daughtercard.

Bootleg Gemini Wing board, hosting the patch daughtercard.

File:Gemini patch board.jpg

2016-09-21T11:54:28Z

Asayuki: Physical construction of a daughterboard to patch the non-working audio samples section of a bootleg Gemini Wing board.

Physical construction of a daughterboard to patch the non-working audio samples section of a bootleg Gemini Wing board.

File:Gemini patch schematic.jpg

2016-09-21T11:52:13Z

Asayuki: Schematic of the daughtercard needed to patch a bootleg Gemini Wing board with messed up sample player.

Schematic of the daughtercard needed to patch a bootleg Gemini Wing board with messed up sample player.

File:Gemini patched.jpg

2016-09-21T11:48:10Z

Asayuki: Gemini wing. Patchwork needed to fix the issues made on the PCB by the bootleggers.

Gemini wing. Patchwork needed to fix the issues made on the PCB by the bootleggers.

File:Gemini socketed.jpg

2016-09-21T11:46:38Z

Asayuki: Gemini Wing, digital samples section completely socketed.

Gemini Wing, digital samples section completely socketed.

File:Gemini audio schematic.png

2016-09-21T11:44:11Z

Asayuki: Reverse-engineered schematic diagram of the sample playback section in Gemini Wing.

Reverse-engineered schematic diagram of the sample playback section in Gemini Wing.

File:Gemini boot nosamples.jpg

2016-09-21T11:41:58Z

Asayuki: Bootleg Gemini Wing board with entirely missing audio samples section.

Bootleg Gemini Wing board with entirely missing audio samples section.

Pac-man (bootleg) Repair Logs

2016-09-11T10:38:55Z

Asayuki: Added another pacman repair (draft)

'''Repairer:''' Asayuki

'''Symptom:''' Music notes never stopping

'''Date:''' 3/Sep/2016

This bootleg board had a very funny issue on the audio: the notes of the music wouldn't stop and kept playing forever.

Check out for yourself: https://www.youtube.com/watch?v=Ckdzzu7wxBY

As you can hear, the music that plays when the game starts does not have the characteristic "staccato effect" which is
typical of the Pac Man game.

(proper Pac-Man music for reference: https://www.youtube.com/watch?v=dScq4P5gn4A&t=43s)

A lot of people wouldn't even notice the issue (let alone the seller of the board, who insisted that everything was fine, because of course!) until the music stops; in the first video you can somewhat hear that the last note keeps playing indefinitely after the music has finished playing. The note stops once I insert another coin; you can clearly hear the difference before and after that.

I initially tought this would be a software issue, because everything else seemed just fine and all the other sounds played quite well. I was definitely wrong, but this has been quite difficult to prove. I dumped the ROMset and found out that it was a weird mixture of files from several different sets all of which were already known to MAME. Since both this weird mixture and the missing Namco logo were disturbing to me, I decided to reprogram the board with a specific known ROMset which is a bootleg of the original japanese set. The Namco logo was back again after the cure, and the ROMset was in a state that was confirmed by emulation to have no sound issues. Yet, the audio issue persisted. I needed to use my logic analyzer and compare the behaviour of the board with the code's behaviour under MAME's debugger to realize what the problem was. And I had to delve deep into the sound generation logic of the game. The schematics of this Namco game are available; this made my fascinating trip a lot easier.

[[File:Pacman_audio_schematic.png|800px|frameless|center|Schematic portion of the audio section.]]

This schematic looks cryptic and strange, but it's a very clever design. Imagine Commodore's famous SID chip, with its internal three voices, different waveforms, ADSR and stuff. The Namco engineers implemented all that in software assisted TTL logic!

First of all, let me give you a reading key: the objects at 2L and 2K (74LS89) are two 16x4 RAMs. Yes, you read that correctly: 16 locations by 4 bits each! A total of 32 nibbles. The object at 1K (74LS283) is a 4 bit adder, the one at 1L (74LS174) is a latch. The custom at 1M is just a PAL with some custom logic from Namco. We'll see in a moment what it does, but for the time being you can consider that as a PROM. Finally there is another latch at 2M (74LS273) and two weighted resistors DAC circuits separated by a 4066 analog switch at 1N.

To understand how this works, we need a bit more information which is there in MAME (pacman.cpp) for the taking: the 32 nibbles stored in 2L and 2K are:
* 20 bit (5 nibbles) accumulator for voice 1
* 4 bit (1 nibble) waveform selector for voice 1
* 16 bit (4 nibbles) accumulator for voice 2
* 4 bit waveform selector for voice 2
* 16 bit accumulator for voice 3
* 4 bit waveform selector for voice 3
* 20 bit frequency value for voice 1
* 4 bit volume level for voice 1
* 16 bit frequency value for voice 2
* 4 bit volume level for voice 2
* 16 bit frequency value for voice 3
* 4 bit volume level for voice 3

Frequency and volume codes are stored in the memory at 2L, while accumulator and waveform are stored in the memory at 2K. The interrupt handler code of the CPU, called at the end of each video frame, copies blindly from the main CPU RAM to these two memories 32 values which it has elaborated previously. Therefore the audio generator gets updated once per frame.
Writing is done through the multiplexers at 3L (74LS157) and 3K (74LS158). The latter has a feature which inverts the output bits you feed in, which is a clever way of compensating for the RAMs at 2L and 2K also having inverted outputs.
When the CPU is not writing to these two memories, the multiplexers are switched to let the hardware control the memories.
The PAL at 3M (bottom left of the schematic) takes care of timing this hardware access.

All 32 values are read sequentially, 8 bits at a time. Once all of them has been read, the sequence repeats. This occurs very fast because it's timed by the horizontal scanning counter (4H, 8H, 16H and 32H). The frequency values come out LSB first from 2L, and at the same time the accumulator values come out LSB first from 2K. 1K sums them together and latches them in 1L so that the result is presented to the PAL at 1M. The result is also fed back to the RAM at 2K and written there as the new value for the accumulator. Since this is done 4 bits at a time, it's hard to follow. But for the sake of simplicity imagine the following:

You have a 16 bit value you call "accumulator". At regular intervals you sum this value to a constant 16 bit quantity you call "frequency". Your accumulator will increment by the given amount with every sum. The larger the frequency value, the faster the accumulator will increment. Once the accumulator has reached the maximum value it can hold, it will roll back to zero and keep counting. With this mechanism you have generated a "ramp" of upward-going numbers which gets steeper as you increase the frequency. Sounds familiar already? Now you can use this ramp of numbers as addresses into a wave table, right? That's exactly the purpose of the PAL at 1M. It internally generates digital audio waveforms based on this ramp value provided by the last nibble of the sum through its inputs A[0:4]. The other nibbles are just used for counting and don't take part in the actual sound data lookup. The waveform is selected by the inputs A[5:7] which come from the RAM at 2K. The 4 bit audio waveform data is then stored by the latch at 2M which presents it to the weighted resistors R6, R7, R8 and R9 at its outputs (Q[5:8]). At the other end of those resistors we have an analog signal.

The RAM at 2L also contains volume values, which are latched at the same time as the digital audio data from the sound generator PAL. These volume values are used to enable the single switches in the 4066 at 1N. These, in turn, forward or block the audio signal to the second weighted resistor set R1, R2, R3, R4 and R5. The final result is the ability to control the volume of the analog signal emitted by the sound generator.

Now that you know the entire mechanism you can better see the importance of the timing PAL at 3M, without which it wouldn't be possible to run this entire orchestra.

Back to our issue, it turned out that Pacman's audio code is lazy and doesn't clean up after its mess. It doesn't zero out the frequency registers when the notes finish playing, but rather shuts them up forcibly by setting a zero volume for them. Can you see where this is going? Yes, the 4066 analog switch at 1N had one defective switch which was letting the sound through even when it was not supposed to. Funny, eh? :)

[[File:Stage_clear.png|332px|frameless|center|Stage clear]]
[[File:LUCK-.png|332px|frameless|center|Lucky bonus]]

----

'''Repairer: channelmaniac'''

'''Model: Pac-1 / Pac-2 Pac Man board set'''
'''Symptom: Dead. Audio amp chip gets VERY hot.'''

Board has 2 edge connectors. The smaller one had a homebrew JAMMA adapter connected to it.

Board had activity on the EPROMs but no video out. Checked the pinout of the board on the large connector, traced it over to the small connector, and found that the board did not have the video pinned out correctly to the adapter. Checked the pinout and found the adapter to be totally wired wrong.

Rewired the adapter and when pinning out the small connector I found that there was no Coin 1 input on it. Used an unused pin and wired it to the Coin 1 pin on the large connector. Tested the board when finished.

----

'''Model: Pac-1 / Pac-2 Pac Man board set'''
Tip: Pinout for small connector

1: Gnd 
2: Gnd 
3: Gnd 
4: Speaker + 
5: +12v 
6: N/C 
7: N/C 
8: N/C 
9: +5v 
10: Player 1 Down 
11: Player 2 Down 
12: Player 2 Start 
13: Player 1 Start 
14: Player 1 Right 
15: Player 1 Left 
16: Blue 
17: Green 
18: Sync 

A: Gnd 
B: Gnd 
C: Gnd 
D: Speaker Gnd 
E: +12v 
F: 
H: 
I: 
K: +5v 
L: 
M: 
N: Coin 1 (Must be added! Connect to pin I on the large connector - across from pin 8) 
P: Coin 2 
R: Player 1 Up 
S: Red 
T: Player 2 Right 
U: Player 2 Left 
V: Player 2 Up 

Coin 1 input is NOT available on the small connector. Use the unused pad at location N to add it. Run a jumper wire from Pin I on the large connector to the pad at location N.

----

'''Model: Pac-1 / Pac-2'''
Tip: Software ROMs

The ROMs aren't readily available for this board but, the Namco Pac Man code is what it uses. It's just divided into 2716 EPROMs instead of 2732.

I didn't test all of them, but the EPROMs I did check are coded as this:

Pac-1 CPU board: 
6E: Lower half of namcopac.6e 
6F: Lower half of namcopac.6f 
6H: Not checked 
6J: Not checked 
6K: Upper half of namcopac.6e 
6M: Upper half of namcopac.6f 
6N: Not checked 
6P: Not checked 

I would assume the rest would follow suit as would the video EPROMs on the Pac-2 video board.

The ROM code was found in the puckman.zip file used for MAME.

----

'''Model: Pac-1 / Pac-2 Pac Man board set'''
Tip: Pinout for large connector

1: Gnd 
2: Gnd 
3: +5v 
4: +5v 
5: +7.5v Unregulated 
6: 2 Player Start Lamp 
7: Coin Counter 
8: Coins 2 Switch 
9: Service Switch 
10: 2 Player Start 
11: 1 Player Right 
12: 2 Player Up 
13: 2 Player Right 
14: 1 Player Down 
15: Gnd (Use for Speaker -) 
16: Video Green 
17: Video Sync 
18: Speaker + 
19: +12v 
20: +12v 
21: Gnd 
22: Gnd 

A: Gnd 
B: Gnd 
C: +5v 
D: +5v 
E: +7.5 Unregulated 
F: 1 Player Start Lamp 
H: Lock Out Solenoid 
I: Coin 1 Switch 
K: Test Switch 
L: 1 Player Start 
M: 1 Player Left 
N: 1 Player Up 
P: 2 Player Left 
R: Gnd for Table Mode (Unconnected for upright) 
S: Gnd 
T: Video Red 
U: Video Blue 
V: 2 Player Down 
W: +12v 
X: +12v 
Y: Gnd 
Z: Gnd 

Pinout courtesy of the Mowerman website. His site was down at the time I needed this but the Internet Archive had a copy.

[[Category:Repair Logs]]

File:Pacman audio schematic.png

2016-09-11T10:12:18Z

Asayuki: Schematic portion of Pacman's audio generator section.

Schematic portion of Pacman's audio generator section.

Ghost'n Goblins (Bootleg) Repair Logs

2016-08-19T02:07:27Z

Asayuki: More typos and small changes

'''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.

[[File:Gng_boot_board.jpg|800px|frameless|center|The A board of this bootleg]]

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...

[[File:Gng_white_stripes.jpg|800px|frameless|center|The funny white stripes]]

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.

[[File:Gng_schematic_a_1.png|800px|frameless|center|Schematics of the A board, page 1]]

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.

[[File:Gng_no_boot.jpg|800px|frameless|center|The board tried to boot but locked up.]]

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.

[[File:Gng_probes_at_cpu.jpg|800px|frameless|center|The boot process of this board is being debugged]]

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!

[[File:Gng_schematic_b_1.jpg|800px|frameless|center|Schematics of board B, page 1]]

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.

[[File:Gng_text_glitch.jpg|800px|frameless|center|Glitch on the text layer]]

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?

[[File:Gng_boot_parts.jpg|800px|frameless|center|The parts I replaced]]

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.

[[File:Gng_banking_bits_test_setup.jpg|800px|frameless|center|The logic analyzer is set up. Note the too many socketed ICs.]]

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.

[[File:Gng_banking_bits_fail.jpg|800px|frameless|center|The scope catched the guilty transition!]]

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.

[[File:Stage_clear.png|332px|frameless|center|Stage clear]]
[[File:L----.png|332px|frameless|center|Lucky bonus]]

----

'''Repairer:''' [http://www.aussiearcade.com.au/member.php/133-GameDude GameDude] 
'''Forum Thread:''' [http://www.aussiearcade.com.au/showthread.php/5845-Ghost-N-Goblins-%28Bootleg%29 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:''' [http://www.aussiearcade.com.au/member.php/1-Arcade-King Arcade King] 
'''Forum Thread:''' [http://www.aussiearcade.com.au/showthread.php/20971-Another-bootleg-GnG 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.
 
 
[[File:Pcb repair ghostn goblins bootleg2 2.jpg]]
 
 

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.
 
 
[[File:Pcb repair ghostn goblins bootleg2 1.jpg]]
 
 

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.

More Problems updated 19/feb/09

'''Problem:''' Title Screen graphics (high scores etc) colours flickering. 
'''Fix:''' Traced the problem back to a bad 74LS194(GSS) @ D11, Replaced the other 74LS194(GSS) @ D10 just to be safe. 

'''Problem:''' Game runs for a bit then crashes, when you try to turn it back on your get a "vram is bad error" 
'''Fix:''' Sigh man by the time im finished with this board it will be completely rebuilt. Had a bad 74ls157 @ 5H, using the probe you could "hear" the chip failing. The outputs sounded sick, looked sick were sick. I ended up replacing all of the 157's just to be safe. 

'''Problem:''' Problem to end all problems Game was running fine for awhile then died...again! Screen background covered in random garbage and foreground was mostly zeros (see attached pic no.2). When you turned on the board you could see the garbage in the background cycle like it was doing its self test so I assumed the program was running but halting with an error. 
'''Fix:''' I spent 4 nights on this on and off the bloody thing was driving me nuts I couldn't put it down! (even though I said I threw it on my shit pile)
I decided to remove all the chips i had socketed which was all the 245's. I also removed all the roms, main MC68B09P CPU and the 6264 and 6116 ram's. I was convinced the problem was had something to do with the character video ram. I poked around the 6116 with my scope and noticed some of the address were doing nothing, Using the schematics I traced it back to a set of 3 74ls157s (all of which I ended up replacing). I noticed pin 14 which is an input of the 157 @ 5H was sitting high. Using my probe and the schematics I traced the input (AB0) back to see what IC's its connected to. I immediately knew there was a problem when I traced it back to an 74ls245 @ N6 pin 11 which had already been replaced, with the chip removed pn 11 was sitting high when it should have been dead along with the rest of the row of pins on the socket (pins 11-18). I knew there must be a short somewhere. Going back to the schematics I traced AB0 through to a couple of other IC's, a 74ls259 @ B9 (pin1) and a 74ls138(GSS) @ A3 pin 1.

The 259 was an Hitachi brand and IMO they are a very robust (ive yet to find a dead one on any PCB I've worked on) The 138 was however a GSS which has been problematic through out my repair.

The 259 looks like it had been replaced previously so I went ahead and used my side cutters to cut pin one which is an input on the 138. Fired the board up and away she went! I really hate these sort of faults where an input shorts.

The 138 is part of the I/O Port so disabling it didn't stop the game from running. Replaced the 138 and the game has been runing for about 3 hours without a hitch.

Before I did this last repair I did replaced all the roms and CPU on the board, I noticed the Roms were getting VERY HOT to touch, not only the roms but the main CPU, the 2 Yamaha sound chips and the 245's were all hotter than they should be. Before finding the above fault I replacing all the Roms the board now runs nice and cool. I think this confirms this board had been spiked at some point. Even when I first got the board running the game would crash to a white screen at random, some time's I got an hour out of it other 10 seconds, anyway shes all fixed...for now

PS: I always try and replace faulty IC's with either Hitachi or Mitsubishi brad, I find these to be extremely well made.

Update: 21/2/09

Bloody thing developed another fault but really it was my fault for not replacing the IC anyway.
Problem: Character sprites colours all messed up.
 
 
[[File:Pcb repair ghostn goblins bootleg2 3.jpg]]
 
 

Fix: This was the last GSS branded 74ls174 @ H1 on the CPU board and stupid thing was I knew it was on the way out but forgot to replace it. As soon as i saw the graphics colours screw up I knew what the culprit was.

'''Repair Logs converted to wiki format by Brad from [http://www.aussiearcade.com.au Aussie Arcade]'''.

[[Category:Repair Logs]]

File:Gng banking bits fail.jpg

2016-08-19T01:35:58Z

Asayuki: Banking bits latch failing on a bootleg Ghosts 'n Goblins board.

Banking bits latch failing on a bootleg Ghosts 'n Goblins board.

File:Gng banking bits test setup.jpg

2016-08-19T01:33:16Z

Asayuki: Logic analyzer setup for testing of the banking bits on a bootleg Ghosts 'n Goblins board.

Logic analyzer setup for testing of the banking bits on a bootleg Ghosts 'n Goblins board.

File:Gng boot parts.jpg

2016-08-06T13:09:40Z

Asayuki: Parts replaced on a Ghosts 'n' Goblins bootleg board

Parts replaced on a Ghosts 'n' Goblins bootleg board

File:Gng text glitch.jpg

2016-08-06T13:08:07Z

Asayuki: Ghosts 'n' Goblins, glitch on the text layer

Ghosts 'n' Goblins, glitch on the text layer

File:Gng schematic b 1.jpg

2016-08-06T13:06:32Z

Asayuki: Ghosts 'n' Goblins schematics, B board, page 1

Ghosts 'n' Goblins schematics, B board, page 1

File:Gng probes at cpu.jpg

2016-08-06T13:03:56Z

Asayuki: Debugging a Ghosts 'n' Goblins boot process

Debugging a Ghosts 'n' Goblins boot process