BryanMcPhail.com

Professional software development, amateur BMW tinkering, old arcade stuff

By

Taito Chase HQ arcade pcb repair

Initially a completely dead board, with no clock signal at the CPU.  Some probing revealed the crystal oscillator didn’t have any power going to it, and in fact nothing on the top board had +5V.  There was a very unusual broken trace on the main +5V line from the edge connector, and a handful of capacitors that had pretty much came apart.

IMG_4239 IMG_4235

With that fixed the board booted to a lot of garbage graphics – no sprites and no road layer.

O8wRopK

The road layer is handled by the top board – pretty much the custom chip, two RAM chips, a ROM and a PROM (the other two RAM chips in that corner are the palette RAM).  In this case the 63s141N PROM had failed and had dead outputs.  A PROM was taken from another board and the road layer fixed.

IMG_4328

The title screen had some interesting sprite behaviour – the first entry in the sprite list seemed to be drawing somewhat correctly (The ‘CH’ of the Chase HQ logo).  That made me wonder if some kind of counter had failed and it was only processing the very first address of sprite RAM over and over.  There are a bunch of LS161 counter chips on the video board and there was a dead input on some of them.  This traced back to a PAL chip which was replaced by one from another board and all sprites displayed, albeit with a lot of garbage and vertical line corruption.

IMG_4266 IMG_4325

The final part of the puzzle are the 16 sprite work RAM chips on the video board – if any of these fail it will tend to be vertical lines or other corruption throughout the screen.  The sprite RAM seems to be in ‘screen space’ – so faults don’t follow the sprites but instead have constant positions on the screen.  On this board 5 chips were confirmed as bad and when replaced the board was 100% again!

IMG_4326 IMG_4271

 

IMG_4295    IMG_4286 IMG_4284

 

By

Namco Pacland arcade pcb repair #2

This pcb booted up but with corrupt graphics.  Helpfully Pacland does a self-test on startup and this one briefly printed 0 0 4 on screen (or arguably 4 0 0 as the self-test is printed upside down – to clarify the 4 is the first digit to appear).  This means a RAM error and as I have a working Pacland to compare against it was quite easy to work out what error digit corresponds to what chip.

IMG_3562 IMG_3566

Piggy-backing a replacement chip on top fixed the corrupt text and the top scrolling layer so for sure RAM was bad.  The bottom scrolling layer was now completely absent though and the self-test didn’t report any errors.

IMG_3575

As I had a working board I swapped the custom chips and tilemap ROMs between boards just to rule them out and it made no difference.  I suspected the fault was in the priority mixing circuit – this is what decides what pixel is ‘on top’ be it text, sprite or a scrolling layer.

IMG_3578

The relevant chunk of the schematics is above, essentially the sprites and top scrolling layer are mixed by custom chip 29.  The bottom scrolling layer is produced by custom chip 30 and drives the ROM at 4N.  A pair of LS298 multiplexer chips then decide what takes priority – the background layer or the sprite/foreground layer.  The LS298 selector is driven by an 8 input AND gate (LS30 @ 1N).  This is really what determines ‘transparency’ in the sprite/top tilemap layer – if any of the 7 bits are high for a given pixel then it is ‘opaque’ – all low means ‘transparent’ and the lower layer should be shown.

IMG_3579

On this board the LS298 chips and the LS30 are all manufactured by Fujitsu, which is known for a terrible failure rate.  A logic probe showed the output of the LS30 chip was dead – so the LS298′s in turn were constantly stuck.  Replacing the LS30 with one from a Dragonninja parts board fixed the problem.

IMG_3584 IMG_3585 IMG_3589

By

Capcom Gun.Smoke PCB repair

This is a bootleg PCB though a well made one with excellent image quality.  The problem is that the buildings have corrupt colours.  This is a rather strange fault as Gun.Smoke only has 1 layer of tiled graphics and all of the other tiles were fine.  This rules out almost all potential RAM or TTL faults (maybe with the exception of some of the palette circuitry), as those components are clearly working fine with the other tiles.  From the look of the graphics I suspected a couple of bit-planes for the tiles had disappeared – because each tile only has 4 colours per block, instead of 16.  MAME confirmed the tile ROMs were laid out as 4 pairs with each ROM contributing 2bpp and the corrupt buildings were within the first pair.

IMG_0864IMG_08642

The missing 2bpp theory was confirmed when I ran the board with ROM ’13′ removed – the buildings completely disappeared – so this means that ’13′ was working and it’s partner ’9′ wasn’t contributing anything.  However all ROMS read ok in the reader and matched the MAME set exactly.  The logic probe lit up for all pins on ROM ’9′ so the socket seemed good.  Next theory was the chip enable (/CE) logic was faulty and ROM ’9′ was not being asked to output any data.  However examination of the traces showed /CE was linked for each pair of ROMs in the set (as they always output at once to give make 4bpp output) so could not be that.

IMG_0884

I then burned a new eprom with ROM ’9′ data from MAME, placed it on the board and everything worked!  So the fault was definitely with the ROM even though it read fine on PC.  The only theory I have is that the original ROM ’9′ is more susceptible to low voltage than the others.  There is quite a bit of voltage drop from the +5V on the main board to the video board.

IMG_0892

By

Pacland PCB repair

After making a custom loom for this untested pcb, I found it booted to garbage. Booting to garbage is at least better than not booting at all though as it shows the video output section is at least running.  After checking the voltages at the chips were 5V (or slightly higher) and that the program eproms I examined other socketed chips and found the custom chip 34 had badly corroded pins when removed from the socket, and a few of the legs snapped completely.


