Repair Logs – Page 107 – JAMMArcade.net

Galaga repair log

Jul 312014

Stored this original Galaga PCB from a while but never looked at it deeply:

It had a piece of tape on it saying “Dead” but at a first visual inspection I noticed it missed the custom marked ‘0020’ (tilemap address generator with scrolling capability) on CPU board @1H.So I thought game is over, I was doomed .The only chance I had was using some modern replacement (based on CPLD or FPGA).But, then, my savior appeared under the name of Silvio, a guy met over over ArcadeItalia forums (thank you again and again..) who very kindly donate me this custom chip.

So, time to build the needed JAMMA adaptor and I fired up the board getting this:

Horizontal white stripes all over the screen, a good point to begin from 🙂

So, I started to touch and press the board in different places and I noticed that if I pressed the custom marked ‘0200’ (GFX data shifter and mixer) @4H on video PCB , issue disappeared.So, it was clearly a matter of bad contact due a corroded socket and this was confirmed by replacing it with a new one:

I was happy since I thought board was 100% fixed but when I started a game I noticed (or better, heard..) something odd : all sound FX (explosions, etc..) were fine but music was muffled, almost distorted.

So , schematics in hand, I was starting my troubleshooting on audio section when I noticed that a 1KOhm 5 pin resistor network @RM2 was missing from my board:

Looking at schematics I found that this should have been connected (and acted as pull-up) to outputs of the near N3101AN (7489 equivalent) @2A which is one of the two RAM used in sound circuitry .So, with confidence I installed a new resistor network and…. music really came back crystal clear as it should be.

Another great classic preserved!

Lightning Fighters repair log #1

Jul 292014

Received today from Spain this Lightning Fighters orginal Konami PCB (bought on Ebay some days ago):

Seller sold this as faulty saying game suffered from graphics glitches.

He was right (positive feedback for his honesty…)

I immediately thought it was something related to tilemap generation since part of screen was doubled and drawn in wrong place while sprites were good.So, I started to check this part of circuit.This hardware, like many other from Konami, use some ASICs in QFP package to generate parts of graphics.This PCB uses two of them to create the tilemaps, they are marked ‘052109’ and ‘051962’ and always used in pair.Checking them I found a couple of lifted pins on the one marked ‘052109’, I reflowed them but issue was still present.

So I started to think about : technically speaking, an ASIC behaviours like a CPU, so in this case it takes datas from graphics ROMs and stores them in RAMs.When it wants to read these stored datas, it addresses the RAMs.

So my issue should have been due a bad RAM adressing since screen fullfilled of zeros, graphics drawn in wrong place are clear symptoms of it.So, I started to check the two 6264 SRAM @H24 and J24.All address lines was shared between except for A2 (pin 8).This abnormality was also confirmed by schematics:

I noticed that someone replaced (or desoldered for testing) these two SRAMs previously so probably he managed to cut the track between the two address lines.So I jumpered them with a bit of AWG30 wire and all graphics came back to normality:

What can I add more?End of job!

X Multiply repair log #2

PCB Repair Logs, Repair Logs 2 Responses »

Jul 262014

I recently sold this PCB but after a week I was told the board had developed a fault.
The fault showed up as “RAM NG 10” at boot-up and there was some issues with the sprites.

There is absolutely no logical meaning to the error message so using MAME I started corrupting different RAM values during it POST to see what RAM errors were flagged up during which memory writes.
Originally I couldn’t understand how the awful V30 CPU worked. Without knowing how it worked I was unable to use the MAME debugger effectively. Charles MacDonald came to my rescue and told me how the V30 addresses were set. Thanks very much to Charles.
You can see the outcome of that exercise in THIS previous post.

So now I knew for sure that the fault was with the sprite RAM. Now the next challenge, which RAM chip is the sprite RAM?
I originally tried shorting some address/data lines on RAM chips to see if any other errors were flagged but strangely it didn’t show anything else at all.
With nothing left to try I started making my own schematics up in the hope I could work out which RAM was responsible for the sprites.

Due to the complex nature of this board set, I was stuck for quite some time looking on the lower video PCB assuming (yes I know) that this is where the sprite RAM could be but was unable to find any problems at all.
Taking a step back I reversed the PAL chip XM_A-7D- into equations. Using these equations and the schematics I had drawn up I could take an educated guess as to what RAM chip was the sprite RAM.
Knowing that the sprite RAM lies at address 0xc0000, this means that address pins A19 & A18 would need to be active. Looking at the equations I could see that output pin 17 of the PAL chip would fit this address so I followed the signal which led to the /CE line of a 74LS245 of IC40 on the top CPU PCB.

The only chip that this chip goes to is a 2018 RAM chip at location IC52.
This was pretty good news. I removed the chip and it failed the tests so I replaced it and now all the POST tests pass.
The sprites are all back to how they should be too.

Ill be keeping hold of this board I think. It was one of the first games I ever bought since getting into this hobby so it will stay with me for good now.

Konami GT repair log

PCB Repair Logs, Repair Logs Comments Off

Jul 232014

A friend of mine sent me this really mint original Konami GT PCB saying it suffered from vertical stripes across most part of screen.

Fired up the board and …he was right 🙂

Initial test said all RAMs were good so the problem was elsewhere.Without any schematics I started my visual inspection as usual.I noticed that the only IC replaced on this mint PCB was a 74LS157 @H13.Since a socket was installed, I removed this IC and all the part of graphics affected by stripes disappeared so I started to think problem was generated after this part of circuit.In particular I traced an output (pin 7) of this 74LS157 to pin 4 (RAS) of some TMM4164 DRAMs (there are 16 of them).Probing these DRAMs with my logic probe revelaed that on four of them pin 2 (DATA IN) was pulsing but the pin 14 (DATA OUT) was stuck high.So I desoldered (they were @G2, G3, H4, H5 position) and test them in my Hi-Lo Systems ALL-07A programmer and the result was this:

They all failed miserably.I was lucky since had some good 4164 DRAMs taken from a scrap PCB in order to repair a Commodore 64 motherboard.Installed them and goodbye stripes for ever!Board 100% fixed.

Juno First repair log #3

PCB Repair Logs, Repair Logs Comments Off

Jun 262014

Third repair log from the batch of Juno First boards.
On power up the board was completely dead. No clocks were present on the CPU or many other IC’s.
As this is a bootleg board the available schematics do not fully apply and the clock circuit is normally handled by custom chips so this was a bit of a learning experience.
To help in dealing with this problem I started making my own schematics up.

Using a logic probe I could see that the outputs of the 74LS161 @ H14 were all HIGH. As there is no clock present to this chip it should not have counted anything at this point and they should all be LOW. This meant to the board was booting up in an incorrect state and the clock circuit was never starting.
I desoldered and replaced the offending 161 chip.

The clocks were now all present but I just got a static blue screen and the watchdog was constantly resetting the system.
Using my in circuit Arduino tester I knew the ROMs could all be read correctly by the CPU. I also knew all the program RAMs were fine.
Replacing the 6809 CPU allowed the game to boot properly.

Next problem was the sound or lack of it.
The sound CPU is a good old Z80 so I fitted the Fluke and did a ROM check. This reported back an incorrect signature and when I removed the ROM I see this

The VCC pin was missing. I soldered a new pin onto this and this board is fully fixed.

The last bootleg board has been a major pain and at this point in time I have admitted defeat with it. I have also been harvesting parts from it to fix the others so it will be written off.

Older Entries Newer Entries