BryanMcPhail.com

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

By

Sega Super Monaco GP arcade pcb repair

Super Monaco GP!  Same board as Afterburner, one of the classic late 80′s sprite scaling boards.  Very complex hardware with 2 68000 CPU’s + Z80 for audio.  When powered up this board would flash the screen for a second and then sit dead on a black screen.  Logic probe showed the main 68000 was getting a clock signal but there was no activity on any data or address pin.  The probe also revealed the reset logic was working fine, and there was a burst of data activity for a second or less at boot up before it stopped.

IMG_7856

A stopped 68000 usually means there is a bus error or illegal instruction and the CPU has crashed, usually asserting the bus error hardware pin.  In this case the BERR pin didn’t show anything.  I suspected the software was actually issuing a STOP command and indeed when I fired up the MAME debugger I found all the exception handlers jumped to STOP routines.  So the theory was the program started to run, crashed, then the CPU was told to stop.  The most common reason for a crash would be bad RAM – because as soon as the program tries to return from a subroutine, a bad value would be returned by the RAM (most likely 0xffffffff) which would trigger a bus error for unaligned access.

Piggybacking known good RAM didn’t help so I decided to write a little diagnostic ROM that would print RAM values to screen.  The program itself is very careful not to use any RAM of course – so no subroutines, just logic instructions and static branches.  After trying the program out in MAME, I first needed to modify the board to run on 27c010 eproms – rather than the 27c1000 pinout eproms my programmer didn’t support.  Jumpers/resistors can be toggled to switch between the two different types (see Afterburner schematics for full details).  The program worked first time – which was great because it proved the main CPU was running as well as the palette and text layer hardware.

IMG_7864

Running the real hardware side by side against MAME showed a couple of bad bits in the 0×280000 range – which according to MAME memory map is actually the sub CPU RAM.  I used the logic probe to short pins on the RAM chips to identify what physical chip matched that address range and then piggybacked the known good RAM on top.  The values flickered and changed which is a good sign the RAM was bad (the flickering being the two RAM chips arguing over the correct value).  The RAM (TMM2063@IC31) was removed and replaced and the board worked 100% again.

IMG_7877

Diagnostic ROM and source is included below – note it’s a very quick hacky test!  Not something polished and easy to use.

IMG_7879

IMG_7878

IMG_7885

Diagnostic ROM and source – MakeSMGP- provided with no warranty

By

Capcom Last Duel arcade pcb repair

Game played but with lines through sprites and corrupt sprite colours.  Diagnosis was quick – it was clear a mask ROM was missing on the video board, and strangely it’s sister ROM was inserted with a pin outside the socket.

IMG_7982 IMG_7976

The board has pins for both a 23c2000 16 bit mask ROM or two 8 bit 27c301 ROMs, probably so the factory had flexibility to fit whatever type was cheaper during the production run.  But.. the 27c301 is a 32 pin IC, and the mask ROMs fitted are only 28 pin.

eprom_27301_pinout

This borrowed picture shows how it is possible – the top 4 pins are VPP (programming voltage), VCC (+5V), OE (output enable), PGM (enable programming).  The 28 pin mask rom doesn’t need the programming pins, and it omits OE in favour of just using CE (chip enable), so it always outputs when enabled.  The +5V line then just runs to the NC (not connected) spare pin on the 27c301.  So this way the board can use both the 28 pin or 32 pin ROM with no other modification.  In this case I used a fresh 27c301 and everything was fixed.

IMG_7988

IMG_7987  IMG_7991 IMG_7996

By

Konami Blades of Steel arcade pcb repair

Game played blind, with audio responding to input, but no video signal.

The custom digital to analog IC for video had obviously been changed in the past as a lot of solder flux was on the board.  (Same custom IC as Dark Adventure).  In the fact the problem was just a single pin had a bad connection – when resoldered video returned and the game was 100% again.

IMG_8002 IMG_8010 IMG_8019

IMG_8003

By

