CannonBall V0.31 - Maintenance Release

This release focuses on upgrading the libraries and compilation tools CannonBall uses, as I hadn't maintained the codebase in a number of years. Most of these changes will be invisible to most users. Right now, I'm trying to get the house in order as opposed to add lots of wild new features! :)

The most exciting news is the upcoming SmartyPi support, but until the hardware is released, that's kind of a mute point!

Changes:

[audio] Audio updates at the correct rate and resolves the longstanding issue with music and sound being very slightly 'off'

[roms] ROMs are now read by CRC 32 value. Filenames no longer matter - so long as they are present they can be renamed to anything.

[roms] Fixed expected Z80 rom file length

[controls] Start Button behaviour less 'sticky' and buggy

[controls] Analog axis for accelerate and brake can now be configured via the in-built menu system

[menu] Reduced delay when scrolling through menu with analog controls

[config] ROMs and save data can be relocated to separate locations

[bug fix] Time Trial mode no longer crashes if used as the first mode played

[timing] Code tries to use V-Sync for timing OR internal timing, as opposed to both at once

[source] SDL 2 used by default. SDL 1 removed from codebase. This appears to have fixed compatibility bugs for some people

[source] Added compatibility for upcoming SmartyPi hardware (Pi 4 based) to run on original arcade hardware

[source] A general clean-up in many areas

OutRun: Enhanced Edition 2.02

OUTRUN: ENHANCED EDITION V2.02

OutRun: Enhanced Edition is a set of 7 replacement EPROMs intended for use on original OutRun arcade hardware. 

It fixes many bugs present in the final official codebase (Rev. B), and introduces new features to extend the life of the game, including: 

• Working Free Play Mode
• High Score Saving
• Additional High Score tables
• 3 additional in-game audio tracks
• Best Track Time (aka ‘Lap Time’) records
• New and old course layouts
• Software DIP Switch support
• Cheats - including infinite time and the ability to disable traffic
• Optional car handling modifications

Full documentation and installation instructions

To register:
1/ Complete this form

2/ Consider an optional charity donation

Bringing Turbo OutRun Audio to OutRun: Rush A Difficulty

Following Camino’s optimization, I performed a similar treatment on Cruising Line, the remaining 3DS track. I reduced the track’s filesize from 24K to 9K using a similar set of techniques. Cruising Line does not suffer from the quantization issues that plagued Camino, which made the process a little easier and yielded even better results. So far so good and there was plenty of ROM space left to stuff with additional music! The next Enhanced Edition will contain three new audio tracks, which is an amazing result.

Originally, I considered bringing the new Switch music into the fold: Radiation and Step On Beat. However, from a subjective point of view, neither of these tracks are particularly great. I felt like they didn’t sit harmoniously with the existing music, and I wasn’t prepared to spend many weeks optimizing music I didn’t love.

Turbo OutRun - A prime example of what happens when you don't understand your own product.

Instead, I turned to another reference point in the OutRun universe - Turbo OutRun. Whilst Turbo OutRun is arguably a disappointing sequel, the soundtrack is impressive. In particular, Yasuhiro Takagi’s ‘Rush a difficulty’, which is an upbeat number that wouldn’t sound out of place in the original game. As an aside, Takagi went on to become sound director for Shenmue II, before moving to the Yakuza series.

Listen: Rush A Difficulty

Terrible Name. Amazing Track.

Turbo OutRun runs on the same hardware as its predecessor so, on the surface, the idea of converting the music might appear simple. Being a hand-crafted piece of MML, we wouldn’t need to worry about the rigorous optimization process required by the 3DS audio. However, the audio engine embedded in the Z80 program code isn’t identical. Between OutRun and Turbo OutRun Sega added a number of improvements to the engine. Firstly, an extra 3 PCM channels can be utilized by music, bringing the overall number of simultaneous samples to 8, bolstered by the usual 8 FM channels. (On OutRun, these 3 channels are strictly reserved for sound effects and can’t be used by music.) Secondly, samples can be played at different pitches. Let’s say the composer took a sample of an electric guitar chord, this could be triggered at different pitches and replayed like an instrument. AfterBurner used this functionality to great effect with its guitar-laden riffs. Whilst the samples are 8-bit, and relatively lo-fi compared with clean Yamaha FM patches, they add depth and grit to the overall mixdown when used wisely. In order to backport the music to OutRun, considerable changes would be needed.

