BryanMcPhail.com

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

By

Sega My Hero arcade pcb repair

Clean original board, but booted up with no backgrounds present.  What I presumed to be tilemap RAM was pulsing ok with a logic probe check.  All tilemap ROMs were pulsing ok as well as was the palette RAM.  Piggy backing other RAM on top made no change – so my first theory was that the tilemap circuits were fine and it was a priority circuit problem (like an earlier Pacland repair).  So with that kind of problem the sprites are considered ‘opaque’ and nothing underneath them comes through.

IMG_5729

IMG_5738

There are no schematics for this game, but the hardware is kind of similar to Choplifter which does have schematics available.  The ‘opaque’ test works by just summing the 3 bitplanes for each of sprites and the text layer – all low means it is transparent, any other value means it is ‘opaque’.  The priority PROM enforces that opaque text is always over sprites and tiles, and that opaque sprites are always over tiles.  On My Hero an LS27 at IC37 handles the opaque check.

IMG_5731

Unfortunately this didn’t seem to be the problem – the priority check seemed correct, and shorting pins on the PROM didn’t bring any backgrounds back either.  So I ended up testing each pin on every chip in the tilemap section to see if anything looked wrong.  Eventually I found a latch (IC29) with a lot of activity on the inputs but always zero output.  The chip itself was fine, the problem was it had no clock input – if I shorted pins to manually clock it, the whole background colour changed – so definitely related to tilemaps.  The missing clock traced back to a bad Fujitsu LS86 with dead outputs – when replaced tilemaps fired up.  (The latch at IC39 controls the text layer and works from a different clock).

IMG_5796

IMG_5798

IMG_5853

But…  bad colours on some but not all tiles and flashing dots in places.  This was a headscratcher for quite a while – the ROMs all tested good, the checksums matched, palette RAM was good and no obvious dead or floating lines.  Eventually I realised the problem was that 3 of the 6 tilemap ROMs were not original – these replacements had slower access times than the 3 originals left on the board.  Although they read fine on the PC reader at slow speed, at the tilemap circuit speed they tended to return bad data or no data causing the bad colours.  When replaced with faster access EPROMs, everything was fixed.

IMG_5843 IMG_5869

IMG_5873

 

 

By

Nintendo Mario Bros arcade pcb repair #1

Board appeared to play blind – sounds were produced, but no video.  Logic probe quickly revealed there was no video sync signal coming from the video board.

The sync signal is mostly produced by a couple of LS123 chips – there was no output from them – but also no input to them either.  I followed the path upstream until getting to the clock circuit, so much like the Popeye repair the video clock circuit didn’t seem to be active.

mario2

In this case the crystal oscillator and LS04 tested fine – the problem chip was the upstream S74 which had failed.  When replaced the board was 100%.

IMG_6180

IMG_6179

IMG_6183

 

By

Nintendo Popeye arcade pcb repair

Game did not boot, and seemingly no logic activity anywhere on the board.  The clock circuit is the first place to start for this kind of thing.  It mostly consists of a crystal oscillator, a few resistors/capacitors and a 74S04 in a kind of feedback loop.

popeye

I removed the S04 chip from the board but it tested ok – the actual problem was the crystal oscillator itself had failed.  20.160MHz is kind of an unusual value for arcade games, but a replacement was found and fitted and everything worked 100%.

IMG_6169

IMG_6171

IMG_6173

 

By

Konami Track & Field arcade pcb repair

Booted up to a screen full of 0′s.  That meant the CPU was partially running as it was clearing the text layer to consistent 0 instead of leaving it as random garbage.  The program ROMs were tested on PC and 2 of the 5 gave inconsistent reads.  2 replacement eproms were burned and game started up!

IMG_5781

There was a further graphics problem – corrupt text on the hi-score names in game.  At first I thought this might be a problem with the graphics ROMs and indeed 1 gave inconsistent reads, but replacing this didn’t fix the problem.  Some Googling revealed this is a common problem when the battery on the board dies – it seems the game then reads garbage data from the save memory and doesn’t do any validity checking on it – so it just copies garbage chars to the screen.  A fresh battery was installed and the save memory reset via the dip switches.

IMG_5784

IMG_5783

 

By

Taito Legend Of Kage arcade pcb repair

Much like the earlier Tiger Road repair every other line missing in the sprites suggests a double buffered sprite line buffer system, and that one of the buffers have failed.  Handily the sprite ROMs were in sockets already on this board, so I removed them one at a time and booted the board – removing all except IC21 caused additional visual faults, so good chance this was the culprit.

IMG_5721

Replacement RAM was fitted and board was 100%.

IMG_5760 IMG_5761

IMG_5743

 

By

TAD Cabal arcade pcb repair

Like the Legend of Kage and Tiger Road repairs all sprites had every other scanline missing suggesting a failure in double buffered sprite line RAM.

IMG_6143