Repair 1 – clean up the corrosion and mount the chip in a new socket and solder through from the broken pins to the socket top. Not the prettiest fix but it works.

 

Unfortunately, this didn’t change much with regards the corruption. So I put a logic probe on the CPU and found the clock pins (Q & E) and the address and data bus pins had activity on them. However, the read/write pin seemed stuck high – this means the CPU could only be reading from RAM, never writing to it and a CPU that can’t write data certainly can’t run properly. The CPU also got very hot very quickly.

Theory 1 – CPU has failed internally, and R/W has stuck high.
Theory 2 – the chip the R/W pin connects to has failed and forced the R/W line high regardless of what the CPU tries to do.

The CPU is in a socket so that’s the easiest thing to try first – however I didn’t own others of this type to swap in (HD6309, slightly different from regular M6809) so had to wait a week to order some from Ebay.

And.. didn’t help, no change. The R/w pin connects to an LS368 chip at location 5A and suspiciously it has corroded pins, even though all the chips around it are perfect. So remove and replace that.

And.. still corruption, though it’s different and it seems the CPU is definitely doing ‘something’ as the corruption cycles a few times before stopping. In retrospect I think the stuck R/w pin theory was a bit flawed – if it was truly stuck then the corruption would probably be random each time, and this was consistent. Instead more likely the CPU started to run the program then just parked itself in an infinite read loop when it detected a failure.  The LS368 was probably bad in some other way though.

So Pacland in MAME shows that on boot the game should print 0 0 0 on screen to show all self-tests passed.  The curious thing about the new corruption is you could clearly see the screen clear a few times then a couple of zeros appeared, just not where you would expect them to be.

So new theory – RAM is bad – as when the CPU tries to write the zero character it gets reflected in a bunch of other locations (so the internal address decoding has failed).  So, desolder and test the 7 6116 RAM chips on the top right of the board.  The top 4 is the RAM for the tile maps, the bottom 3 is for the sprites and CPU workram.

Unfortunately, all the RAM tested good.  So..  time to examine the schematics to see what is in-between the RAM and the CPU.  I desoldered the IC’s at 10B, 9E, 9D, 10N, 9F – these control the enable lines to the RAM.  All tested good so no progress.

Usually in arcade schematics you read from left to right – inputs on the left, and outputs on the right.  There’s an exception in Pacland though, as the tile map ram chips can be addressed by the main CPU, or by the graphics hardware through a custom chip.  So the address bus on the right of the RAM in the schematics is actually an input, and it comes from a pair of LS365 chips.  These chips seems relatively rare on arcade pcbs, and my tester doesn’t support them.  Their use seems to be in allowing both the CPU and graphics hardware access to the RAM chips.  This is driven by the 2H signal – from the name I assume it toggles twice for every horizontal pixel – so for every pixel on the screen both the CPU and graphics get RAM access.

Switched these chips out for new – and instantly no more corruption!  The 0 0 2 self test signals bad RAM, but this was expected as I hadn’t replaced the sprite ram at this point.

In game however, corruption remained on the backgrounds, but at least sprites and logic were working 100%!  Time to look at the video part of the schematics which I’d mostly ignored until now.  Custom chip 36 makes the tile maps.  It has access to the tile map ram of course, two eproms with graphics data, and two color proms.  We know the tile map RAM itself is good, so time to test the LS174 and LS86 chips that drive addressing to the graphics eprom.  Unfortunately all tested good, so the problem wasn’t there.

Tracing back further shows a LS365 and LS366 involved in addressing the tile map ram from the graphics side (NOT used by the CPU side access).  Really I should have tested them first as having already found a bad LS365 there’s a good chance another from the same batch would have failed in the same way.  Replaced these and everything was good!

 

 
Time taken : > 10 hours over 3 weeks (lots of waiting for parts to arrive)

By

Rastan PCB repair

Ok, calling this is a ‘repair’ is probably a misrepresentation as it was so easy. I bought this pcb from a junk pile and it arrived a bit dusty but not physically damaged in any way. It was missing all eproms (68K program, Z80 audio program, audio samples eprom) and the socketed PAL at IC58 (PAL16L8). The schematics show that IC58 generates monitor sync so it definitely wasn’t going to show anything without that..

Burned all eproms from the MAME set, and the PAL16L8 onto a GAL with thanks to the PLD images at http://www.jammarcade.net/pal-dumps/

And it worked! Well, almost – no sound and wouldn’t accept any coins. It seems this is due to the connector marked H on the board. I’d assumed this was a stereo sound output, but it seems 12V is required here in order to power the sound amp and coin IO. 12V from the jamma connector already runs here – so you have to jumper pins 1 & 2 together and 3 & 4 together to enable sound & coins. With this done the game worked fine.

Mystery 1 – why does connector H even exist, when 12V is already at the jamma connector!?
Mystery 2 – why did an operator strip a (presumably) working board just for some cheap eproms and a PAL? I guess something else more important at the time needed the parts.

By

Wells Gardner K4900 monitor fix

This JAMMA cabinet had gone pop almost two years ago, time to diagnose why. On applying power the primary fault was quickly identified – high voltage fireworks were literally shooting out the top of the flyback! You can see the burn marks on the picture, but there is probably a hairline crack as well.

So, remove old flyback, install new one… and it worked! Great to find the fault hadn’t taken out anything else on the board. Usually this would be a good time to install a cap kit, but it seems the previous owner must have done this at some point, as all the caps looked new. (Disclaimer, do not attempt to remove or even touch the flyback or tube if you don’t understand how to safely discharge a CRT. Very high voltages can be present even with power off).

Apart from some screen burn in, picture quality is great for a 33 year old monitor!