Konami Dark Adventure arcade pcb repair

A very frustrating time consuming repair…  The board was initially stone dead – no video output at all.  Logic probe revealed the reset on the 68000 CPU wasn’t working.  This was quickly traced to a Fujitsu LS07 chip near the edge connector – dead outputs.  Logic probe on the two Fujitsu LS32 chips next to it also showed dead inputs, so all were replaced.  At this point things slowed – 10% of the time the board wouldn’t boot, 70% it would show the ROM RAM TEST string and hang, 10% of the time that test would complete after a while, and 10% it would complete instantly.  When the test did complete it would show various bad ROM and RAM chips.  If the test completely instantly then everything showed bad, so clearly the test itself wasn’t working correctly.

IMG_7506 IMG_7504

MAME provides some insight into how the game works – there are two 68000 CPU’s – the master does a few tests, and prints the ROM test string, then it signals the sub CPU via an IRQ to do the bulk of the tests.  When the sub CPU completes it uses an IRQ to signal back to the main CPU which then shows the results screen.  I spent a lot of time examining all the components involved in the IRQ logic and the Fujitsu LS273 at 5U was found to be bad.  This IC is a latch that passes input to output on a clock signal – but the probe showed the inputs went to outputs regardless of the clock – so it was just spewing bad signals everywhere downstream.

The MAME debugger also shows the main program waits for the graphics hardware on the bottom board to signal it’s ready a couple of times before the self test happens.  This turned out to be a bad trace on the board somewhere – the CPU would just get a disconnecting floating signal.  This was the reason for the inconsistent booting – sometimes it would hang forever waiting, sometimes it would read as being ready before it really was.  With the bad trace patched the game would finally boot consistently and with no errors on the check screen!

IMG_7640 IMG_7641

But…  lack of sound now quite obvious.  There was no hiss from the speakers so I suspected the amp was bad but before looking at that I used the logic probe to try and see if the sound CPU program was running properly.  The main CPU sends sounds commands to the sound CPU and triggers an interrupt when the command is ready.  The sound CPU reads the command, acknowledges the interrupt and things continue.  So if things are working well placing the logic probe on the Z80 interrupt line you should see it pulse for every sound played (easy to see in the audio test).  But…  more inconsistency – often it would accept the first IRQ then hang/crash, leaving the IRQ line low so it was obvious it was never acknowledged.  Sometimes it could trigger 4 or 5 times before hanging.

So yet more time examining the IC’s related to sound IRQ, the sound RAM and I even swapped out the YM2151 audio chip which was obviously corroded and perhaps putting bad data onto the bus.  Eventually this turned out to another bad trace – sometimes a pin on the RAM chip would drop out which of course caused the CPU to crash returning from the interrupt (as the wrong value would be pulled from the stack).

The amp turned out to be good – the fault there was one of the power capacitors had physical damage and 12V was not getting to the amp.  With that replaced sound was working.

But..  now obvious inputs were faulty as player joystick left did not work.  Like most Konami games of this era inputs go through a custom IC then a LS253 multiplexor IC.  Because the output of these chips go onto a shared data bus you can’t tell bad outputs with a logic probe alone, but usually piggy-backing a good chip on top will identify the problem IC.  In this case the chip @ 2M controller player 1 left and when replaced the board was finally playing perfect again.

IMG_7631

IMG_7638

IMG_7630

IMG_7627

By

Technos Double Dragon 2 arcade pcb repair #2

I bought this board non-working and it arrived with the main RAM missing on the top board and two sprite RAM chips missing on the bottom.  I soldered in replacements and.. it worked 100%!  Nowadays this is a very valuable game for someone to scavenge for quite cheap RAM parts, so I assume it had been removed years if not decades ago.

IMG_7932 IMG_7934

 

 

 

By

Konami Aliens arcade pcb repair

This Aliens had bad colours on certain things in the game, even though most others were fine.  Often the cause of this kind of fault is a bad graphics ROM but in this case the game includes a full self-test of the mask ROMs (and palette RAM) and no errors were reported.

