Because most retro-computers had only one CPU (i.e. one core, in today’s terminology).

Emulating in parallel a sequential computation is not reasonable (and realistically not feasible).

The graphical cards (or other devices) at that time did not “compute”, only “display” (or do input/output). No need to emulate it in parallel.

And the rare exceptions (for instance Channel I/O on IBM/360 did some simple computation in parallel) don’t deserve a complex multithreaded emulator.

Also, emulators are often complex to code but today they run faster than the emulated hardware, so there is no reason to spend efforts in accelerating them by multithreading.

It might be different if you wanted to emulate at the lowest hardware level, e.g. emulating the physics of each transistor.

BTW, you could try to write your own (maybe multithreaded!) simulator in free software (perhaps by contributing to unisim)

I’ve actually asked myself this question.

The accepted answer makes some reasonable statements, especially regarding the systems and acronyms mentioned by the OP. For sure, true multithreaded emulators don’t give us much at the emulation level.

However, I’ve been looking at getting truer emulation of a KIM-1 board, with more complete RRIOT emulation, with usable maskable and non-maskable interrupts for the purpose of timers (i.e., timers that can be scaled, restarted, and accessed by the programmer).

One approach there is an implementation of multitasking in the emulator (which doesn’t have to actually be truly parallel) so we have independent timers (or a single timer) that can be scaled, hooked up to “interrupts”, etc. That is, user code could run that checks memory locations for timer info that is supposed to be ticking over even as our own program statements are being stepped through. More importantly, it might be a good way to emulate interrupts that a program subscribes to, allowing our own interrupt handlers to work as expected.

The intention is to emulate more closely the machinery of the CPU and support chips so that the registers, programmable interrupts, and read-only memory locations that change as the hardware ticks behave more as expected. But doing it without coding it at the tricky per opcode load-and-execute level.

I think it might be easier to emulate the target CPU speed a little closer, too, or at least get timer resolution pretty accurate. That is, what happens between the various timer location updates and interrupts is not that important as long as those ticks and interrupts are correct when user and ROM routines access them.

Yeah, still a work in progress.

I think the main reason that emulators tend to be single-threaded is that you are managing a very complex state engine; emulators may be the most complex state engines in general.

When you add in multi-threading, you then have to add in locking mechanisms to keep that state engine in proper synchronization. As emulators tend to be emulating older hardware anyway, the performance gain is seldom enough to justify the huge increase in complexity.