A great many Atari-era games ran in two threads.

The first thread attended to gameplay, listening to controller input, keeping score, arranging the playfield, cueing sounds.

The second thread was responsible for sprite-juggling to render the playfield in a more complex way than the hardware designers imagined, the added complexity to be more competitive or emulate the better hardware in arcade machines. This thread effectively "followed the raster".

This was preemptive/cooperative. At a certain point in the sweep/scan, the display hardware fired a hardware interrupt which (preemptively) launched the raster thread. It quit voluntarily (cooperatively) when the raster reached the last point of its concern. If it failed to quit, the game would crash.

If the gameplay module was unable to complete an entire "cycle" of tasks in a single display sweep, that wasn't the end of the world. You could intentionally run the gameplay module on a 2-frame or 3-frame cycle if that made sense, or let it roll asynchronous. Animation or polling tasks that didn't like being asynchronous could also be off-loaded onto the end of the raster thread.

During debugging, you would set the screen border color to different colors for different tasks, e.g. blue for raster-chasing work, red for gameplay tasks handled by the raster interrupt, and green or rotating colors for the main thread. You could watch the colors dance up and down the screen while you playtested, and watch for conditions that overloaded the game.

A great many Atari-era games ran in two threads.

The first thread attended to gameplay, listening to controller input, keeping score, arranging the playfield, cueing sounds.

The second thread was responsible for sprite-juggling to render the playfield in a more complex way than the hardware designers imagined. The purpose of the added complexity was to be more competitive to other games, or emulate the better hardware in arcade machines. This thread effectively "followed the raster".

This was preemptive/cooperative. At a certain point in the sweep/scan, the display hardware fired a hardware interrupt which (preemptively) launched the raster thread. It quit voluntarily (cooperatively) when the raster reached the last point of its concern. If it failed to quit, the game would crash.

If the gameplay module was unable to complete an entire "cycle" of tasks in a single display sweep, that wasn't the end of the world. You could intentionally run the gameplay module on a 2-frame or 3-frame cycle if that made sense, or let it roll asynchronous. Animation or polling tasks that didn't like being asynchronous could also be off-loaded onto the end of the raster thread.

During debugging, you would set the screen border color to different colors for different tasks, e.g. blue for raster-chasing work, red for gameplay tasks handled by the raster interrupt, and green or rotating colors for the main thread. You could watch the colors dance up and down the screen while you playtested, and watch for conditions that overloaded the game.

A great many Atari-era games ran in two threads.

The first thread attended to gameplay, listening to controller input, keeping score, arranging the playfield, cueing sounds.

The second thread was responsible for sprite-juggling to render the playfield in a more complex way than the hardware designers imagined, the added complexity to be more competitive or emulate the better hardware in arcade machines. This thread effectively "followed the raster".

This was preemptive/cooperative. At a certain point in the sweep/scan, the display hardware fired a hardware interrupt which (preemptively) launched the raster thread. It quit voluntarily (cooperatively) when the raster reached the last point of its concern. If it failed to quit, the game would crash.

If the gameplay module was unable to complete an entire "cycle" of tasks in a single display sweep, that wasn't the end of the world. You could intentionally run the gameplay module on a 2-frame or 3-frame cycle if that made sense, or let it roll asynchronous. Animation or polling tasks that didn't like being asynchronous could also be off-loaded onto the end of the raster thread.

A great many Atari-era games ran in two threads.

The first thread attended to gameplay, listening to controller input, keeping score, arranging the playfield, cueing sounds.

The second thread was responsible for sprite-juggling to render the playfield in a more complex way than the hardware designers imagined, the added complexity to be more competitive or emulate the better hardware in arcade machines. This thread effectively "followed the raster".

This was preemptive/cooperative. At a certain point in the sweep/scan, the display hardware fired a hardware interrupt which (preemptively) launched the raster thread. It quit voluntarily (cooperatively) when the raster reached the last point of its concern. If it failed to quit, the game would crash.

If the gameplay module was unable to complete an entire "cycle" of tasks in a single display sweep, that wasn't the end of the world. You could intentionally run the gameplay module on a 2-frame or 3-frame cycle if that made sense, or let it roll asynchronous. Animation or polling tasks that didn't like being asynchronous could also be off-loaded onto the end of the raster thread.

During debugging, you would set the screen border color to different colors for different tasks, e.g. blue for raster-chasing work, red for gameplay tasks handled by the raster interrupt, and green or rotating colors for the main thread. You could watch the colors dance up and down the screen while you playtested, and watch for conditions that overloaded the game.