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.
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.
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.
Diagnostic ROM and source is included below – note it’s a very quick hacky test! Not something polished and easy to use.
Diagnostic ROM and source – MakeSMGP- provided with no warranty
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.
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.
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.
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.
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.
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!
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.
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.