8086 Emulator Download No Registration ((NEW))

I worked for a small aerospace company in 1989 that based its satellite flight computer on a CMOS 8086 made my Harris. For power reasons, the CPU spent a lot of its time running at 256 kHz, with the clock bumped up to full speed (I forget the rate now) when it was time to do some real work. There were only two CPU emulators that supported that clock - one made by Zax (it was terrible) and the other by SoftAid, which was by far the best one I've ever worked with.

8086 emulator download no registration

Sad news that V86 mode is on the way out. I remember the excitement of getting MS-DOS (or FreeDOS) running under dosemu on Linux, with almost the full native CPU speed available to the DOS virtual machine. More so if you then enabled direct video access in the dosemu config, so that DOS games would work, at the risk of crashing the machine if you configured it wrong...But nowadays CPUs are so much faster than they were even in the last days of DOS (mid 1990s or so) that you can use a software emulator such as Bochs and it's easily fast enough. Also, V86 mode is not accessible from 64-bit mode on x86_64 processors anyway.- What about Wine running 16-bit Windows applications? Does that use V86 mode? The old 'real mode' (8086) Windows applications (like winword 1.x) are impossibly ancient but I wouldn't be surprised to see some 'standard mode' (80286) programs still in use in the corporate world. They won't run on 64-bit Windows but I think 32-bit Windows still supports them. (Log in to post comments) CONFIG_VM86 Posted Sep 3, 2015 16:54 UTC (Thu) by drv (subscriber, #78370) [Link]

