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