Jump to content

What was the first multi-threaded arcade game?


Recommended Posts

So this sent me on a little hunt over on System16.com. Unfortunately with Japanese companies, the exact date when a game was released isn't always known so it's a little muddy but from what I can see from some searching there, 1980 was the earliest boards with 2 CPUs start to show up. I only found these examples:


Taito's Stratovox

Data East's DECO Cassette system (a small number of games launched for it in 1980)


Caveat - it's possible that the way the hardware was designed used the 2nd CPU for something else other than the game, such as driving a sound chip on Stratovox or tape control on the DECO. One example of a board using 2 CPUs but 1 was for something else was Namco's King & Balloon from 1980, where the 2nd CPU controlled the DAC for speech. Dunno if that counts as multi-threading but again that still puts it all at 1980. I do know that Stratovox came out before King & Balloon at least, so I suppose Stratovox might be the first. 


For Atari, the first double CPU game I can find is Agent X / Cloak & Dagger. Atari also often used multiple POKEYs to get more sound channels

For Midway, their first double CPU game was Blue Print

Sega's earliest I can find is Super Locomotive. Interesting to note that Sega had a 3 CPU game with Komax's Flower in 1986. Taito used 5 CPUs in Big Event Golf in 1986, so that might really count as "multi-threading?"


Otherwise, you'd have to find the first PC-based arcade game that used a multi-threading processor, so likely something from Sega/Namco/Raw Thrills (Namco did use the PS2 & PS3 in some configs, I think the PS3 would certainly count, can't recall if PS2 technically did multi-threads though)

Edited by Shaggy the Atarian
  • Like 2
Link to comment
Share on other sites

I thought the question was kind of odd, since I usually hear the term Multithreading in relation to Real Time Operating Systems (RTOs). An arcade game is a real time system, since it has to service incoming I/O requests from the user (joystick and buttons, coin slot ).


This is usually accomplished via a game loop, where the main() program just goes down the list of methods that handle the game. This isn’t how most people would define Multithreading or RTOS, but since the arcade machine has to respond to user input at regular intervals (likely 60 times a second), and has to refresh the screen at regular intervals (or the screen will roll, since it isn’t a valid NTSC signal), it might be described as Real-Time.

main() {


Traditionally, Multithreading relies on spinning up multiple threads that handle different aspects of a system. And implementing a scheduler that is tasked to run these threads, based upon some priority, so that no thread is dead-locked (never has a chance to run). These threads have to limit the amount of time that they control the CPU. The system itself can preempt control if a thread is taking too long, to make sure that certain tasks are completed in a certain amount of time. It is doubtful that these games spin-up a thread to handle all the different methods / functions of the game. Nor do they likely limit the time spent in each of the threads, and require giving up control to the system.


An example of a Multithreaded 2600 game would be Boulderdash by @Andrew Davie, since the falling of the rocks is performed when the scheduler determines there is available time to move those objects.

Without the Arcade source code, it wouldn’t really be possible to know which if any Arcade game was multithreaded (although they are all real time)

Edited by CapitanClassic
  • Thanks 1
Link to comment
Share on other sites

5 hours ago, CapitanClassic said:

An example of a Multithreaded 2600 game would be Boulderdash by @Andrew Davie, since the falling of the rocks is performed when the scheduler determines there is available time to move those objects.

I think it would be reasonable to call Boulder Dash "multithreaded".  There are a number of processes which run "concurrently"; some over a single frame, and some independently over multiple frames. All use various amounts of available time in the vertical blank and overscan periods. Some are opportunistic and "scavenge" time that is leftover after other processes have found the remaining time is too short.  Some are high priority. Others run once dependent processes are completed. It's definitely not a linear step-by-step thing, and often the order of some things is pretty unpredictable - while other things are guaranteed to happen at particular points.

  • Like 5
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...