This is a C-compiler for 8086 cpus which is important for the development of boot loaders or BIOS related 8086 code. . It is possible to run 8086 code under i386 Linux using an emulator, `elksemu', also included in this package.

Abstract:LinuxBIOS is fast becoming a widely accepted alternative to the traditional PC BIOS for cluster computing applications. However, in the process it is gaining attention from developers of Internet appliance, desktop and visualization applications, who also wish to take advantage of the features provided by LinuxBIOS, such as minimizing user interaction, increasing system reliability, and faster boot times. Unlike cluster computing, these applications tend to rely heavily on graphical user interfaces, so it is important that the VGA hardware is correctly initialized early in the boot process in additional to the hardware initialization currently performed by LinuxBIOS. Unfortunately, the open-source nature of LinuxBIOS means that many graphic card vendors are reluctant to expose code relating to the initialization of their hardware in the fear that this might allow competitors access to proprietary chipset information. As a consequence, in many cases the only way to initialize the VGA hardware is to use the vendor provided, proprietary, VGA BIOS. To achieve this it is necessary to provide a compatibility layer that operates between the VGA BIOS and LinuxBIOS in order to simulate the environment that the VGA BIOS assumes is available. In this paper we present our preliminary results on FreeVGA, an x86 emulator based on x86emu thatcan be used as such a compatibility layer. We will show how we have successfully used FreeVGA to initialize VGA cards from both ATI and Nvidia on a Tyan S2885 platform.1 IntroductionLinuxBIOS [9] is an open-source replacement for the traditionalPC BIOS.The PC BIOS was developed in the 1980's for the original IBM PC, and much of the functionality needed to support this legacy hardware still remains in the PC BIOS today. In addition, the vintage operating systems that ran on thesemachines were dependent on the BIOS for carrying out many of the configurationactivities needed for the system to function properly. Modern operating systems are now able to initialize and configure hardware directly, sothere is no longer any reason for the BIOS to be involved. The basic principle behind a modern BIOS, like LinuxBIOS, is to do the minimum necessary to enable system hardware, then leave as much device configuration to the operating system as it can. The result of eliminating this unnecessary initialization is a very fast boot time compared to a traditional BIOS.Another legacy feature provided by the PC BIOS is a 16-bit callback interface using the x86 software interrupt mechanism. However, only a tiny subset of the interface is used by modern operating systems, and in the case of Linux,it is not used at all. LinuxBIOS does not provide this interface, and asa result, is able to substantially reduce its memory footprint. Compared to 256KB required by the PC BIOS, the typical size of LinuxBIOS is just 32KB to 64KB. This is important because of the small size of FLASH memory in manysystems.Unlike the PC BIOS, only a very small portion of LinuxBIOS is written in assembly code. For the x86 architecture, this is just enough code to initialize the CPU and switch to 32-bit mode. The rest of LinuxBIOS is written in the C language. This makes LinuxBIOS very portableacross different architectures, and it has already been ported to supportthe Alpha and PowerPC processors.Using a high-level language also allows LinuxBIOS to employ a much more sophisticated object oriented device model, similar to the one used in the Linux kernel. In such a model, each physical device has a corresponding software object. The object encapsulates information about the physical device and has methods to probe, initialize and configure the device. The main function of LinuxBIOS is reallyjust to organize, query and manage these device objects. This kind of device object model is unheard of in a BIOS implemented in assembly code.LinuxBIOS has been successfully deployed in a number of real world applications. At Los Alamos National Laboratory, we have Pink andLightning [11], two very large production cluster systems that use LinuxBIOS. There are also a number of companies shipping commercial LinuxBIOS-based systems. The advantages of LinuxBIOS have alsodrawn attention from Internet appliance, desktop, and visualization platformdevelopers. These applications have created a demand for video graphics adapter (VGA) card [7] support under LinuxBIOS. In order to useLinuxBIOS, systems running these applications need to be able to initialize a widevariety of VGA cards. However, LinuxBIOS does not have this capability becauseit does not provide the 16-bit callback interface mentioned earlier.Traditionally, a VGA card is initialized by software known as the VGA BIOS,which is considered an extension of system BIOS. It is loaded by thesystem BIOS from an expansion ROM located on the VGA card into a specific address in system memory. Control is then transfered to the VGA BIOS, and it uses the 16-bit callback interface to communicate with the system BIOS. SinceLinuxBIOS does not provide this interface, a non-traditional way toinitialize the VGA device in a LinuxBIOS environment is required. Inorder to achieve this, we have developed a system known as FreeVGA. FreeVGAuses an x86 emulator to run the VGA BIOS. By using an emulator, we freethe VGA initialization from any architecture dependencies, since theemulator can operate on any type of processor. In addition, the emulatorgreatly simplifies the implementation of the 16-bit callback interface.To demonstrate the effectiveness of this technique, we have used FreeVGA toinitialize two VGA cards, an Nvidia FX 5600 and an ATI Radeon 9800 Pro,running on a Tyan S2885 mainboard. Both video cards and the mainboardare state-of-the-art, so we can be confident that FreeVGA will workfor virtually all mainboard/video card combinations.The rest of this paper is organized as follows. Section 2 describes previouswork on supporting the initialization of VGA cards with VGA BIOS innon-traditional ways. Section 3 presents how we used an x86 emulator toexecute the VGA BIOS and the necessary modification to the emulator andLinuxBIOS itself. We also examine some of the issues that need to be dealtwith in order to support this technique. Section 4 shows how we found outthe issues described in Section 3 and the strategy we used to overcome theseproblems. Finally, Section 5 is a roadmap of our future development.2 Related WorkInitializing VGA cards in a non-traditional way (i.e. not using the standardVGA BIOS in the normal manner) is not a new problem, and various other opensource projects have addressed it in the past. There are a number of reasonswhy VGA cards need to be initialized in this manner.Due to the limitation of the traditional initialization process and legacy VGA hardware, only one VGA device can be initialized in a given system. For systems with multiple VGA cards, only the first one is initialized at boot time, other cards have to be soft-booted after the operatingsystem is loaded.Some VGA hardware is fragile, so that a slight error in programming the registers will put the hardware in a non-functional state. A complete re-initialization is then required to bring the hardware back to normal.Normally, the only way to do such a re-initialization is to re-execute the initialization code in the VGA BIOS. Of course it is always possible to reset the whole system as a last resort, but usually this is not an option.In these cases it must be possible to reset just the VGA device while other parts of the system are still running. Other open source projects that have addressed the need to initialize VGA cards are described in the following sections.2.1 SVGALibSVGALib [2] is a library that provides a generic VGA interfacefor older VGA cards. It includes a utility called vga_reset to re-initializeVGA cards. The utility uses the vm86 mode of x86 processors to execute the VGA BIOS. In vm86 mode, an executing program is just like any otherprogram executing in 32-bit mode, but it executes 16-bit code like a traditional 8086 CPU. To support this, Linux provides a system call to switch a process into vm86 mode. vga_reset first maps in the BIOS code and data area from physical memory space to its virtual memory space.Then it sets up register values for instruction and stack pointers.Finally, it enters vm86 mode by calling the vm86 system call.By default, both VGA BIOS and system BIOS callbacks are executednatively by the hardware, except some privileged instructions andI/O operations.By giving different flags when entering the vm86 mode, it is possible to chooseto intercept I/O and BIOS calls. This feature was used frequently in the earlystage of the development of our solution as a debugging and verification tool.The I/O and BIOS call logs from vga_reset and x86emu were comparedto examine if both vga_reset and x86emu had the same code execution path in the same hardware environment. If they both had the same execution path, it indicated that the emulator executes the VGA BIOS exactly as the real hardware.The disadvantage of vga_reset is that the vm86 mode is not supportedby the AMD x86_64 architecture. The 64-bit Linux kernel does not provide the vm86 system call. During our development, we had to install a 32-bit Linuxdistribution on our 64-bit AMD K8 platform to run vga_reset.2.2 ADLOADLO [5] was the original effort to add VGA BIOS support intoLinuxBIOS.ADLO uses the BOCH BIOS to replace the traditional system BIOS. It loads the BOCH BIOS and VGA BIOS into the memory addresses where the traditional systemand VGA BIOS are loaded. ADLO then switches the processor back to 16-bitmode and jumps to the entry point of the BOCH BIOS. The BOCH BIOS tries todo the same initialization process and to provide the same BIOS callbacks asa traditional BIOS. The net effect of this BOCH+VGA BIOS combination is likea software reboot in a traditional BIOS system. One of the advantages ofALDO is that it can support legacy operating systems like Window 2000.The problem of ADLO is that it depends on the BOCH BIOS, which isvery difficult to maintain and modify. Even adding a message printingstatement in the BOCH BIOS will make it fail to build.2.3 VIA/EPIA PortAnother effort to use VGA BIOS to initialize VGA hardware is the VIA/EPIA port of LinuxBIOS. The port uses a trampoline to switch back and forth between the 16-bit and 32-bit modes of x86 processors. This allows the VGABIOS to be executed directly in 16-bit mode but standard BIOS callbacks to beemulated in 32-bit mode in the C language.Before executing the VGA BIOS, a 16-bit interrupt descriptor table (IDT) isset up to redirect all interrupt calls to the trampoline.The BIOS then switches to 16-bit mode and jumps to the entry point of VGA BIOS.When the VGA BIOS calls the standard BIOS callbacks, the trampoline switchesto 32-bit mode, and dispatches the call to the BIOS emulation code.After the emulation code returns, the trampoline switches back to 16-bit modeand returns to VGA BIOS. The main limitation with this approach is that itis highly architecture specific, so can't be used for non-x86 based architectures. The other disadvantage of this method is that because the trampoline is inside LinuxBIOS, it is more difficult to debug than a user space program like x86emu.2.4 XFree86The XFree86 project [4] has to solve this problem in order tosupport multiple-card, multiple-screen configurations. Since XFree86 supportsmultiple architectures,the solution must be able to initialize VGA hardware not only on x86 systems,but also on other architectures like Alpha and PowerPC. To achieve this, XFree86 uses x86emu emulator to execute the VGA BIOS directly.X86emu is an x86 instruction emulator which does not emulate any hardware other than the core x86 processor in 16-bit mode. The emulator provides helper function stubs to access I/O and memory spaces. XFree86 implements thesehelper functions in architecture dependent ways. XFree86 first unmapsthe primary VGA card from physical I/O and memory spaces by programming wellknown legacy I/O ports or registers in the PCI configuration space. Then itmaps in the I/O and memory spaces of the secondary card, loads the VGA BIOSimage of the card into the virtual memory space of the emulator.The emulator then executes the VGA BIOS starting from the entry point. Becausemost VGA BIOSes also require traditional BIOS callbacks which are notavailable in non-x86 systems and not usable in 32-bit x86 systems, theemulator also has to intercept these BIOS calls and then emulate them in a similar way as I/O and memory accesses. 2.4.0.1 In a summary, each of these previous efforts was found to have deficiencies.Both SVGALib and VIA/EPIA are non-portable, so are not suitable forintegration in LinuxBIOS. SVGALib, ADLO and VIA/EPIA were found to be verydifficult to debug, which is a major problem for a complex system likeLinuxBIOS. XFree86 initializes the VGA hardware very late, which doesnot meet our design goals. These problems motivatedus to seek a solution which was able to address all these issues, while takingadvantage of the experience gained by the previous research.The concept and advantages of using an emulator to execute the VGABIOS in order to initialize VGA hardware are obvious. The solution is portable across different platforms, and it is flexible enough to monitor I/O and memory accesses and BIOS callbacks. The ability to monitor theseaccesses is very useful for debugging purposes. As a consequence, thesolution we have chosen for FreeVGA is based on a modified version of x86emu.3 VGA EmulationMost modern VGA cards support two modes of operation: legacy mode and native mode. In legacy mode the card replicates the graphics hardware interface that was used on the original IBM PC/AT. The legacy mode is primarily used to provide a compatibility mode so that applications and drivers have a common programming interface. In native mode, the card provides access to avendor specific register interface that is used to configure and controlthe card. Most VGA cards require an elaborate programming sequence to initialize the VGA hardware and turn it to legacy mode. If LinuxBIOSwas to support direct initialization of the card, it would needto use a device driver that provided this programming sequence.Unfortunately, most vendors worry that even exposing the interface totheir proprietary hardware will allow their competitors to plunder theirintellectual property; hence they do not reveal the sequence of registerdiddles necessary to initialize their cards.Linux uses a frame buffer device as an abstraction of graphics hardware. Applications interact with frame buffer device interface (/dev/fb)instead of directly accessing the hardware. At a minimum, the frame buffer device driver provides support to switch video modes and some basic drawing functionality. Some vendors like Matrox provide a sophisticated frame buffer device driver which can initialize the hardware from the power-up state to any video mode available by the hardware. Our original intentionwas to persuade vendors to provide these sophisticated drivers so thatthey could be used by LinuxBIOS. However many of the vendors who provide enough information to implement a minimal frame buffer device driver hesitate to provide the additional information necessary for a such a driver.As a result, the only way to reliably initialize the hardware from power-up ina vendor-neutral manner is to run the vendor supplied VGA BIOS. Once the VGABIOS has been run, the card will switch to legacy mode and it can be controlledusing the legacy interface from then on. Depending on the implementation of the VGA BIOS, the 16-bit BIOS callback interface may be used to communicate with the system BIOS. Since LinuxBIOS lacks this callback interface, it can not support VGA BIOS directly in the same way as the traditional system BIOS. We have to either add the 16-bit callback interface to LinuxBIOS or use another software to provide this interface. The use of an emulator solves this problem by allowing the emulator to run in 32-bit mode to execute the 16-bit mode VGA BIOS and then implement the callback interfaces as necessary.3.1 x86emuThe emulator we used to enable VGA support in LinuxBIOS was based on amodified version of x86emu.The x86emu emulator was originally developed by SciTech Software[1] as part of their SciTech SNAP SDK.The XFree86 project adopted the emulator for soft-booting VGA cards intheir X-server. We used the XFree86's version rather than the SciTech'sversion because it is more updated and debugged.The virtual machine of the emulator is implemented by a data structurerepresenting all the integer and floating point registers in an x86 CPU.The emulator decodes and jumps to an entry of a function table based onthe first op code of each instruction.The functions in the function table update the virtual machine with theoutcome of the execution of the instruction.The emulator uses helper functions provided by client applications tocommunicate to the real world, for instance, accessing I/O and memory spaces.The emulator allows interrupt handling using either an interrupt handlerprovided by the client application or an interrupt handler in the BIOS.3.1.0.1 IO and Memory AccessThe client application provides a set of functions for accessing I/O portsand another set of functions for accessing memory addresses. The structuresused to define the functions are shown below:typedef struct u8 (inb)(int addr); u16 (inw)(int addr); u32 (inl)(int addr); void (outb)(int addr, u8 val); void (outw)(int addr, u16 val); void (outl)(int addr, u32 val); X86EMU_pioFuncs;typedef struct u8 (rdb)(u32 addr); u16 (rdw)(u32 addr); u32 (rdl)(u32 addr); void (wrb)(u32 addr, u8 val); void (wrw)(u32 addr, u16 val); void (wrl)(u32 addr, u32 val); X86EMU_memFuncs;These two sets of functions are installed into the emulator viaX86EMU_setupPioFuncs() and X86EMU_setupMemFuncs()respectively.Since we are working on an x86 platform, the implementation of the I/O accessfunctions is just a thin wrap