Professional software development, amateur BMW tinkering, old arcade game stuff


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.


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.


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.


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


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.


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.


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.