IMG_7494

IMG_7650

IMG_7488

If it’s assumed the custom graphics chips are ok, then the first place to start with this kind of fault is in the palette mixing circuit.  In the schematic picture you can see all the relevant parts with the final RGB output in the lower left, and the graphics data coming in at the upper right to the group of LS153 chips.  The palette RAM is the two 2128 chips also in the lower right – as the name suggests this contains the RGB ‘pens’ the indexed graphics will use.  We can probably assume is is ok because the self-test said so.  The two LS273 latches to the right ‘cut up’ the signal per pixel – we know they are ok because if they weren’t all graphics would be bad, not just some.

Untitled-10

The two LS245 latches above the palette RAM are used when the CPU updates the palette – again, any error here would show in the self test.  The job of the 3 LS157 chips is to arbitrate between the graphics hardware accessing the palette RAM and the CPU accessing the palette RAM.  A fault here could cause bad graphics as it means the palette lookup could be wrong.  The LS245 chips hold the bytes going from the CPU into the RAM (or the bytes going back to CPU when reading it).

The group of 4 LS153 chips multiplex all the incoming graphics data and essentially handle layer priority – that’s what makes a sprite show over a background and under a foreground.  A fault here could also cause bad graphics – potentially sprites using the palette of the background, or background using the foreground palette and so on.

The two LS174 chips buffer the multiplexed output – any error here would likely show as all graphics being bad, not just some.

So, really the problem is likely be in just 1 of 7 chips, the LS153′s and the LS157′s, which can be examined with a logic probe (checking for stuck outputs or shorting outputs and seeing what happens on screen).  In this case the very first chip I tried (Fujitsu LS153 at G12) was bad.  It was replaced and all graphics perfect again.

IMG_7804 IMG_7803

IMG_7496

IMG_7811

IMG_7812

IMG_7818

IMG_7805

IMG_7814

 

 

By

SNK Ikari Warriors arcade pcb repair

This Ikari Warriors was mostly fine, but had some specific bad graphics – the bullet on the title screen, the plane in the intro, grenades and power ups all displayed with a corrupt line effect.  Ikari has two sets of sprite generators – one for the players, enemies, tanks and one for the all the elements mentioned above, so it’s clear the fault was localised to the second sprite generator circuit only.  The middle board contains the 2 pairs of line buffer RAM, and shorting pins with a logic probe confirmed the top two chips were for the players, and the problem sprites were associated with the bottom two.  As it’s clear the graphics fault was on every second scanline, this was likely a problem in the line buffer setup (1 chip handles odd scanlines, 1 handles even.  If the glitch affected all lines then the problem is likely prior to the line buffer split).

IMG_7737 IMG_7732

After probing the chips feeding the RAM and finding no problems I assumed it was just a failed RAM chip.  So I removed both, but they tested fine off board and replacement RAM acted the same way on board – fault still present.  What’s more running the board with one of the RAMs removed showed the game logo also used the second sprite generator, but that wasn’t corrupt – so it seemed only some of the sprites were being corrupted, not all.  The sprite ROMs all tested good as well.  With no obvious dead chip this just got a lot harder to fix.

IMG_7743

Ikari does have a self-test mode – which reported no errors – and a debug sprite display mode – however it only displays sprites for that first sprite generator – the one with the players and enemies.  That is called ‘Front 2′ on the test and the schematics.  I modified the program to make it display ‘Front 1′ – the ROM is attached below.  This threw up an interesting fact – the corruption only happened on sprites using palettes 2, 6, 10, 13, 15 – so anything where bit 2 was set in the palette showed the error.  Very strange but I could verify this by always pulling bit 2 low on the LS245 chips that control the palette – bit 2 low graphics fine, bit 2 high – every other scanline showed an error.

IMG_7760

 

