Is there a cycle-exact 8086 emulator?
Clash Royale CLAN TAG#URR8PPP
up vote
9
down vote
favorite
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.
emulation 8086
 |Â
show 3 more comments
up vote
9
down vote
favorite
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.
emulation 8086
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 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 at 10:21
5
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 ;-).
â Stephen Kitt
Oct 4 at 11:57
1
See also What exactly is a cycle-accurate emulator?
â Stephen Kitt
Oct 4 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 at 12:26
 |Â
show 3 more comments
up vote
9
down vote
favorite
up vote
9
down vote
favorite
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.
emulation 8086
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.
emulation 8086
emulation 8086
edited Oct 4 at 14:06
pipe
1,196714
1,196714
asked Oct 4 at 4:29
multics
20116
20116
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 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 at 10:21
5
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 ;-).
â Stephen Kitt
Oct 4 at 11:57
1
See also What exactly is a cycle-accurate emulator?
â Stephen Kitt
Oct 4 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 at 12:26
 |Â
show 3 more comments
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 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 at 10:21
5
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 ;-).
â Stephen Kitt
Oct 4 at 11:57
1
See also What exactly is a cycle-accurate emulator?
â Stephen Kitt
Oct 4 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 at 12:26
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 at 8:12
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 at 8:12
1
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 at 10:21
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 at 10:21
5
5
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 ;-).â Stephen Kitt
Oct 4 at 11:57
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 ;-).â Stephen Kitt
Oct 4 at 11:57
1
1
See also What exactly is a cycle-accurate emulator?
â Stephen Kitt
Oct 4 at 12:07
See also What exactly is a cycle-accurate emulator?
â Stephen Kitt
Oct 4 at 12:07
2
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 at 12:26
@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 at 12:26
 |Â
show 3 more comments
4 Answers
4
active
oldest
votes
up vote
20
down vote
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!
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
0
down vote
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 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 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 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 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 at 14:15
 |Â
show 5 more comments
up vote
0
down vote
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.
New contributor
Welcome! You might find this presentation interesting, in relation to building real-time systems on Linux.
â Stephen Kitt
Oct 4 at 21:05
And I mentioned that I don't mind a bit of jitter.
â multics
Oct 5 at 3:43
And, to the best of my knowledge, Unix is (and was) also a preemptive multitasking system.
â multics
Oct 5 at 3:46
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
2 days ago
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
2 hours ago
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
20
down vote
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!
add a comment |Â
up vote
20
down vote
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!
add a comment |Â
up vote
20
down vote
up vote
20
down vote
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!
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!
edited Oct 4 at 7:45
answered Oct 4 at 6:21
Stephen Kitt
31.4k4126150
31.4k4126150
add a comment |Â
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
edited Oct 4 at 19:43
answered Oct 4 at 18:59
traal
7,53812563
7,53812563
add a comment |Â
add a comment |Â
up vote
0
down vote
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 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 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 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 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 at 14:15
 |Â
show 5 more comments
up vote
0
down vote
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 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 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 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 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 at 14:15
 |Â
show 5 more comments
up vote
0
down vote
up vote
0
down vote
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 :))
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 :))
answered Oct 4 at 5:20
Raffzahn
37.1k482149
37.1k482149
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 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 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 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 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 at 14:15
 |Â
show 5 more comments
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 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 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 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 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 at 14:15
1
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 at 9:49
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 at 9:49
4
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 at 10:28
@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 at 10:28
2
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 at 11:19
@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 at 11:19
1
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 at 11:31
@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 at 11:31
1
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 at 14:15
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 at 14:15
 |Â
show 5 more comments
up vote
0
down vote
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.
New contributor
Welcome! You might find this presentation interesting, in relation to building real-time systems on Linux.
â Stephen Kitt
Oct 4 at 21:05
And I mentioned that I don't mind a bit of jitter.
â multics
Oct 5 at 3:43
And, to the best of my knowledge, Unix is (and was) also a preemptive multitasking system.
â multics
Oct 5 at 3:46
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
2 days ago
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
2 hours ago
add a comment |Â
up vote
0
down vote
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.
New contributor
Welcome! You might find this presentation interesting, in relation to building real-time systems on Linux.
â Stephen Kitt
Oct 4 at 21:05
And I mentioned that I don't mind a bit of jitter.
â multics
Oct 5 at 3:43
And, to the best of my knowledge, Unix is (and was) also a preemptive multitasking system.
â multics
Oct 5 at 3:46
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
2 days ago
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
2 hours ago
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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.
New contributor
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.
New contributor
New contributor
answered Oct 4 at 19:48
John Lord
101
101
New contributor
New contributor
Welcome! You might find this presentation interesting, in relation to building real-time systems on Linux.
â Stephen Kitt
Oct 4 at 21:05
And I mentioned that I don't mind a bit of jitter.
â multics
Oct 5 at 3:43
And, to the best of my knowledge, Unix is (and was) also a preemptive multitasking system.
â multics
Oct 5 at 3:46
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
2 days ago
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
2 hours ago
add a comment |Â
Welcome! You might find this presentation interesting, in relation to building real-time systems on Linux.
â Stephen Kitt
Oct 4 at 21:05
And I mentioned that I don't mind a bit of jitter.
â multics
Oct 5 at 3:43
And, to the best of my knowledge, Unix is (and was) also a preemptive multitasking system.
â multics
Oct 5 at 3:46
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
2 days ago
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
2 hours ago
Welcome! You might find this presentation interesting, in relation to building real-time systems on Linux.
â Stephen Kitt
Oct 4 at 21:05
Welcome! You might find this presentation interesting, in relation to building real-time systems on Linux.
â Stephen Kitt
Oct 4 at 21:05
And I mentioned that I don't mind a bit of jitter.
â multics
Oct 5 at 3:43
And I mentioned that I don't mind a bit of jitter.
â multics
Oct 5 at 3:43
And, to the best of my knowledge, Unix is (and was) also a preemptive multitasking system.
â multics
Oct 5 at 3:46
And, to the best of my knowledge, Unix is (and was) also a preemptive multitasking system.
â multics
Oct 5 at 3:46
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
2 days ago
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
2 days ago
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
2 hours ago
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
2 hours ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7841%2fis-there-a-cycle-exact-8086-emulator%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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 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 at 10:21
5
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 ;-).â Stephen Kitt
Oct 4 at 11:57
1
See also What exactly is a cycle-accurate emulator?
â Stephen Kitt
Oct 4 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 at 12:26