So, the Turbo OutRun engine uses additional channels and manipulates sample pitch intelligently. It was time to decompile the necessary sections of Turbo OutRun’s Z80 code to start analyzing the raw music data. A starting point was the PCM channels, as we potentially needed to remove or remap the extra ones. It was immediately clear that 2 PCM channels were permanently disabled. Interestingly, the disabled channels contained an early draft or a guitar riff for the tune that sounded unfinished when reactivated. This was good news, as it meant there was only one extra channel of audio to worry about. The extra channel contained a sampled driven slap-bass line. Converting this back to OutRun would be problematic. It would involve finding space for the slap-bass sample in the, almost full, sample ROMs and backporting the pitch manipulation code. Plus there wasn’t a spare PCM channel to use anyway, so this was a non-starter.

The bass line was an essential ingredient of the track - it sounded sparse without it. I decided to recreate the bassline as a YM patch/instrument. CMonkey had the great idea of sourcing a patch from a Megadrive rendition of Rush a Difficulty. The patch wasn’t perfect, but proved a good starting point for further manipulation. I used the VOPM plugin, which emulates the Yamaha 2151 chip, to modify the patch further, before converting the data back to the format required by the OutRun engine.

VOPM Plugin. Spend ages fiddling with knobs

A YM patch will never sound as beefy as a sample, but it’s not a bad compromise. I replaced a, sparsely used, existing YM channel that didn’t contain a strong lead with the bassline.

Audio Comparison

The next hurdle was remapping the track’s percussion. The Turbo OutRun music utilises a different set of drum samples. Now, we could theoretically replace all six sample EPROMs on the PCB with larger ones to include these new drums, and solder the corresponding jumper. But at a practical level, this seems like a big ask on the poor user just for the drums on a single track! Most of the Turbo OutRun drums have an equivalent in OutRun - kick drum, snare, hi-hats, tom-toms etc. Whilst the OutRun drumset doesn’t contain as much reverb, this seemed like a sensible compromise for now.The only one that’s missing is the cowbell, which I mapped to a wood rim instead.

One final change was needed. The entire Turbo OutRun engine runs at a different timing value to OutRun. To work in OutRun, the engine needs to be temporarily patched to the Turbo value, but only whilst the music is playing. I have a temporary fix for now, which will need to be improved before release. So finally, the track is successfully converted. The main differences are: remapped drum samples, the sampled bassline replaced with a YM patch, with the resulting loss of a single YM channel.

Listen: Sunset Rush (The Enhanced Edition Remix)

So there we have it. A different challenge to optimizing the 3DS music that entailed rewriting existing tooling, decompiling the Turbo OutRun audio engine and converting the MML data and commands to an older format.

I’d also like to thank cmonkey, without his assistance this would have taken much longer. When working on a project of this nature it's invaluable to have someone to bounce ideas off, challenge your assumptions, and sometimes make you feel (unintentionally) ridiculous. I've been incredibly lucky to find someone who understands the Sega audio engine as well as he does, and I wish I could say more than, "thanks buddy!"

The Incredible Shrinking Camino!

When creating the 3DS and Switch versions of OutRun, developer M2 added a number of new music tracks. Thankfully, most adhered to the original Music Macro Language (MML) format used by the original game. Once extracted from the 3DS, the music data plays out of the box on original hardware, with minimal modifications to the Z80 program code. Delightful dedication on behalf of the composers. 

Unfortunately, as mentioned in the previous blog post, the file size of this new music is substantially larger than the original music. As a comparison, the new tracks weigh in at around 3-4 times the size.

This isn’t a result of additional length or musical complexity. File size is simply not a concern on modern hardware. However, my dream is to add multiple music tracks to a future release of OutRun Enhanced Edition. This relies on the hope that they could be reduced in size and programmed back to the original arcade PCB, without the need for additional hardware. As such, I’ve spent my evenings studying and optimizing the first OutRun 3DS tune: Camino a Mi Amor.

The original music was composed by Hiro on a Roland MC-500 keyboard and transcribed as sheet music, before being hand translated to MML. This ensured the original MML was well structured and highly optimized. After coding an MML decompiler, I could study the new music and determine why there is a size disparity, and more importantly recompile any optimizations back into the OutRun audio engine.  

It was clear that the new MML data was auto-generated by some kind of tooling. I believe that the new audio was composed in a modern Digital Audio Workstation package (DAW)  and then run through a conversion process for reasons I’ll outline below.