Referring to the schematics shows this is probably 1 of 4 chips.  The two LS374′s, or the two LS298′s.  The job of the LS374 is to pass data into the line buffer RAM pair as the line is built.  The job of the LS298 is to pass data out of the RAM and send it to the priority circuit on the top board.  The data going into the LS374′s must be good (because if it wasn’t the problem would show on every scanline, not just every second), and the circuit past the LS298′s must be good for the same reason.

schems

So, I desoldered the LS374′s and tested them – and a single bit error came up – on the pin that handles the palette bit 2!  Replaced and everything is fine, but what a really strange specific error.  Usually when chips fail all outputs go bad.

IMG_7771

IMG_7796 IMG_7786

Diagnostic ROM – up03_l4.front_1_diagnostic

 

 

 

 

By

Taito Chase HQ arcade pcb repair #3

I was sent this untested pcb and when I wired it up found there was no video output on RGB – very strange as sync was present, so this caused me to check and re-check my wiring a few times.  When examining the pcb closer it was clear the TC0070RGB custom had been removed, presumably to fix a different game.  I had a spare one so I soldered it in and everything was back to working.

IMG_7530

See here www.jammarcade.net/taito-tc0070rgb-reproduction/ if you need this part.

 

By

Nintendo Mario Bros arcade pcb repair #4 / Ghetto Fluke

Another Mario Bros – again booting to a screen of garbage tiles. I attached the video (bottom) board to a known good CPU (top) board and apart from a glitch fixed by reseating the ROMs the video output was fine. So any problems were on the top board.

There were a bunch of obviously corroded Fujitsu IC’s that a logic probe showed had dead outputs, but even when replaced the game didn’t boot. Piggy-backing known good RAM chips didn’t help either. Rather than start shotgun replacing parts I decided to try out an idea I’ve had a for couple of years – use an Arduino or Raspberry Pi style device to replace the CPU and probe the board for faults that way. The idea is that the Arduino device will connect to the data and address bus as well as the read/write pins so that you can manually run tests that may show up faults. For example, reading ROMs, testing main RAM, writing to graphics RAM or sound latches.

My idea isn’t unique – I know Paul Swan has made a similar device – http://www.paulswan.me/arcade/ArduinoMegaICT.htm as well as a chap called Artemio who has helpfully placed code for a Z80 setup on Github – https://github.com/ArtemioUrbina/GhettoFluke9010A

The Mega Arduino was wired up – GND, 16 address lines, 8 data, various read/write/bus ready control lines, etc, plus 12V from game PSU powering the Arduino itself. I added a test to read each of the ROM chips and print the CRC’s. After some debugging of my setup all the ROM chips came back with the same CRC’s as MAME – great news, so for sure the CPU can read the program properly. I wrote a test that writes to and reads back the two RAM chips – this returned garbage values. The useful thing about this setup is that I can ‘pause’ the current state at any time and examine chips with a logic probe. So with all activity frozen it was easy to see the chip select line on the RAM was not being enabled when it should be. With the schematics this was traced back to a LS138 chip that had dead outputs.

With that replaced I wrote an incrementing numeric sequence to RAM – but the sequence read back with duplicated sections – so the RAM address decoder had surely failed internally and bytes written were going to the ‘wrong’ place. (As an aside this explains why piggybacking a known good RAM didn’t work – the RAM outputs were working fine – just address conflicts internally).

With the RAM replaced the game booted and worked fine albeit with most sounds missing!

I used the Arduino again to trigger all sound ports one by one and checked with the logic probe and schematics that all the right pins pulsed at the right time on the audio CPU. In fact the audio CPU itself was dead as confirmed when a known good one was placed on the board. The audio program eprom was also bad (returned 0xff for every byte), so a replacement was burned.

Another Mario saved.

[It seems the pictures for this post were lost - here is a picture of the Arduino attached to a Bubble Bobble bootleg for an upcoming repair].

IMG_7411

By

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

IMG_6699

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.

IMG_6708

IMG_6727

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.

IMG_6735

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.

IMG_6738

IMG_6739