Cooperative Threading — Near's Respite

submited by

Style Pass

2021-06-23 09:00:05

Perhaps the largest challenge to writing an emulator is grappling with programming code being inherently serial, whereas the emulated systems often contain many, sometimes even dozens, of parallel processes all running at the same time.

In fact, most of the overhead of writing a retro video game system emulator is managing the synchronization between components in this environment.

In this article, I'll go into the approach I chose for my emulators: cooperative multi-threading. Please note that this is but one of several approaches, and I am not here to advocate for one or the other. I will do my best to present an unbiased look at its pros and cons.

Let's say we are emulating the base Super Nintendo, which has four major components: the general-purpose CPU, the audio APU, the video PPU, and the sound output DSP. Note that I'm simplifying things a bit here (eg there are two PPU processors) for the sake of example.

Our emulator needs to run each chip in serial, or one at a time; whereas the real SNES would run all of these chips in parallel, or all at the same time.