1/ The music is incoherently structured. 

One of the powers of Sega’s Music Macro Language is the ability to use nested loops and subroutines. When used wisely, these radically reduce data duplication and therefore save a lot of space. Music is inherently repetitive, especially when divided into individual channels of audio. When studying Camino, it’s apparent the subroutines have been automatically generated, rather than created by hand. Rather than a subroutine containing a musical pattern that make sense in isolation, subroutines frequently start and end at illogical points from a composition perspective. Many of the subroutines are called just twice whereas you’d expect, especially with repetitive channels containing drum patterns, a much greater degree of reuse. 

M2 were on point for writing tooling to identify repeated sections of data. Theoretically, it’s a smarter, faster approach than attempting to optimize by hand. However, it’s a difficult problem to solve well and the results are only as good as the algorithm. And in this case, the results are mediocre. Aside from badly structured subroutines, the tooling created subroutines that are called just once, rendering them pointless. And furthermore they’d overlooked a separate problem further up their toolchain...

2/ The music does not adhere to the inherent timings of the audio engine. 

As Cmonkey explained in his documentation: the overall tempo of the tune is controlled by timer A on the Yamaha 2151 sound chip. This timer is loaded with a value of 524 during initialisation of the audio engine.  The calculation used for the timer A period (in ms) is:

   tA = 64 * (1024 - tAvalue) / input clock (KHz)

The sound chip has an input clock of 4 MHz (4000 KHz).  So this means the timer A period is calculated as:

   64 * (1024 - 524) / 4000 = 8ms

So, to play a note for 1 second, you'd pass a value of 125 as the duration (125 * 8ms = 1000ms = 1s).

Now, where Camino a Mi Amor falls foul of this system is that its core timing is not divisible by units of 8ms. As such the music is quantized to fit the audio engine’s timing, ensuring the notes align to 8ms boundaries. Let’s look at a typical sequence of notes to clarify this point. This series of commands simply plays the note D at octave 4 a number of times with a few rests thrown in for good measure. 

Command	Time V1	Time V2
D4	57	58
D4	28	27
D4	14	14
D4	14	14
REST	15	15
D4	14	14
REST	14	14
D4	14	15
D4	29	28
Length	199	199

So far so good. However, the second time this sequence is exported from the DAW to MML, there are subtle timing differences:

1. The first version of this sequence plays D4 for a length of 57, which is 456ms (57 * 8).
2. However, the second version of this sequence plays D4 for a length of 58, which is 464ms (58 * 8).
3. This disparity is offset by the second use of D4 in the sequence, where the timing is inverted. 

Both versions of the sequence last the same total duration, but the notes are aligned differently. Imagine the original composer setting a chosen tempo in his audio software. When the exporter reached the second version of the sequence, it was quantized to the closest possible duration, in order to work with the default audio engine timing. The second time round, the quantization was applied to different notes in the sequence. The difference is inaudible to the ear and, in fact, an artefact of M2’s tooling, rather than a deliberate artistic choice. The timing differences also affect the drum patterns, which you would expect to be rigid, rather than variable. It should also be noted that the timing differences are only ever +/- 1. Any additional difference would be an artistic choice. To compound the problem, the tooling inserts additional ‘REST 1’ commands in various sequences to compensate for the timing differences, which wastes further space.

For file size, this is a critical problem. Each version of the sequence is now treated as a separate block of data, rather than a shared subroutine. It’s effectively different from a data perspective, despite sounding identical. This is part of the reason the previously described subroutine automation is a failure. It is fed imperfect data to process and cannot identify sections of the audio that should be identical. Whilst my example shows just two versions of the same sequence, in reality there are often many more. This is incredibly wasteful, as well as making the resultant MML unwieldy.

We’re faced with bulky MML, littered with illogical subroutines, that needs a major restructure to wrestle it into shape. I tackled the problem by listening to each channel of audio in isolation and capturing it to a waveform. This helped build a mental and visual image of the structure of the music channel. The next part of the process wasn’t an exact science, but I started visually identifying chunks of MML data that looked similar, unrolling subroutines where necessary. I built a Google Sheet that would help me do this.

