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.






Konami TMNT arcade pcb repair

Board #1


Game played, but with an overlay of text over everything.  I suspected the tilemap custom chip wasn’t reading from tilemap RAM properly but nothing seemed obviously wrong until I found some bad traces on the bottom of the board.  Someone had previously tried to repair them, and it had probably worked at the time but now the thin lines had corroded further.  A patch wire on the top of the board was the safest fix.

IMG_5294 IMG_5304


Board #2


Board booted to consistent screen of garbage text.  I had a hunch this was actually the ROM/RAM check screen – but with the graphics addressing broken in some way so incorrect text was displayed.  Logic probe check on tilemap related chips (found via schematics) found a dead input to the LS139 that controlled VRAM chip select.


Pin 3 (A16) comes direct from the main CPU and with this floating it caused garbage to be loaded to VRAM.  I couldn’t find any broken traces, but there must have been one somewhere.  A wire patch was added underneath the board direct to A16 on the 68000 and everything worked.






Technos Double Dragon arcade pcb repair

Board played but no sound at all.

First thing was to check the amplifier – there was a faint humming sound from the speaker and the hum changed as the volume control was moved, so the power amp part at least seemed to be working.

Next thing is to check the digital side – a logic probe showed the sound CPU pulsing as well as the ROM and various address and data pins, so it was definitely executing code.  A good trick here and on similar games is to check if the YM2151 IRQ pin is pulsing – this is because the YM2151 will only send out interrupt requests if the Z80 correctly programs it.  If the CPU is just executing garbage then it’s unlikely the YM2151 will get the correct setup commands.

In this case – the logic probe showed the IRQ pin was stuck high.  More probing showed the RAM chip enable (CE) pin never pulsed either.  So it seemed the CPU program had probably crashed because it could not access the RAM.  Schematics showed CE is driven from the LS138 at IC79 and indeed amongst the dirt there seemed to be some water damage/corrosion!

The LS138 turned out to be fine though a logic probe showed pin 1 wasn’t connected to anything.  Schematics show it should connect to the Z80 address bus – in fact this trace had corroded so I soldered a patch wire on the board underside.  The YM2151 IRQ started pulsing and music worked!


Footstep samples however just played a loud static noise – this game has two MSM5205 sample players.  These take 4 bit data, so a pair of LS157 multiplexers convert the 8 bit ROM data into two 4 bit halves to feed the sample player chip.  One of the LS157 output lines also went through the corroded area which meant a dead input into the MSM5205.  The line was patched and all sounds worked again.





Taito Chase HQ arcade pcb repair #2

Two different boards with pretty much the same fault – some kind of horizontal glitch in all the sprites with blocks of 4 pixels appearing out of place.

IMG_5359 IMG_5365

At first I thought this would just be a simple addressing problem affecting the sprite ROMs but when I examined the data format in MAME each 16 pixel row of each tile is stored at a unique address (so the 16 pixels map directly to the 16 bits on the ROM data bus).  So if the glitch is within a 16 pixel block it can’t be addressing, it has to be elsewhere.  Unfortunately the problem wasn’t easy to find as the entire video board is for sprite processing.  Eventually I found it – dead outputs on the PROMs at IC92 or IC94 can cause this.


Only one PROM of the pair was bad and it was replaced with one from a parts board.  Problem solved.

IMG_5376 IMG_5392


Capcom Tiger Road arcade pcb repair

This game had every second scanline missing in all the sprites.

IMG_5215 IMG_5217

A lot of arcade game games work by using two line RAM buffers for sprites – the sprite logic builds line N+1 in RAM0 whilst line N in RAM1 is displayed to the screen, then they swap and RAM0 outputs to the screen whilst the new line is built in RAM1 and so on.

So a missing scanline in sprites suggests one of the RAM chips in the double buffer has failed.  By piggybacking good RAM onto the chips on the video board I found the fault right away.  The lower line buffer RAM had failed.  A new one was soldered in and game fixed.

IMG_5222 IMG_5227




Rare Battletoads arcade pcb repair

(One of the most complex/time consuming repairs I’ve done – so a very detailed write-up!)

Part 1

