Hi everyone,
It has been a little while since I have been this way. Sometimes my real job gets in the way.
Anyway, after a few posts recently about emulating an x86 instead of using virtual real-mode, I made a few notes and thought that it would be an interesting idea.
After doing a few other things, I took it a bit further and emulated a whole 32-bit (un)real mode machine. (16-bit real mode 80x386 machine. No protection.)
It is 100% emulated. All emulation is written from scratch using C/C++ and compiles and runs at 64-bit or 32-bit.
It still needs a lot of work, but the current emulation is enough to execute the BIOS from Bochs, both the Legacy BIOS and the VGA ROM BIOS, as shown in the screen shot above.
It should be pretty close to turning control over to the first sector of the emulated disk. However, I haven't written the emulated FDC yet, so the interrupt service routine will fail.
Also, looking at the displayed text in the screen shot, since the VGA BIOS is licensed for Bochs, I guess I get to find a different VGA BIOS to use. Either that, or find an older machine and read 32k from 0xC0000.
Anyway, it wasn't as difficult as one might think. My OS already had a disassembler that put the instructions into tokens. All I had to do was call this disassembler to disassemble a line at a time. Then take the tokens and manipulate the emulated system.
It has a somewhat working VGA adapter--obviously, due to the screen's display.
It has a mock-up minimalist DMA controller, keyboard controller, two parallel ports, four serial ports, a non-working PIC (currently mocked-up to use), a non-working PIT (again, simply mocked-up so stuff works), and misc other items.
It needs the PIC emulation written so that I can send keys to the system, the DMA so the floppy will work, and a few other things. The interesting thing is that the system would fail and I didn't know why. After looking over the code, it came down to a simple error in the eflags register emulation. Not setting the Carry flag correctly after a SUB instruction. It happened more than once. :-)
It has been an interesting project though. Also, another interesting thing is that I am using an emulator (QEMU) to emulate my OS which in turn is emulating another x86 machine. :-)
One last thing is that I spotted a bug in my task scheduler that I haven't been able to pin-point where it is yet. The scheduler is modifying the stack approximately 32-bytes above the current stack location. This in-turn modifies a parameter used by the task that got interrupted by the scheduler, so when this task regains control, it sometimes crashing the whole (emulated) system due to a parameter now being destroyed. Something I need to further investigate.
Update: My emulator now runs DOS 5.0a:
http://www.fysnet.net/blog/2021/01/Anyway, Happy New Year to you all,
Ben
-
http://www.fysnet.net/fysos.htm