I could simply copy and paste two giant blocks of MML data that I suspected were identical into the sheet. The sheet formulae would verify the list of commands were in fact identical, verify the timing of each command didn’t differ by more than +/-1 timing unit and finally sanity check that the overall timing of the block was identical. Once happy, I could return to the MML, remove the obfuscated original data and subroutines and move them to a shiny clean subroutine. 

Effectively, I was consolidating all of the data variations back into a coherent section of music. Some of these could be reused multiple times, which was a huge optimization. If you think back to the previous example with two versions of the same sequence, there is no reason both of these sequences shouldn’t be identical, as long as the overall timing of the block is the same. The upside to this, is that we’re returning to the vintage 1986 Hiro approach of hand-crafting MML. We can make genuine use of powerful loops and smartly organised subroutines. 

I’ve made this process sound a breeze, but in reality it was time consuming and error prone.  With over 10,000 lines of MML data to work with for the first track alone, one small error could throw the timing of the entire tune, especially if the error was contained in a loop that was iterated over multiple times. I found I could manage 2 to 3 hours of this work at a time, before needing to call it quits. Despite that, it is an incredibly fun puzzle to crack. My score was the byte count. Every time I hit recompile, my savings were output to the console. The lower the score the better I felt. Sometimes I needed to increase the overall size in the short-term as a strategy to reduce it considerably in the long-term. I’m unsure whether this process could be automated to produce MML that was as clean. Maybe it could and I just don’t want to admit it. Certainly, it would be easier to improve M2’s tooling to create better MML in the first place, if I had access to it. 

3/ Cross channel optimizations are missed. 

Wait, we’re not done yet! There were other easy trends to spot. For example, FM channel 0 and FM channel 1 shared a bunch of note data. I suspect the conversion tooling did not work across channels. It was trivial to move this into its own subroutine. 

4/ The REST command is everywhere! 

For FM channels, the REST command largely serves a purpose. It’s akin to depressing the note you’re playing. However, for percussion channels it serves less of a purpose. Consider the following sequence of commands:

    KICK_DRUM 42

    REST 10

    KICK_DRUM 14

This translates to: 

• Play the kick drum sample. Wait 336ms (42*8).
• Rest for 80ms (10*8).
• Play the next kick drum in the sequence. 

The technicality to note is that once a sample is initiated, it can only be interrupted by another sample. The REST command adds little value, beyond inserting a delay before the next command. Therefore, the above block can be optimized to:

    KICK_DRUM 52

    KICK_DRUM 14

We’ve shaved 2 bytes from this 6 byte sequence! This might not sound much in isolation, but when the command is littered across all percussion channels, you can claw back a considerable number of bytes and save Z80 cycles in the process.

Generally speaking, for FM channels the REST command should be left well alone. Removing REST commands would change the way notes sustain and decay. However, there are exceptions to this rule. Earlier, I mentioned M2’s tooling had inserted ‘REST 1’ commands in the FM channels to compensate for audio timing differences. This was particularly obvious when comparing two identical blocks. One might look like this:

F4 14

  REST 1

  F4 28

  REST 14

The second might look like this:

      F4       15

      F4       28

      REST     14

The first block adds an 8ms rest between the two F4 notes. The second block adds the delay to the time the note is played for and does away with the REST command entirely. Therefore, both versions could be condensed into the succinct second version. This optimization might appear to be a leap of faith, but it does become apparent as artefact removal when analyzing 10,000 lines of MML by hand! I studied both variations in a wave editor and found no visual difference, let alone an audible one. In reality the block would be longer than the example provided of course.  

5/ Patches and Erroneous commands.

My MML decompiler performs other handy analysis. For example, it denotes which FM patches (or FM sounds if you like) are in use by the track. The unused patches can quickly be removed by hand. Furthermore, the MML contained junk data. For example you’d see command sequences as follows:

  LOAD_PATCH 6

  REST 10

  LOAD_PATCH 16

  C4 10

Clearly the initial LOAD_PATCH command is trumped by the second and can be removed. There's no need to load the first sound patch, as no notes are played! There were other examples of redundant commands that also provided a small but welcome saving. 

In Conclusion

In total, the above methods sliced a whopping 10k from the original track - a saving of 46% - with hopefully no loss of musical integrity! But this hard work is only just the beginning, and soon I'll need to tackle the next track - Cruising Line.

Parting Words

