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


Konami Track & Field arcade pcb repair #2

Game booted to a solid purple screen with no sounds so it seemed the game was not running as well as likely graphics problems (with graphics working and dead CPU the game should show character tiles garbage).


Usual checks with a logic probe didn’t show anything obviously wrong – CPU lines were pulsing away as were ROM and RAM. I started by trying to debug the character display part of the board to see why no tiles were displaying. Again, nothing seemed wrong here – graphics ROMs were pulsing away – both data and address lines – so data was coming out but where was it going?

I traced back to a LS157 chip – this is a multiplexor that selects between 2 four-bit sources. One source is the tiles, one is the sprites – so this is really what handles the priority between sprites & tiles in the game. When I used the logic probe to short some of the pins on this chip – tiles appeared! In fact they were proper game tiles so the CPU program was clearly running. The main fault on the board was now clear – the sprite output was jammed on for every pixel – so the priority selection always chose the sprites which gave the solid purple screen – the tiles and CPU program were actually running fine underneath the solid output.



So I traced the LS157 sprite input back looking for dead chips – in fact I traced back about 10 linked chips without finding anything before giving up and starting again at the other side of the chain – the sprite RAM. On that address lines were pulsing but data pins were not – so nothing was being written into the RAM. Traced back to a Fujitsu LS244 latch.. dead :( Replaced that and graphics worked!

Weirdly though – the game was running at least double speed. This game, like many, regulates speed through periodic vertical blank interrupts – 60 a second give or take. The logic probe showed the IRQ pin on the CPU was stuck low – this traced back to another Fujitsu LS244 – dead. When replaced game speed was correct.


However, still no sounds – I spent quite some time debugging the sound (top) board but nothing seemed wrong – the IRQ pin on the sound CPU pulsed whenever a sound was requested by the main CPU. Eventually I went back to the main board looking for where the main CPU writes the sound command data to the audio board – a Fujitsu LS245 with dead outputs.

With all that done a new battery was installed and high scores cleared to fix the bad score graphics and the game good to go.




Technos Double Dragon 2 arcade repair log #2

Owner of this board reported it would crash going into attract mode or when you inserted a coin. However when first wired up I couldn’t get past a screen full of garbage tiles. Logic probe didn’t show any problems, but piggy backing known good RAM onto the 6264 main RAM chip @ IC20 made the game boot to the title screen. However it did indeed still crash on coin up or attract mode giving a static corrupt screen.


IMG_6821 IMG_6832

As the CPU was obviously running to get that far and nothing seemed wrong this was a head-scratcher for a while… I used MAME to try some things out – when I disabled the second CPU in the emulation I could mimic the board problems exactly. (DD2 is a 3 CPU game – master CPU, sub CPU and audio CPU). It turned out the sub CPU RAM @ IC24 was bad as well – when replaced the game ran and played fine but sound effects were very quiet and music very loud.


There’s not much to the sound section on this board – music comes from the YM2151 synth chip through a DAC, and sound effects come the Oki sampler player. Both go through some pre-amp stages before being combined and hitting the main amplifier. To debug things I used the trick of connecting some powered speakers to each of the preamp input pins. The two MB3615 preamps have four channels each – but it’s not split between music and sfx – for whatever reason the music uses 6 preamp stages, but SFX only two. Listening to the individual channels through the speakers confirmed the SFX were clear and correct but the music was distorted and corrupt at every stage. So I replaced the DAC – but no change, replaced the capacitors used – no change, then eventually the preamps themselves with replacements from a Wrestlefest board. The preamp at IC87 was indeed bad – sound & music were now perfect.



But this became the repair from hell as now sprites were corrupt. Very weird as all the other work I done was on the top board and this was a new fault on the bottom board that I had barely touched.

IMG_6893 IMG_6935

Every 16 pixels or so across the screen there were corrupt lines – but only on alternate scanlines. Like many other games Double Dragon 2 uses a double scanline buffer system where sprites are written to a pair of RAM chips which alternate every line (one is written to by the video system, as one is read out to the screen). Because the fault was consistently every 16 pixels I suspected a horizontal counter had gone wrong somewhere. But because it only affected one of the scanline buffers it had to be after the chunk of logic that decodes the sprite list and reads the ROM data.

The Double Dragon schematics show the scanline buffer area – there are really two copies of this circuit on the board. A bunch of LS163 counter chips are used to count the horizontal pixels – these go through a further buffer before going to the line buffer RAM chip.  If I used a logic probe to short out the LS163 timing chips in one area then I could get a perfect sprite display on even scanlines, if shorted out in the other I get a garbage display on odd scanlines.


However, having narrowed the fault down this far there wasn’t much progress – logic probe showed everything working ok, digital oscilloscope didn’t show any ‘noisy lines’, shorting pins together didn’t reveal any clues and piggy backing known good IC’s for every chip in this page made no difference.

After many hours I had to resort to using a heat gun to remove all the IC’s in this area to test them off the board – and… bad RAM :( Not bad enough that it was fully dead, just bad enough that one of the address input pins clearly wasn’t working properly and data was being randomly diverted to weird addresses every 16 pixels or so.

New 6116 RAM installed and finally the game perfect again.

IMG_6953 IMG_6956


Technos Double Dragon arcade pcb repair #2

The game would boot up with no errors on the self test, but then reset when you inserted a coin or shortly into the attract mode.

A couple of the main CPU program eproms initially gave slightly inconsistent results when read in an external programmer (different CRC’s each read) though when I tried again the next day they were 100% consistent. What was soon clear though was that using program eproms from a known working board made this board 100% reliable so new ones were burned and installed and everything fixed.

Quite an unusual fault to see original eproms from that era fail like this but they were definitely the problem.



Midway Space Invaders arcade pcb

Can’t call this one a repair as such as a non-booting original Space Invaders was made to boot just by reseating the CPU. Although this is a classic black and white game, you can make it run with a regular switching PSU that supplies +5V,-5V and 12V and a monitor capable of composite video input (as opposed to regular arcade RGB + sync).  Notice the unusual ‘L shaped’ design with the sound board at a right angle to the main board.

IMG_7136 IMG_7143 IMG_7312


Nintendo Mario Bros arcade pcb repair #3

Very strange fault on this board – two misplaced tiles on the title screen – but absolutely no fault anywhere else.



That kind of fault is very strange as usually a fault with video hardware like this would affect all sprites, or at least groups of related sprites.  Indeed when the CPU board was matched with a known working video board the fault remained – so it was on the CPU board rather than in graphics generation.  As the program EPROMs verified correct the main suspect would be the Z80-DMA chip which copies data from memory to the video board – however I found the fault with some luck by swapping the two main CPU RAM chips.  The fault went away with different RAM, and came back with the original RAM replaced.


New RAM installed to properly fix the problem but still a very strange fault – usually when RAM fails an entire an address row or the data bus is taken out – which usually means the CPU program will fail quickly.  This RAM must just have a handful of bad bits that happened to correspond to work area for the title screen.



Taito Sky Shark arcade pcb repair

No video output from this Sky Shark, aka Flying Shark but the main CPU and RAM did show activity via logic probe.  There are no schematics available so I traced out where the RGB lines on the jamma edge connector go.


And they go to the resistor network at the right side of the board, so the digital palette is converted to analog video signal as expected.  The resistor network is fed by the two LS273 latches in the N row and I presume those two latches are clocked by the pixel clock to output each pixel as supplied by the palette RAM.  No clock was present though – so I traced the clock signal back to the LS08 on the M row.  This seems to be how the game handles the horizontal and vertical blanking – so the pixel output is turned off when needed.

The MAME source indicates the CPU can also turn the screen on & off – and it’s this signal that also goes to the LS08 – by (temporarily) bridging the input pins I forced the screen on – and got a screen full of garbage!


So that’s actually a good thing – confirmation the pixel clock is working, palette RAM works, tilemap RAM works, etc, and likely confirmation the CPU program was not running long enough to turn on the screen.

Piggybacking the main CPU RAM with known good RAM had no effect, and the program ROM’s seemed fine, so I used the MAME debugger to trace the program a bit – and it seems the program is very delicate – any RAM or DSP error leads to a crash rather than any on-screen indication (so although the game reports ROM:  GOOD  RAM:  GOOD on successful bootup – it will generally never report something bad – just crash!).


Now after all that, I examined the board in more detail and found 3 gouged traces on the underside – when repaired the game worked 100%.  So I went down the wrong path for a while but fixed in the end.






Nintendo Mario Bros arcade pcb repair #2

Two pcbs with a fair amount of corrosion on the chips, probably stored in a humid warehouse for decades.


Board 1

Showed quickly scrolling lines, so clearly video sync wasn’t correct.  Sync mainly comes from two LS123 chips – a logic probe showed one of them was getting an input but had a stuck output.  A corroded Fujitsu chip.  Piggybacked a replacement on top and video worked – screen of garbage characters!




So random garbage on each boot generally means the CPU isn’t running (consistent garbage usually means it is).  Logic probe showed the main Z80 cpu had pulsing address lines and reset was working ok, but all data lines were stuck low.  The program eproms, which tested good off board, also had pulsing address lines and pulsing output enable lines.  So that means something is telling the eprom to output data – but if it is then why are all the data lines low?  Something on the data bus had to be grounding all the lines and stopping activity.  There’s not much on the data bus – the CPU itself, the Z80-DMA chip, the RAM, the ROM and a LS245 latch that isolates the video board data bus.

The LS245 was removed and tested good, the Z80-DMA was removed and suddenly the data bus was active.  With a replacement fitted all data and address lines were now pulsing – but still random garbage characters on screen.  So the Z80-DMA had failed in a way that pulled all lines low.


The LS245 was next the clue – this latch allows reading and writing from the video board – but the direction pin appeared to be stuck low.  The schematics show this line is buffered by a driver chip – in this case a Fujitsu at 6A which had failed.  When replaced the game worked albeit without sound!



Board 2

No garbage display on this one – instead some consistent moving long blue lines across the screen.  So that’s a hint the CPU is probably doing something and the initial problems are on the video board.


Because of the ‘stretched’ look to the lines I examined the horizontal and vertical timing part of the circuit first.  In the schematics things like 4H refer to every 4 horizontal pixel, and V to the vertical line.  In the picture you can see some references to the low 3 bits of V and H.  3 bits gives you a value 0-7 – and this game has 8 pixel wide tiles, so you can see those parts are dealing with the pixels inside a tile.


The video board came together bit by bit – the lines became solid tiles, then the inside of tiles, then sprites.  Faults were all Fujitsu chips, or just badly corroded chips.


At this point it was pretty clear the CPU board was fine and sound worked on it so the working video board 1 was combined with CPU board 2 to make a fully working game.  1 worker from 2 corroded trashed boards is a good result.


But I’ll get back to fixing CPU board 1 and video board 2 at a later date – the video board only has 1 fault left – sprites are sometimes duplicated vertically – I suspect some kind of vertical comparison fault somewhere, but not found it yet.  The lack of sound on the CPU board I suspect the audio CPU itself has failed.







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.



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.


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).




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





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.


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%.






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.


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%.