The entire top board is for sprite processing and contains 12 ram chips (the tilemap, palette and main RAM is all on the bottom board).  The bad chip was found by piggy backing a known good RAM chip on top of each RAM until the problem went away.

IMG_6157 IMG_6158

Trackball to joystick mod was also built and installed thanks to the work at http://elgensrepairs.blogspot.co.uk/search/label/TAD

IMG_6201

 

By

Konami X-Men arcade pcb repair

This pcb was a mess of previous repairs and missing parts – two crystal oscillators missing, program ROMs missing, audio mask ROM missing, various TTL and RAM chips replaced.  So clearly many problems in the past and someone likely tried to repair it, failed and then harvested parts to fix other boards.

I pulled some crystals from a parts board (Konami Run and Gun) and burned some fresh program ROMs from the MAME set.  Game booted to a solid yellow screen.  Like the Vendetta repair I suspected palette RAM and when new RAM was piggybacked on top the usual Konami check screen came up with a bunch of errors.

IMG_5344

Eeprom @ 13B error

13B is the eeprom used for storing game configuration data – when I tested this with a logic probe there was no data output – but actually there was no +5V to it either…  it seems this was a victim of a previous repair attempt – it had been removed and replaced, but had a bad solder joint on the +5V line.  With that corrected the game still reported an error – and this time the data pins were active.  Schematics are available for this part of the board and there was no continuity between the two outputs of the eeprom and where they should go – trace damage from the previous repair attempt.  Patch wires soldered on the bottom of the board – and success!  The screen was no now longer upside either as the game stored the flip screen configuration data correctly.

The remaining errors all related to the audio section of the board.  Like Vendetta I decided to patch the program to skip errors and see what happened.

IMG_5452

IMG_5453

Broken Colour Output Custom

Well, the game ran surprisingly well!  All graphics and inputs were working, just no sound, and clearly no blue colour in any graphics.  There are schematics for the video output, which consists of two LS273 latches and a bunch of LS07′s.  Logic probe seemed to show this was all working correctly, so the problem was likely the custom 052535 IC – a replacement was taken from a Run n Gun and the blue channel restored.

IMG_5500

IMG_5497

Audio errors

Errors 6F, 7G, 4E, 2D are all in the audio section of the board – program ROM, two RAM chips and the missing mask ROM.  Piggybacking RAM had no effect, and the program ROM was freshly burned from MAME so it should have been correct.  Further probing revealed the Z80 CPU was not even running – no activity on data or address lines – so it makes sense the main CPU reported all the audio parts bad.

Before declaring the Z80 dead I checked the control lines – and the WAIT line was being held – so something was actually forcing the Z80 not to run. No schematics are available for this section so I traced the WAIT line to the output of a LS08 chip  – that’s just an AND gate – and eventually traced the input to the gate from the custom audio chip.  So some info not in MAME is that the audio chip actively controls the Z80 wait, probably when accessing shared memory.

I temporarily removed the LS08 so the Z80 could run and there was activity on the data and address lines so the CPU itself was probably good.  At this point I stalled for quite a while with no ideas.  After finding the bad Konami PAL on the Vendetta repair though I checked the X-Men audio PAL and it was completely failed.  When replaced some synth sounds could be heard during the game!  The WAIT problem turned out to be the custom chip was not getting a clock signal – the Run N Gun dual frequency crystal was bad – so one was taken from a working game (Premiere Soccer) and the LS08 replaced – this finally cleared up all the audio errors in the self check.

Sample ROM

Final problem was the missing sample ROM – a 2 megabyte 27c160 eprom can be used here as replacement.  Lots of traces on the board had been damaged but all address/data lines are shared with the custom audio chip so a logic probe in the socket will show if any lines are disconnected.

IMG_5665

Unusual to see a board with so many unrelated problems, but fixed 100% at last.

IMG_5504

IMG_5503  IMG_5515

IMG_5660

 

 

By

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!

IMG_5265

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.

IMG_5269

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.

IMG_5468

IMG_5614

 

The MAME source code had some interesting info:

PORT_BIT(  0×0004, IP_ACTIVE_LOW, IPT_JOYSTICK_UP    ) PORT_PLAYER(player) \
PORT_BIT(  0×0008, IP_ACTIVE_LOW, IPT_JOYSTICK_DOWN  ) PORT_PLAYER(player) \

PORT_START(“EEPROM”)
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_SERVICE_NO_TOGGLE(0×04, IP_ACTIVE_LOW)
PORT_BIT( 0×08, IP_ACTIVE_HIGH, IPT_CUSTOM ) PORT_VBLANK(“screen”) /* not really vblank, object related. Its timed, otherwise sprites flicker */
PORT_BIT( 0xf0, IP_ACTIVE_LOW, IPT_UNUSED )

 

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.

v

 

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.

IMG_5621

IMG_5613

IMG_5616

 

By

Konami TMNT arcade pcb repair

Board #1

IMG_5275

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

IMG_5291

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.

IMG_5311

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.

IMG_5306

 

 

 

By

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!

IMG_5403

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.

dd