Super HangOn PCB Fix Log

I purchased up the internals of a Super Hang On shell a few months ago. The package included an untested PCB that, judging from the photos he sent, had suffered a tough life. On arrival, the PCB booted and ran which was a great start, but no road was visible.

On inspecting the underside of the PCB, it was a real dog's dinner with repairs all over the place. It looked like someone had gone wild gunshotting parts of the circuitry to fix a previous problem. There were jumper wires connecting parts of the PCB where traces had been damaged. At this point I wrote to Mark at Retroclinic who kindly provided details of the work he'd done on the board, so I can distinguish his work from the chaos that had also occurred.

The top PCB is responsible for road rendering and is identical to the OutRun PCB, including the PALs. Super Hang On is similar to OutRun but with inferior sprite hardware, which is why the scenery is rather sparse in comparison from a gameplay point of view.

I quickly ported the OutRun test ROM to the Super Hang On hardware. This involved changing a number of memory addresses as well as the memory mapper configuration code. This proved that both the Sub CPU and Road RAM was fine. (For those waiting on the OutRun test ROM, it's now with Alex who will be releasing it in due course.)  ignore the sprite hardware failure below, I didn't adapt the code to handle SHO's sprite hardware correctly.

I could now focus on a smaller section of the schematics. I verified the Road ROM which was good. I swapped the PALs responsible for the road mixing and road bit extraction with a known good OutRun PCB to eliminate them from the equation.

Using my logic probe, I noticed that the Output Enable pin of the Road ROM was stuck high, essentially meaning the ROM data was not being used. Using the schematics, I traced the problem back to an LS174 @ IC14 (quad d flip flop). On closer inspection there was some signs of corrosion around its legs.

Piggybacking this chip restored the road circuitry. I mistankenly swapped out an IC downstream beforehand. If I'd used my scope and not been lazy, I would have avoided this.

Shortly after fixing the problem, another issue arose whereby there was a further visual glitch with the road hardware. Notice the colour band in the sky and the blurry road below. I swapped the test ROMs back in and they reported a failure with the Road RAM (or more likely the logic chips connecting them to the CPU). In game it looked like a visual glitch when the hardware performs the Road RAM swap.

However, the problem then vanished! And no amount of pressing on chips, flexing the PCB or power cycles could replicate it. I imagine it could return in the future if a chip is on the verge of failing somewhere, but hard to fix a problem you can no longer reproduce. If anyone has any thoughts on this then let me know.

Turbo OutRun PCB Fix Log

Purchased this OutRun boardset from the states. It was sold as faulty. The seller included some free food, which kept me happy whilst I stared at the black screen it presented me with on boot.

First thing I did was to verify an EPROM with RomIdent. This showed this was actually an OutRun boardset converted to Turbo OutRun.

I then tested the 2 boards against a known good set, and found the lower video PCB to completely working. Fantastic! This saved me building the interconnects that ColinD kindly sent me this time round.

I swapped the security FD1094 processor with a vanilla 68000. I programmed some decrypted ROMs.

I was greeted with the following screen.

Progress, but this was a bit of a red herring. It crashed immediately after this screen. In fact, this screen was an addition of the Japanese decrypted roms I'd happened to use. It's possible that the security processor was still working, but I'll go back and check that later.

I dug out the schematics and found an LS244 with dead outputs @ IC83. This was part of the sub CPU memory addressing. I socketed it and swapped it out, but it didn't make the game boot, although the logic probe showed its pins were doing something at least.

At this point I decided I wasn't going to change any more components without better diagnostic information. I'm slow at desoldering, so shotgunning stuff wasn't a good idea.

I used the OutRun SDK, created by Alex, to code a test tool for OutRun. Alex had already started work on the tool and I made some further modifications. My theory was that I needed a minimal piece of software to test as much of the hardware as possible. The problem with the on-board tests on OutRun, is that they require most of the PCB to already be working in order to use them. So they are mostly useless.

I spent a couple of nights changing the tool so that it would test the 4 Main CPU SRAMS, the 4 Sub CPU SRAMs, Tile RAM, Text RAM, Palette RAM and Sprite RAM.

The tests that Alex had included were far more rigorous than OutRun's onboard tests, with separate address bus and data bus tests.

Screenshot from MAME below, excuse the horrible palette (it's really setup for OutRun not Turbo OutRun)

I programmed this to the boardset and got the following:

The program reported the Sub CPU RAM @ IC 73 was bad.

I also verified that the ICs reported by the program were correct by glitching some of the SRAMs whilst it ran.

After hours of swearing and desoldering (mostly due to the ground plane) I'd removed the offending SRAM and socketed the IC.

Personally, I find these boards an arse to work with. I have a lot of respect for Mark at Retroclinic now.

At this point, the test gave me a different error because the SRAM was completely missing. Promising!

Inserted a replacement SRAM and BOOM - all OK!

Change the EPROMs back to the game and we have attract mode with sound: