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.
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.
Top PCB
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
Following my painful success fixing a TMNT PCB, I decided to move on and try another.
I bought an untested (tm) Shinobi PCB from ebay as I like the game.
The PCB was in a dusty state, but was complete.
Of course, the board didn't really work. Although I was pleased to see it booted and did something!
The most noticeable problems:
1/ The graphics either had jailbars or were completely missing
2/ There was no sound.
The game was actually playable under all those jailbars.
The first thing I did was to remove Sega's FD1094 processor and replace it with a stock Motorola 68000. I reprogrammed the relevant EPROMs. There are also some reports that these boardsets exhibit unpredictable behaviour, including the sound failing, when the battery is on the way out. This didn't fix any of the issues, but gave me the comfort in knowing the board wouldn't die in the future when the ageing processor battery expired.
Graphics
The test mode showed one of the RAMs was bad.
This is the RAM shown below.
I bought a spare from China, and socketed it. Desoldering went a little smoother than the TMNT desoldering marathon, but I still had to snip the legs of the old chip and spend maybe an hour or two on the chip. The end result was pretty clean, so at least my desoldering is improving. I can't say this is a particularly enjoyable part of the hobby for me.
Unfortunately, this didn't fix the bulk of the issues.
On a positive, the RAM test now passed, and the graphical problems seemed marginally better with less random garbage on-screen. The jailbars remained though.
At this point, I could tell that it was just the tile graphics that had problems. The sprites seemed fine. I did some highly technical 'pressing on EPROMS' and noticed I could reduce the width of the jailbars with some pressure.
I removed the tile EPROMs and checked them in my reader. One of them was full of junk data and didn't match the expected CRC.
I programmed a new EPROM and the graphics were restored and the game looked perfect.
Unfortunately, after running the game for about 30 minutes the sprites also developed a problem with lines running through them.
In hindsight, maybe this problem was intermittent as the sprites were also screwed in my original screenshot of the game.
I used my System 16 Sprite Viewer to determine where the garbled graphics were located. Once again, I found a faulty EPROM and reprogrammed it.
Graphically everything is working again! Phew!
Sound
- I verified the 3 sound EPROMs were good. After all the previous EPROM failures, they were the first thing I suspected.
- I checked the Z80 isn't in a HALT / RESET state. It seemed to be running.
- I could hear hum from the amp when the pot is turned up. Tapping the logic probe on the outputs of the YM3012 causes audio interference.The amplification part of the circuit is working. However, data wasn't being fed into this chip correctly. So something was going wrong upstream.
- I tried piggybacking the SRAM used by the sound processor. This didn't change anything.
Using a logic probe, I spotted some bad activity at the YM2151 sound chip The following pins were suspect:
21 Serial Output
Stuck Low [Connected to DATA on YM3012, should be doing something]
20 Sample & Hold 1
Stuck High [Connected to SAM1 on YM3012, should be doing something]
19 Sample & Hold 2
Stuck High [Connected to SAM2 on YM3012, should be doing something]
There was sensible looking activity on the data and A0 pins. Downstream, the YM3012 wasn't doing anything sensible. The analog and channel outs were floating.
I didn't know which of the two components was faulty, so I ordered both. The output from the YM2151 was clearly borked whereas the inputs seemed sensible. I wasn't entirely sure whether a damaged YM3012 could also be causing this.
I socketed and replaced the YM3012 first, mainly because it had fewer pins to desolder!
This didn't fix the problem, so I socketed and replaced the YM2151.
I haven't done any coding work on CannonBall lately. This isn't because the project is abandoned, or that I've lost interest as I still have plenty of ideas. It's simply a result of my limited amount of time and as such I've focused my attention elsewhere.
Having said that, Manuel Alfayate has made some critical backend changes which result in CannonBall performing really well on Linux based systems including the Raspberry Pi. Previously performance was stuck in low gear.
Firstly, he has ported CannonBall to SDL 2. The codebase previously used the ancient SDL 1.2 library. This results in accelerated, fullscreen, X-less mode for the Pi using SDL 2. To utilise this, you must build the sdl2 or sdl2gles cmake profiles.
Right now, SDL 1 is still included in the codebase and is the default for Windows, but it will be phased out the next time I release a new version. Right now , the main benefits will be for Linux based systems where you don't want to rely on an X-Windows GUI environment.
There is still optimization needed for the Pi 1 and Pi Zero. I'd like to look into this when I have some time. But once you're past the sluggish start line, you can achieve 60fps in widescreen mode. Not bad for a $5 machine.
Here's a video of the changes in action with the frame counter on display. A $5 OutRun PCB could closer than you might think...
I recently extracted all my PCBs from my parent's garage. These had been sat in cold conditions since the 1990s and not used in years.
Surprisingly, everything I tested worked. Apart from my Konami TMNT which had corruption to the graphics. The sprites rendered fine in isolation, but the tiled graphics clearly had major problems.
The game ran fine.
The sound plays.
The RAM/ROM check passed. The Mask ROM check failed. This required setting a DIP switch to test.
Unfortunately, the Mask ROM test screen was so garbled it was unreadable and I inferred the wrong Mask ROM was bad! In the end, I swapped out two ROMs rather than one. For reference the screen looks like this (not my picture!)
After desoldering the Mask ROMs, I used 27c400 EPROMs as replacements.