I’m frequently asked if a feature or idea is possible. Can something be done? Couldn’t you just…? And the answer is often theoretically yes. Yes, if you’re prepared to pour time and energy into seeing a hair-brained scheme through to fruition. Of course, you could, and maybe should, view this entire process as complete madness. All this effort to trim mere bytes from a binary file: reversing the MML format, cmonkey’s robust tooling to create and compile MML files, the decompiler to reverse 3DS binaries back into an editable format, countless evenings spent manually manipulating data with a hodgepodge of makeshift tools. And we’re nowhere near done yet, but let’s keep going, because no one else will!

Raiding Hiro's Sega Audio Archives

In recent years, Sega consolidated its scattered Tokyo offices to a centralised building in Ousaki. One office that closed at the start of 2019 was the Otorii office. This office had been the key development hub since September 1985, shortly after Hang-On development concluded. As such, intriguing development materials were unearthed in the process.

Sega Otorii Office Building

Hiro posted a vast collection of audio planning documents and media from 1985 through to the early 1990s. When Hiro joined Sega in 1984, music was composed on hand-written sheets.

Space Harrier Sheet Music. Note that game was called 'Heli' at this stage, as the fantasy theme had not yet been adopted.

Synthesizers used to compose the melodies included the Yamaha DX-7 for Space Harrier and the Yamaha PSR-70 for AfterBurner. The sheet music was manually transcribed into Macro Music Language for the audio engine to process. This took the format of the note, followed by its length (e.g. C-4, L4, A#4, L8). Once assembled, the actual audio could be tested on hardware. Needless to say this would have been a time consuming process.

Hiro's ROM cartridges for the Yamaha DX-7 Synthesizer

For the arcade games of this era, sound comprised lo-fi 8-bit samples used for voices, drums and sound effects. The samples were paired with a YM sound source (typically a Yamaha YM2203 or YM2151 chip), mostly used for melodies. YM sounds could be created and edited with an audio editor, which ensured each game had its own style, despite sharing audio hardware. For example, AfterBurner's 'Final Take Off' uses the YM to drive the melodies, but the overlaid guitars are in fact samples.

Data was saved to 8 inch floppy disks.

The following labels read 'OutRun 2' in reference to the revision of the music, as opposed to being anything to do with OutRun's sequel. I wonder if the earlier revisions of the OutRun music still exist?

OutRun's 'Passing Breeze' was initially named 'Passing Wind', until someone pointed out the flatulence reference. So the disk below must date from the end of the development process!

AfterBurner was aptly referred to as 'Top Gun' during development, and the final audio program code appears to have been named TG.HEX. Some of the disks are dated 9th September 1987. 

It appears that data was transferred over the years between 8 inch floppy, through to 5.25 and 3.5 inch floppy for preservation. 

Here we can see the list of commands Power Drift's main 68k program code needed to send to the Z80 Sub program in order to trigger the relevant sound. 

The final Power Drift master. Later on Digital Audio Tapes (DAT) replaced reel-to-reel recordings. 

The Best OutRunners: Who Made OutRun?

Video game publishers were secretive in the 1980s. In a highly competitive market they didn't want star developers poached by rivals. Whereas by the mid 90s, titles like Daytona USA included a full credits list, the 1980s saw developer credits constrained to Easter Eggs and cryptic initials on the high score table.

Unfortunately, as a result of this, many developers remain uncredited for their work. Nevertheless, it's a fun challenge to establish the development story of an influential title like OutRun! 

The seed of OutRun was planted in July 1985, when Sega produced a design document for a game codenamed Dead Heat. This was a response to the success of Hang-On and within Sega there was a business objective to better Namco's Pole Position, which arguably it did depending on which set of figures you believe. Some cite over 20,000 OutRun machines sold, whereas others over 30,000. 

The original design documentation, exhibited in full at the CEDEC 2019 conference, initially proposed an F1 based game, like Pole Position, but with the ability to race a rival player head to head. It also proposed road branching and road inclines, two features which made the final cut.

By December 1985, the design had gravitated from F1 to sports cars. The multiplayer feature had been dropped for budgetary reasons. Instead, focus shifted towards making the tracks as interesting and feature rich as possible. The game was now codenamed Spark Rally.

The final design documentation, dated 30th June 1986, is credited to Youji Ishii, I. Yutani and Motoshige Hokoyama (who later directed Shadow Dancer). By this time, the game was called OutRun.

Youji Ishii, who joined Sega in 1978, first worked with Yu Suzuki on Hang-On. He is notable for his hands-on role developing Flicky and Fantasy Zone. He project managed OutRun and handled other elements of the production. He was effectively Yu Suzuki's boss. His role would be equivalent to an Executive Producer or studio head in western development terminology. 

In Szczepaniak's interview in The Untold History of Japanese Game Developers Vol 3, Ishii humbly credits much of the creative vision for OutRun to Yu Suzuki noting, "I mostly left things up to Suzuki. So it's actually correct to say Yu Suzuki was the one who deserves credit". Ishii doesn't receive a credit on the high score table despite managing the project and contributing to the design documentation.

Sega's development studio in Haneda, located next to Sega HQ. This is where OutRun was developed.

OutRun was developed by a small team over the course of eight to ten months. The team consisted of four programmers, five graphic designers and one sound creator. (The Making of OutRun). Space Harrier's code contains a hidden November 1985 date, and OutRun's September 1986. So presuming the core team moved straight from Space Harrier to OutRun, that confirms a 10 month development cycle. There are remnants of Space Harrier's assets in OutRun including the Space Harrier font, and a sound sample so this seems a reasonable assumption. 

VHS-C Tapes from the road trip. One tape is dated 30 April 1986, Monte Carlo. (Source)

In April 1986, approximately 5 months into production, Ishii and Suzuki embarked on a European roadtrip to scout locations for OutRun. The original plan had been to travel to New York and cross America, due to the influence of The CannonBall Run movie. But Ishii claims Hayao Nakayama, the head of Sega, thought this would be too dangerous. (Untold History Vol 3). Suzuki's recollection of events differs, "I realised, once I’d arranged everything, that the scenery along the [pan-America] course actually doesn’t change very much, so I revised my plan and decided to collect data in Europe instead." (The Making of OutRun). This change in focus mid-development perhaps explains why OutRun starts with the California influenced Coconut Beach, before becoming more European in nature. Both Ishii and Suzuki cite the Romantic Road in Germany as a particular influence. It's reasonable to assume that Coconut Beach was developed before the trip took place, as there's an early test variant of that level still present in the ROMs. 

So now we come to decipher the cryptic Best Outrunners list, which offers seven entries from the overall team size of ten. Like all good games, it starts easily enough, but soon gets tough!

1. First up, needing no introduction, is Yu Suzuki (YU.) Yu Suzuki acted as the creative lead and planner on OutRun, but was also a hands-on programmer. He mentions, "I wrote all of the important planning and programming parts myself; I don’t think anything was really influenced by the development staff." (The Making of OutRun).

However, the creative influence of the OutRun team was perhaps more prominent than Suzuki recalls, as we shall see. There's no doubt that Suzuki was the lead visionary from a technical and creative standpoint. It's his name that's present in the Easter egg, indicating his role in developing the program code. With such a small development team, it's clear that many of the individuals wore multiple hats as a result and Suzuki is no exception. It should also be noted that Suzuki composed a couple of the music tracks for Space Harrier including Ida and Valda. The Sega teams contained multi-talented individuals. 

Suzuki's creative reference points included The CannonBall Run movie, his European roadtrip with Ishii and the art of Hiroshi Nagai. 

Suzuki in a BMW 520, the car used for the European roadtrip. Photo dated 1986.

2. The seconds entry reads BIN. This is Satoshi Mifune, who likes to be known as Bin-Chan. (4gamer). He joined Sega in April 1985, and would have been just 18 years old at the time. (AM2 Web Archive).

Satoshi Mifune testing OutRun. [Credit 4gamer]

His first project was a supporting role on Hang-On, where he first worked with Yu Suzuki. From there, Mifune programmed high profile projects including Space Harrier, OutRun, AfterBurner, Dynamite Dux, Turbo OutRun through to Virtua Striker and even Shenmue! 

As we've covered on this blog, he's credited in hidden debug text within the game relating to the colour palette.

3. KAG is possibly Takafumi Kagaya, an AM2 designer credited on Daytona USA, Virtua Cop and Virtua Figher amongst other titles. Entering KAG on the Daytona USA high score table plays a hidden jingle. It's not unreasonable to assume he could have worked on OutRun, but I've not seen concrete proof of this. 

4. MIY is Hiroshi Miyauchi, more commonly known as Hiroshi Kawaguchi. One of Sega's longstanding and prolific composers, if not one of the most famous video game composers of all time. Continuing the multi-talented trend of the team, Hiro originally joined Sega as a programmer, impressing Yu Suzuki with his assembly skills at interview. It was common for composers to manually transcribe their music into assembly macros and even write sound drivers at Sega during this period, so perhaps this isn't surprising. (The Rock Stars of Sega). 

In terms of creative decision making, there is light-hearted disagreement with regard to who suggested certain features, contradicting Suzuki's claims that he didn't rely on the development team for input.

During a revealing interview fellow Sega composer Takenobu Mitsuyoshi jokes that Suzuki usually liked to assume ownership of ideas. Hiro laughs when he recalls "Yu Suzuki used to say he came up with [the idea of OutRun's music select] himself." Before adding, "but I seem to remember the designer creating that radio screen and saying, 'hey, if this is a radio, you should be able to select your own songs!' I do remember, however, that the screen originally didn’t show the hand. The original design was just the car’s dashboard. But once you were able to select songs, I asked Yu Suzuki whether we should have a cursor or some indicator on-screen to show people they could choose their music. Ultimately I'm the one who decided we didn’t need to do that, though." (The Rock Stars of Sega).

Hiro references Naoya Matsuoka and Cassiopeia as direct influences on OutRun's soundtrack. "If I had not heard Mr. Naoya Matsuoka's songs, I don't think OutRun's music would have been born" (Sound Creator Interview).

The following image shows Sega's offices around the development of OutRun (Twitter). Hiro can be seen in the foreground playing the keyboard wearing casual clothes, unlike his colleagues. On the right is Mr. Yamamoto who was responsible for transcribing the sound data for OutRun.

5. MAT is programmer Tetsu Matsushima. Like many others on the team he worked across Space Harrier, OutRun and AfterBurner. (MegaDrive Collected Works) He went onto work for Rutubo games, which produced the arcade perfect Saturn ports of the aforementioned titles.

Whilst Suzuki claimed, "The [OutRun] game development team was made up of people who happened to be available at the time, so I wasn’t able to assemble the team according to my wishes", (The Making of OutRun), this must be taken with a grain of salt given Hiro, Mifune and Matsushima appear to be a close-knit unit migrating from Space Harrier onto OutRun, before decamping to their skunkworks Studio 128 office to develop AfterBurner. (AfterBurner II - Developer Interviews). The pixel art style of these three titles is also consistent, which would suggest many of the artists moved from one project to the next.

6. IKA and A.O

Sadly, I can't establish who these individuals are. Maybe they were members of the art team, of which I can find no information at all. Even when John Szczepaniak directly asked Youji Ishii, on my behalf, for the remaining developer credits during an interview in The Untold History of Japanese Game Developers Vol 3, he was unable to recall all the names. For now, the road sadly ends here.

Hopefully one day I'll uncover more information and update this article. If you have any further information, please let me know in the comments below.

Timeline

1978 - Youji Ishii joins Sega
Apr 1983 - Yu Suzuki joins Sega as a programmer

July 1983 - Yu Suzuki assigned to R&D department
1984 - Hiroshi Kawaguchi joins Sega as a programmer
Nov 1984 - Yu Suzuki transferred to Software Development Division 1
Apr 1985 - Satoshi Mifune joins Sega as a programmer to work on Hang-On
July 1985 - Hang-On Released
July 1985 - Space Harrier Development Starts
July 1985 - OutRun Design Revision 1 (Codename: Dead Heat)
Sep 1985 - Space Harrier concept with jet plane displayed at AM show
Sep 1985 - Development relocates to 'Office 2', next to their HQ. Used until Feb 9th 2019
Nov 1985 - Space Harrier Released
Dec 1985 - OutRun Design Revision 2 (Codename: Spark Rally)

Apr 1986 - Yu Suzuki transferred to Software Development Division 2
Apr 1986 - Yu Suzuki & Youji Ishii embark upon European Research Trip

June 1986 - OutRun Design Revision 3 (Rebranded OutRun)
Sep 1986 - OutRun Announced at Sega Tokyo press conference 22nd September
Oct 1986 - OutRun Exhibited at 24th AM Show (7th & 8th October)
Dec 1986 - AfterBurner Development Starts. Team relocates to Studio 128.
July 1987 - AfterBurner Released
Oct 1987 - AfterBurner 2 Released

Aug 1988 - Power Drift Released

Studio 128. The team decamped to this small premises to develop AfterBurner and Power Drift