Re: 8086 Emulator Download 4 5
Kathryn Garivay
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 :
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.
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.
Adrian Cable's 8086tiny: a tiny PC emulator/virtual machine is another system for emulating 8086 systems. It is much smaller than any of the other systems: in its original (IOCCC-winning) form its source was only 4043 bytes (8086 nibbles) long.
You need to be more clear about what you intend to run. There is x86 assembly and then there are all the system calls int 10h int 21h, etc which are not related to assembly but to an operating system. If you are interested in the instruction set I have stripped down pcemu to avoid the confusion of an underlying operating system or bios, leaving just the assembly (for educational purposes).
You can easily try bochs or dosbox on ubuntu, just apt-get one or the other or both if you just want to run some old x86 dos programs that wont run in qemu or virtualbox/vmware (because they dont emulate dos).
Hi, all. I've been writing an 8086 (actually 80186) PC emulator for the Arduino Due. You can interface with it via VNC using a Wiznet 5x00 Ethernet module/shield. I'm working on making it function on a Mega2560 as well, but that's not working quite right yet. Will update if I get that going.
Here's an overview of how it works. It emulates an old 1980's PC's 640 KB of memory space with a mix of a byte array of 80 KB in native SRAM, and uses SPI RAM for the rest. I have an 8 KB generic XT BIOS embedded in the program.
There is a CPU emulation engine which steps through the memory the same way a real 8086 does, interpreting and executing x86 machine instructions how the original CPU does, but with equivalent C code and variables simulating the hardware logic and registers.
7fc3f7cf58