Monday, June 12, 2017

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:

Friday, April 14, 2017

AfterBurner 2: Enhanced Edition

AFTERBURNER celebrates its 30th anniversary this year, so it seemed fitting to produce an ‘Enhanced Edition’ to offer the definite experience to fans of the original.

AfterBurner 2: Enhanced Edition (AEE) is a set of 3 replacement EPROMs intended for use on the original arcade hardware. It is a plug and play solution and no hardware modifications are required.


  • Stage SelectStart the game from any stage
  • New Music Tracks: 2 new music tracks from Hiro himself
  • High Score Saving: The high score table is retained even when the game is powered off
  • Working Freeplay Mode
  • Attract Mode Sound Options
  • Software Dip Settings: Change all settings in software


This is free to owners of the original arcade cabinet. If you would like a copy, send me a selfie of you and your AfterBurner machine (!) on the UKVAC forum where my username is dj_yt 

Full documentation here

Tuesday, March 14, 2017

OutRun Influences: Hiroshi Nagai & Naoya Matsuoka

It's well known that OutRun was partially inspired by the film, The Cannonball Run and a European roadtrip. Yu Suzuki has referenced it in many interviews; the film is even mentioned in the game's original design documentation.

However, some other OutRun influences are less well known but equally important. First is the Japanese artist Hiroshi Nagai. His work extensively features roads running adjacent to shining blue sea, bright foliage, palm trees and the colour palette OutRun fans will recognise.

Now we know why OutRun features so many pink flowers!

Interestingly, Nagai provides the cover art for a 1982 Japanese album, entitled September Wind, composed by Naoya Matsuoka & Wesing. OutRun composer, Hiroshi Kawaguchi references Matsuoka's work as a direct inspiration for OutRun's score claiming that without it OutRun wouldn't have been born. 

The album itself features the sound of waves breaking between the tracks, reminiscent of OutRun's music selection screen. Some of the OutRun melodies are influenced by tracks on the album. For example, Passing Breeze, definitely bears some similarities to A Season of Love. Overall, it's the perfect listening material for any OutRun fan! 

Wednesday, January 25, 2017

Out Run: Early Cabinet Screenshot

Here's an early photo of an OutRun Deluxe cabinet. [source]

If you look closely at the screen, you will spot that there are a number of differences from the released version. This must be running an early prototype version of the game.
  • Timer is using the font from Space Harrier. This font is in the OutRun ROMs but not used anywhere. Now we know it was used in an earlier prototype version.
  • Sign art is different in a number of places from release.
  • Debug information above speed on left hand side.
  • No rev counter
  • kp/h graphic is different
  • No route map

This Space Harrier also has some differences from the released version:
  • A step built into the base at the front which was later removed.
  • The side art is different; the underbelly of the dragon and his hair are orange on this version and yellow on the final art.
  • Different instructions & warning stickers, 
  • Sega logo size on the rear panel and title screen

Sunday, July 17, 2016

Out Run: The Arcade Software Development Kit

OutRun turns 30 this year, and what better way to celebrate its legacy than with the release of Alex Bartholomeus' OutRun Software Development Kit (SDK).

The SDK allows you to compile C and C++ code to target the original OutRun hardware. The package includes:

  • A fully working GCC C cross compiler
  • A mostly working GCC C++ cross compiler (with a large memory footprint)
  • Shared library code including input handling, palette setup, tilemap rendering, sprites, text display and even menu functionality.
  • Example programs
  • An optional bootloader. If you don't want to program EPROMs each time, you can build a nifty interface to send your code directly to the original hardware. 

Here are some example programs that Alex has coded to demonstrate what you can easily achieve. The source code to these programs is included in the package.

There are plenty of cool uses for this SDK. On a basic level it could be used for the creation of test programs to debug and fix original boardsets. Alternatively, you could even use it to create an entirely new game! Whilst you'd lose some performance and memory by coding in C or C++ as opposed to pure 68k assembler, you'd gain the ability to swiftly create and debug code and port existing software.

Download the SDK from Alex's page here

Monday, February 22, 2016

Sega Golden Axe Bootleg Fix Log

I pulled a Golden Axe Bootleg PCB out of storage. I hadn't fired it up for 20 years or so.

Unfortunately, it didn't work. The screen was too dark, apart from when the game was performing its windowing effect, where it suddenly displayed at perfect brightness. Sometimes the screen would completely lose sync and go black.

Initially, I didn't hold out much hope. Whilst there are few customs on this boardset compared with the official Sega PCB, there are hundreds of ICs and no schematics.


Bottom PCB

I started by inspecting the board. There was a Fujitsu IC on the top board that was running hotter than the surface of the sun. As Fujitsus have a bad rep, I swapped it out. The new IC ran cooler, but the windowing problem persisted.

I moved around the board shorting pins with my logic probe in an attempt to figure out what area of the board was responsible for the rendering issue.

I struck gold and found an IC with a damaged leg. It was my lucky day. This was data input pin 6 of an 74LS169 chip. This is a 4-bit binary counter. It would make sense for this counter logic to be used in the windowing effect when resizing the display area. To test this theory I quickly connected the damage leg back up and the problem vanished. This was going to be an easy fix!

I socketed and replaced the IC. I powered up the board. It was now completely dead!  I tried a different 74LS169 chip. Still completely dead! I wished at this point I hadn't snipped the legs of the original LS169 and had simply repaired it in-situ.

Suspecting my handiwork fitting the IC socket, I resoldered it for a second time. The board remained completely dead. I was baffled.

I then swapped in a different LS169. The board booted!

I can only presume that a combination of a faulty LS169 I had purchased and some bad soldering on my part caused the board to play dead. Unfortunately I do not have a way to test LS169s ICs out of circuit. The faulty replacement was a 74LS169BN as opposed to a 74LS169AN, but I'm assured they are compatible.

The bootleg has a number of issues, which are probably the result of it being a bootleg as opposed to a fault on the PCB itself:

- The screen momentarily fills with garbage for a frame or so on screen clear
- The sound isn't as clear as an original PCB
- There is no service mode available to test the RAMs and ROMs