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


Konami Vendetta arcade pcb repair

Game booted to a solid white screen.  Often this can be failed palette RAM as if it fails and all outputs stick high this is usually interpreted as white for every pixel.  Spare RAM was piggy backed onto the palette chips at 7F and 8F and success – some garbage displayed!


Amongst the garbage was a string about bad RAM at 16C- this is the main program RAM.  Another chip was piggybacked to replace the failed one and the familiar Konami check screen came up.


At this point though the repair slowed down a lot – bad RAM was reported at 16G and 16F – this is the tilemap ram.  4F and 5F is the audio RAM and ROM.  Now the audio ROM checked out ok compared to the MAME set, and piggybacking RAM made no difference.  I wasn’t convinced 16F/16G were actually bad either – as if they were the check screen itself should be corrupt.

Eventually I modified the program ROM to continue past the check screen (simple NOP for the branch that resets after the test – quickly found with the MAME debugger).  And despite the errors – the game ran pretty good!  Sound was 100% correct and the only graphics glitch I could find was the high score table.  A weird glitched also existed where pushing up on the joystick started the service menu and pushing down made all sprites disappear.  Inside the service menu the mask ROM test reported every ROM as bad – even though they clearly were not.




The MAME source code had some interesting info:


PORT_BIT( 0×01, IP_ACTIVE_HIGH, IPT_UNKNOWN ) PORT_READ_LINE_DEVICE_MEMBER(“eeprom”, eeprom_serial_er5911_device, do_read)
PORT_BIT( 0×02, IP_ACTIVE_HIGH, IPT_SPECIAL ) PORT_READ_LINE_DEVICE_MEMBER(“eeprom”, eeprom_serial_er5911_device, ready_read)
PORT_BIT( 0×08, IP_ACTIVE_HIGH, IPT_CUSTOM ) PORT_VBLANK(“screen”) /* not really vblank, object related. Its timed, otherwise sprites flicker */


So joystick up on the 1 player input port is bit 0×4 – same as the service bit 0×4 on another port.  Joystick down is bit 0×8 and that same bit affects sprites.  So it’s clear those are being mixed together somehow.  The culprit turned out to be an LS04 chip that the schematics show controls the enable pins on some input buffers.  Probably the player 1 input buffer and the service/sprite buffer both enabled at once.



So the final problem on the pcb took ages to find – literally the last thing I checked were the two custom programmed PAL’s that are used to form the CPU memory map.  It seemed very unlikely there was any problem there given how much of the game worked fine.  Whenever a replacement GAL was programmed and piggybacked on top of P2 the RAM/ROM check errors went away and the high score table was fixed!  An extremely unusual fault.  The PAL clearly worked 99% of the time until some timing edge case occurred.





Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>