The board initially showed no signs of life with most TTL on the board not active at all.  Digging deeper showed there would be tiny pulses of activity then nothing for a few seconds, then repeat, so it seemed a watchdog was constantly trying to reset the CPU.  This was confirmed on the /RESET line of the CPU which was being pulled low for a period then released high as expected.  Voltage to the CPU was good, as were the clock signals (the TMS34020 takes two clocks, one regular CPU, one ‘video’ clock).

The first thing the CPU is meant to do on reset is to fetch the reset vector from program ROM so it can start executing code.  So examining the program ROMs showed the address lines were all pulsing at reset as if the CPU was trying to read, but the ROMs never output any data.  The reason why no data was output is because the /OE (output enable) line is never set.  There are no schematics available for this game, so to figure out why requires a lot of tracing and reverse engineering.  Time to go deep..

Program ROM /OE is driven from pin 19 of the programmable GAL chip at U144.  I dumped the GAL to equations, and also did the same with the MAME dump – both match so I can rule out the GAL itself being bad.  The equations are:

/o21 = i7 * i8 * /i9
/o20 = i23 * i7 * /f17 * i8 * i9 * /i10 * i14 * /i11
/o19 = i23 * i7 * /f17 * i8 * i9 * /i10 * /i11
f17 = i3 * /i4
o16 = vcc
/o15 = i7 * /f17 * i8 * i9

So the outpin on pin 19 (/o19) is a function of 9 different inputs.  Ouch.  Without knowing what they do yet, I can see that all except i10 pulse at reset.  Time to trace where they all go, which is very time consuming with the tiny traces on this board.

i7-i9 are effectively bits 29-31 of the CPU address bus (they get latched into the LS373@U139 first).  It makes sense these bits are involved, because if we reference the memory map from MAME – those top 3 bits are used to identify each ‘section’.

static ADDRESS_MAP_START( main_map, AS_PROGRAM, 16, btoads_state )
AM_RANGE(0×00000000, 0x003fffff) AM_RAM
AM_RANGE(0×20000380, 0x200003ff) AM_READWRITE(main_sound_r, main_sound_w)
AM_RANGE(0×20000400, 0x2000047f) AM_WRITE(misc_control_w)
AM_RANGE(0×40000000, 0x4000000f) AM_WRITENOP    /* watchdog? */
AM_RANGE(0×60000000, 0x6003ffff) AM_RAM AM_SHARE(“nvram”)
AM_RANGE(0xa0000000, 0xa03fffff) AM_READWRITE(vram_fg_display_r, vram_fg_display_w) AM_SHARE(“vram_fg0″)
AM_RANGE(0xa4000000, 0xa43fffff) AM_READWRITE(vram_fg_draw_r, vram_fg_draw_w) AM_SHARE(“vram_fg1″)
AM_RANGE(0xa8000000, 0xa87fffff) AM_RAM AM_SHARE(“vram_fg_data”)
AM_RANGE(0xa8800000, 0xa8ffffff) AM_WRITENOP
AM_RANGE(0xb0000000, 0xb03fffff) AM_READWRITE(vram_bg0_r, vram_bg0_w) AM_SHARE(“vram_bg0″)
AM_RANGE(0xb4000000, 0xb43fffff) AM_READWRITE(vram_bg1_r, vram_bg1_w) AM_SHARE(“vram_bg1″)
AM_RANGE(0xc0000000, 0xc00003ff) AM_DEVREADWRITE(“maincpu”, tms34020_device, io_register_r, io_register_w)
AM_RANGE(0xfc000000, 0xffffffff) AM_ROM AM_REGION(“user1″, 0)

As an example you can see output 21 on the GAL has this equation:

/o21 = i7 * i8 * /i9

So if i7 is set (0×20000000) and i8 is set (0×40000000) but i9 is NOT set (0×80000000) then the resulting address is 0×60000000 which means ‘nvram’ is being accessed in the map.

Back to output pin 19..  i3 and i4 are effectively address bus bits 2 & 3 (latched via ls373@u7).  i11 goes straight to pin 8 on the CPU which is /RAS.  i10 goes to CPU pin 133 which is ‘/TR /QE’.  So if we refer back to the equation:

/o19 = i23 * i7 * /f17 * i8 * i9 * /i10 * /i11

For /o19 to be low (and enable the program ROM) we need the address lines to be correct, /i11 (RAS) to be low which it always is, but also ‘/TR /QE’ to be low, which always measures as high.  The manual describes ‘/TR /QE’ as ‘Transfer/output-enable.  During a local-memory read cycle, TR/QE
functions as an active-low output-enable to gate from memory to LAD0–LAD31.‘.  So it makes sense it’s involved, it’s part of the cycle of reading, but why is it stuck?


