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


Konami Hyper Olympic bootleg arcade pcb repair

This board worked but had a strange magenta outline around the characters.  This was a very time consuming repair for what seemed a little fault, it didn’t help I started down the completely wrong path..



What wasn’t the problem

The eproms and color prom all tested good – so it wasn’t a simple case of corrupt data.  I’ve talked in many repair logs about pairs of sprite line buffers, which are present on this board as many others.  Because the magenta outline was present on all scanlines, this meant the problem had to be after the eproms (where the sprite data is sourced) but before the split into the two line buffers OR after the two line buffers are recombined before reaching the color prom.  So this cuts the potential problem chips right down – the eprom data goes to a bunch of 4 LS194 shift registers, which feed into the two sprite RAMs.  The data leaving the RAM travels to a LS273 then a LS157 which recombines into a single data stream (which goes to the LS258 which acts as the priority selecter by picking between either a sprite pixel going to the color prom or a tilemap pixel).

However, every single chip tested good, so this theory ended up being a complete waste of time.

What was the problem

The clue came when I forced the color prom to display only tilemap colors or only sprite colors (you can do this by forcing the top address line of the colour PROM either high or low – as per OBJOUTD at pin 14 on the schematics).  With the sprite palette forced on the sprites were 100% correct – after checking the palette in MAME I finally understood the fault – the ‘first’ pixel of the sprite was using the tilemap palette, as the magenta only existed in the tilemap palette and was being used instead of the dark brown expected by the sprite.



So why could that be…  In the schematics you can see OBJOUTD controls the prom switching between tilemaps and sprites, but the OBJOUT signal controls the data switching.  A LS174 makes the OBJOUTD and you can see it’s generated 1 CLK later on from OBJOUT.  Why I have no idea..  I didn’t find any problem there so I just patched OBJOUT to drive the prom directly – and this made the magenta outline appear on the right side, rather than left.  So instead of the prom palette being a pixel behind it was now a pixel ahead.  So it was as if the switch happened ‘half a clock’ out of time which is pretty weird.


I examined what drove the CLK1 and /CLK1 signals which was an LS368.  On the original Konami board a custom chip drives the LS368.  However, on the bootleg was a weird hack involving two capacitors on the clock input line – one was damaged and removing it made the graphics perfect!  Not altogether uncommon to see hacks like this on a bootleg (a capacitor delaying a clock, in this case by ‘half’ or inverted phase) but not easy to find.




Leave a Reply