I'm trying to emulate programs from the 80s, but with an accurate clock-speed¹ (pretending its an 8086). Meaning that if a 8086 would take X ms/opcode, the emulator should take X ms (+- a bit of jitter as I'm not running a RTOS). If it should take Y ms to access RAM, the emulator should take Y ms to access RAM.

Is there such an emulator (preferably running on Linux or web)?

¹ Which is why I can't use something like qemu.

  • Looks like you are aiming for Machine Cycle level emulation which is pretty rare. The majority of emulators use just Clock Tics (time bursting) which is allowing just specific CPU CLK clock cycles be elapsed in some time interval (like timer) to throttle the speed to relevant emulated clock. Yes in such case the emulation speed seems correct but HW access is far from it. Look here Question about cycle counting accuracy when emulating a CPU sadly I do not know of any MC level emulation of x86 out there but I did not look for it either...
    – Spektre
    Oct 4 '18 at 8:12
  • 1
    Do you mean a cycle exact emulator as per Stephen Kitt's answer or one that runs at the same speed exactly as a real 8086? You will not find the latter because no modern general purpose computer can accurately synchronise at the microsecond level. The best I think you'll get is a cycle accurate emulator that runs the exact number of cycles between screen refreshes and then pauses until the next screen refresh. I did that with a Spectrum emulator and it was good enough to play games without any sound.
    – JeremyP
    Oct 4 '18 at 10:21
  • 6
    To clarify what I think @Spektre means, there’s a huge difference between emulating a CPU’s instruction timing tables (e.g., CLI takes 2 cycles on 808x, 3 on 286, 8 on 386, 5 on 486), including cycle eaters, and emulating the timing diagrams you’ll find in the CPU’s datasheets (and those of all the other chips in a computer). The latter involves simulating the electrical signals on each wire in the system, along with all the different clocks, and requires much, much finer granularity in the simulation (it’s not emulation any more ;-). Oct 4 '18 at 11:57
  • 1
    See also What exactly is a cycle-accurate emulator? Oct 4 '18 at 12:07
  • 2
    @StephenKitt the MC level timing does not necessarily mean simulating pins of HW but usually does at least some like AB,DB busses at specific times so underlying IC emulation can be done at correct time with actual simulated state they need. As the OP implies correct memory access timing I assume MC level emulation is the target.... but to get back to simulation of MC the idea is to break down each instruction to set of basic operations (just like target CPU does) so the memory and IO is accessed the same ways as on the real HW and underlaying flags/states are updated in the same order too.
    – Spektre
    Oct 4 '18 at 12:26

PCem aims to be an accurate emulator, and its 8086/8088 timings are accurate. It can emulate a wide variety of hardware, and can model specific PCs with their ROMs (such as the original IBM PC, the Amstrad 1640, and many others). It is available for Linux and Windows.

Its 8086 emulation is implemented in src/808x.c — you can see there that it keeps track of the cycles taken by each instruction, and each memory access, and takes into account memory prefetches and the cycles lost to memory refresh. It even emulates CGA snow!


Not an emulator but the MicroCore Labs MCL86 is a 8086/8088 core which has the option to be "cycle-compatible" (accurate to within one or two clocks) with a 4.77 MHz 8088. I don't know if it accesses RAM cycle-accurately. A compatible board (Lattice MachXO2-7000HE) is about $30.


A bit hard to answer with the little information you give. Since you especially mention the8086 (not 8088), it may be safe you're not about to emulate an IBM PC.

The i8086emu might be right for you. It emulates a rather straight foreward 8086 singleboard computer with the somewhat generic name SBC8086 :)) That machine runs on 5 MHz, and the emulator is suppoesed to be close. It's made to run under Linux, using GTK2 as frontend, but also compiles for 32 bit Windows.

The emulator got a quite remarkable software structure with interfaces for easy integration of 'new' simulated chips and I/O hardware.

There might be a little hurdle, as most documentation is in German :))

  • 1
    i8086emu is far from cycle-exact. It simply halts the emulated CPU every soandso many instructions (50000 per default) to slow it down to somewhere like 5MHz. So, it creates the impression of a 5MHz 8086, but the real speed between pauses depends purely on your host's performance.
    – tofro
    Oct 4 '18 at 9:49
  • 4
    @JeremyP Cycle exact emulators measure and adjust the timing for each instruction, not the average spent for 50k. When i8086emu was written back in 2004 that was probably not possible, or at least difficult with the hardware available back then (Also clearly not the intent of the developers, so no blame on them). Today, it definitely is. Also, this emulator might have a hard time running the sort of programs the question is asking for (but admittedly, the question is not very clear on this)
    – tofro
    Oct 4 '18 at 10:28
  • 2
    @JeremyP on x86 PC from Pentium and latter very simply. Its just wait loop using RDTSC ... so read cycles at start of instruction and after its done read cycles again and loop until cycles are bigger or equal then simulated time ... so RDTSC and 32/64 bit cmp and conditional jump so 3 or 4 instruction loop in assembly... You just need to set affinity for your process and stabilize host CPU clock. This way you can have even ~40ns granularity these days.
    – Spektre
    Oct 4 '18 at 11:19
  • 1
    @Tommy exactly in Windows its done like this: Cache size estimation on your system? and you need to take in mind this Negative clock cycle measurements with back-to-back rdtsc?
    – Spektre
    Oct 4 '18 at 11:31
  • 1
    Err, even *if all of this works, it solves a non existing problem. The usual case of pseudo accuracy. Like converting feet into Meter to the 5th digit when it's about a sign pointing to the next loo. For evey day use a 50 (or 60) Hz time slice is perfect. In case of a 5 MHz CPU that would be 100k (83k) cycles per slice followed by an adjusting wait. This combines easy system integration (highly monoton 50 (60) Hz timing is available in most systems) with reasonable implementation effort for a workable solution in next to any environment.
    – Raffzahn
    Oct 4 '18 at 14:15

it's not possible to be cycle-exact inside windows or linux because they both have pre-emptive multitasking. You would have to build this emulator to run inside dos or unix.

  • 1
    Welcome! You might find this presentation interesting, in relation to building real-time systems on Linux. Oct 4 '18 at 21:05
  • And I mentioned that I don't mind a bit of jitter.
    – multics
    Oct 5 '18 at 3:43
  • And, to the best of my knowledge, Unix is (and was) also a preemptive multitasking system.
    – multics
    Oct 5 '18 at 3:46
  • 2
    John I think you're taking a different definition of "cycle-exact". It doesn't mean a fixed ratio of emulated cycles to host CPU cycles or real time, it means cycle-exact from the perspective of the emulated system.
    – Dennis
    Oct 5 '18 at 22:13
  • ok now what happens when you are doing that with, say, a c-64 emulator that links to a 1541 emulator? They both have to be cycle-exact in relation to each other or your disk image won't load. I know there's a version of an emulator that combines them, but there are others that don't. More relevantly, if your emulator isn't actually cycle-exact, you'll get display and sound glitches. Most emulators are splitting the "emulation" into modules (this doesn't apply to jit compiled emulators) that represent chips on the system and they have to be able to communicate reliably.
    – John Lord
    Oct 8 '18 at 1:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.