At first I thought the CPU had just failed internally – but there are some control pins that can affect the CPU state.  The bus fault (BUSFLT) pin checked out ok, and the CPU wasn’t stuck in host mode (HCS pin).  The smoking gun was a control pin called LDRY – this can halt the CPU in the middle of a memory cycle.  This traced back to pin 21 of the GAL @ U11.  Again, I worked out the equations for this GAL and started to trace what controls pin 21.  The actual problem though was that this GAL had just failed and the outputs were garbage.  Replacing this GAL fixed the LDRY input and the CPU finally started to read from the ROMs!

Part 2

So despite the CPU seeming to be running the game was still stuck on a black screen and resetting every second or so.  The CPU was definitely running some code at least as video sync was now working (I assume the CPU sets up the video output).  I then spent a lot of time tracing all the data and address lines, and found no problems.  Eventually I decided to try and disable the watchdog after noticing the game in MAME takes a couple of seconds on a black screen before booting up and the pcb seemed to reset after only one second.

The watchdog/CPU reset is controlled by an IC called LTC690 at U83.  A logic probe didn’t show anything wrong with this – there were occasional writes to reset the watchdog, but probably not as many as there should have been.  The datasheet states the watchdog can be disabled (but the CPU reset functionality kept) by floating the watchdog input.  So without much to lose I just cut the trace (pin 6).  And the game worked!


I have no idea why the watchdog circuit has failed – but it’s arguably not needed as the watchdog is really just to protect against software faults and keep a machine running, so there’s nothing wrong with leaving this disabled for a ‘home’ pcb.


Part 3

On the home straight now – graphics and inputs fully working, but no sound.  Sound comes from the BSMT2000 custom chip – a logic probe showed it had a clock input but no activity on the data or address bus.  I was hoping the fault was that it was not receiving any data from the Z80 rather than having failed itself as I had no replacement.  The Z80 memory map is controlled by a GAL like the main CPU.  As before I dumped the equations from the MAME version which showed what outputs were in use.  With this info and the logic probe it was pretty clear to see the GAL inputs were working, but the outputs were all stuck.  I piggy-backed a replacement GAL and sound worked!  So indeed the fault was that the Z80 was unable to write data to the BSMT2000.


The bad GAL was desoldered and the replacement installed and the board was back to 100%.








Technos Wrestlefest arcade pcb repair

Two different boards with the same sorts of glitches – corrupt sprites, bad palettes and sometimes no video output at all.  Sometimes the corruption would change if you pressed on different chips on the board.

IMG_2650 IMG_2651 IMG_2678

Pressing on the board to make a difference is often a hint surface mount custom chips are not making good contact.  On both boards some pins of the TJ-003 custom were lifted and not making a solid connection.  On one board the TJ-002 custom also had some lifted pins.  The solder was reflowed and both boards back to 100%.






Taito Twin Cobra arcade pcb repair

A slightly unusual fault as this board stalled on the check screen, but reported everything ok.  If RAM, ROM and sound are ok then why doesn’t it work?  Without much to go on I fired up MAME to see what the CPU is actually doing at that point in the debugger.  The answer is the 68000 starts communication with the TMS32010 protection microcontroller.  Disabling the microcontroller in MAME made the emulation act like the physical board as the main CPU waits forever on the protection response.

IMG_4367  IMG_4372

On the real board the TMS32010 is hidden under the T.TC-4 sticker.  A logic probe showed it was getting a clock signal but most data and address pins were weak or dead.  The game booted perfectly using the T.TC-4 from another parts board, so that confirmed the microcontroller itself was dead.  Replacement is the only option as I don’t think blank versions of this part are available anymore.

IMG_4615 IMG_4618



Konami Jail Break arcade pcb repair

Essentially the same fault and repair as my earlier Green Beret fix which is almost the same board.  Corruption in sprites and the corruption was in ‘screen space’ as opposed to moving with the objects.

IMG_4458 IMG_4459

The 4 RAM chips in the top right of the board next to the square custom are used as line buffers for the sprites.  Replacing these fixed the sprites.



IMG_4528 IMG_4529


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.


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.


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