8086 Emulator Download 9 0
Nico Sadiq
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.
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.
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.
We made an Intel 8086 Emulator in Rust. The commandline version is at : -Emulator. Then we compiled it to WASM and integrated with React to make a front-end only 8086 Emulator website. Repository is -Emulator-Web/. It is hosted on GitHub pages at : -emulator-web/.
Please check it out, and let us know how it is. If you think it is interesting, please start the repos ?
In my recent semester we had Microprocessors as a subject, and more than half of it was based on Intel 8086 microprocessor. Now usually when the labs for this were taken, one would probably use some kind of kits or such to write programs of 8086 instruction set x86 assembly, and test it out. But... as this time it was conducted online, we had to use something else. Now the emulator we were supposed to use , in my opinion , had some issues.
While searching for some other 8086 emulator to use, I came across -simulator/, which is a 8085 emulator. This seemed a really cool thing, made in Angular and using JS to run the assembly. (Check it out as well, it is quite cool!)
But other than that, I couldn't find a 8086 emulator.
I decided to make one ? ? I am interested in compilers, (check my c-to-assembly blog series here) and this seemed like a good place to actually use my interest in compilers,the microprocessors course I took, and Rust.
As I had seen the 8085 emulator, it seemed a pretty good idea to make mine also in web version, but I didn't want to write complete Lexer and parser part in JS. As I also wanted to make a commandline version as well, the best Option seemed to be making a core library in Rust and then make different interfaces for both version, compile Web version to WASM and integrate it with front-end. And (bad Rust pun ahead..) that turned to be Some(Emulator) ?
So, my friends and me went ahead, and made the core library, the 'drivers' (interfaces for both versions) and the React frontend, compiled Rust code to WASM, tries to integrate them, found bugs in code, fixed bugs in code ; Rinse and repeat few more times, and got ourselves an 8086 emulator ? ?
Both versions allow most of the instruction set of 8086 assembly, with exceptions of few instructions used to interface with external devices or so, and only allows selected few interrupts, as it does not store the instructions in memory which is required by Interrupt Service Routines. It gives complete 1 MB Memory to store data, and access to all registers which 8086 architecture has.
Commandline version has int 3 debugging support, and has instructions to print flags, registers and memory. It also has an interpreter mode, which gives a user prompt before executing each instruction, and can be used to run a program step by step.
Web version gives GUI access, which shows Registers, Flags and memory as well as provide an editor to write code. It provides auto run mode, which runs program by itself, and shows which line is being executed, along with updating Flags, registers and memory as it runs. It also has support to manually run instructions one by one. Annnnnd... it comes in Dark Mode ?️
So is it perfect? Nope! We are sure there might be some bugs in it, some issues that we haven't even thought of testing, and other things that we haven't thought of. And that's why its open source ! So check it out on GitHub :
So the current problem I have right now (which leads me to the question here) is that I have bugs in my instruction interpretation. I have not yet been able to boot a real OS for example.
This is of course not always that easy to track down so I have been thinking of ways to help with debug that.
Finally, UniPCemu supports importing instruction output in the common emulator format for verification(It'll dump information when a mismatch occurs). You'll just have to redirect the output from your emulator to UniPCemu's input(using simple piping) and have UniPCemu start it's verification using the "debuggerin"(unquoted) command line parameter(debuggerout does the opposite, dumping it's own debugger output to stdout instead of reading from stdin). Said read data(line endings automatically converted) from stdin is compared with it's own. If a mismatch occurs, ""(without quotes) is logged after any mismatching line not matching UniPCemu's logging.
Thanks for replying to this thread. I am going to integrate the 186 tests into my WIP emulator as well and use the example from your code for how they are supposed to be run. It's really too bad that the tests don't have a license... If anyone knows the license please let us know. Does anyone know the original source of them before they made their way onto this forum?
The 80186 tests by Artlav were helpful to me, but unfortunately (unless I'm mistaken in my interpretation of them) they make a lot of poor assumptions. For example some of them assume flag results for instructions that set some of their flags to undefined. Others assume exact memory locations when the tests have been modified over time and those locations no longer hold. I still have CPU bugs and I am still looking for good 8086 CPU tests that can be loaded in place of a BIOS or run completely independently. To see how I'm using the Artlav CPU tests, you can find the tests in my repository here:
Otherwise, if you can create command line output in the common log format, you can compare to UniPCemu at least, which should be able to find more bugs where present(using piping between the programs).
The current commit of UniPCemu has a little 32-bit instruction(RCR) bugfix which isn't in a released version yet, but that shouldn't be a problem with the 16-bit/8-bit instructions, which should be working properly in UniPCemu afaik.
Perhaps try looking at Bochs handling of flags calculation for math instructions (add, sub etc.)? That was the way I finally managed to get it working in UniPCemu. Look at flags.c in UniPCemu's source code for that. Although it's not using lazy flags (which don't seem to cause big improvements in interpreting emulation anyways. They don't even show up in profiling results).
Yea, the 186 tests got me to a point where FreeDOS runs (seemingly flawless). So does most games that I have tested.
But I can still not boot any version of MS-DOS or Windows 3.0 yet. So there are obviously still issues with my emulator.
The early versions (v2?) of MS-DOS tried to read system files in a single run, whereas later versions couldn't do that anymore because the system was too large to fit a cluster.
The Japanese versions (DOS/V) did some pretty weird stuff, too.
i'm trying to display the result of multiplying two numbers on the emulator screen of emu8086, when i use small 8 bits numbers, the result is printed fine when i run the code, but with 16bits numbers i get 0 on the emulator screen, i'm not sure it something is wrong with my code or the emulator it self, i'm totally new to assembly, and i've been trying to solve it for the past hour, that's my code
Note that 512*512=262144=40000h, which is a 32 bit number with the low 16 bits being zero and that's presumably what you get printed. This form of the mul instruction puts the top 16 bits of the result into register dx, you should find 4 there. If you want to print the whole result, you will of course need a 32 bit printing function, and you'll have to pass the arguments properly.
If you like living on the edge you can try building the emulator on a big endian machine, and you will get an emulation of a big endian 8086, a rather bizarre and somewhat useless beast. For everyone else, please run the emulator on a little endian machine.
The download has been tested by an editor here on a PC and a list of features has been compiled; see below. We've also created some screenshots of Emu8086 to illustrate the user interface and show the overall usage and features of this microprocessor emulation program.
Emu8086 is a Microprocessor Emulator with an integrated 8086 Assembler and Free Tutorial. Emulator runs programs on a Virtual Machine, it emulates real hardware, such as screen, memory and input/output devices.
The attached example emulates a very simple system with 256KB RAM, 64KB ROM and an ACIA-ish serial port hooked to the programming serial pins running at 115_200 bps. The monitor source is slightly modified from the original to accomodate for the different system configurations and can be compiled with nasm.
Cool project.
It compiles and downloads fine.
But unfortunately all I get is gibberish when I try to run it, like the serial isn't sync'ing.
I started with 115200, no parity, one stop bit.
I've tried the latest versions of PropTool, PNut and flexprop.
I've tried various baud rates from 9600 to 460800.
I've tried various parities and stop bit combinations.
I've both the Parallax Serial Terminal and TeraTerm.
The gibberish changes with changes to baud, parities and stop bits, but I never get good old readable ASCII.
I've tried changing the P2 clock frequency from 150 to 200 MHz. I don't get any response from the program below 150 or greater than 170 MHz.
Any thoughts? I'm using a P2 Edge Rev. C on a mini breakout using the latest prop-plug(rev. D), which has been working fine with everything else I've thrown at it...