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

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>