Page 1 of 1

DOS subsystem

Posted: Fri May 20, 2005 4:59 am
by SANiK
Well, I am working with a couple of buds on an OS called Halfix, the 4.5 nanocore.

Well, since 64-bit mode doesn't allow use of the BIOS, we started implementing a method that emulates the x86 16 bit.

Here's the buggy source, but it may not be of any use now:
(The reason it's buggy is due to an incorrent opcode table I had foolishly relied on)

Although, this core is an interpreter based core. To allow for speed, I am planning to rewrite the core so it uses look up charts instead of emulating the CPUs registers and flags. So the idea would be to convert/translate 16 bit opcodes to 32 bit ones and then have the CPU execute them.
Hence, allowing blazingly fast speeds for running DOS programs.

Conversion factors:
  • Prefixes need to be changed to 32-bit. (0x66 would be removed when going from 16 bit to 32 bit, vice versa it would be added. Same for 0x67)
  • The segment registers are not available. So one needs to filter prefixes, and apply the change in the regenerated mode-rm byte.
  • The mode-rm byte has 256 possible combinations which could neatly fit into a conversion array.
The question is not how to emulate the x86, but instead how to translate the opcodes.

One could even take the idea further and cut the program being translated into sections. When a section has been translated, it could be saved and reused again until that section has been changed.

Posted: Sun May 22, 2005 11:37 pm
by Delfi
but why couldn't reactos just bundle dosbox for much better compatibility also with games?

Posted: Mon May 23, 2005 9:22 am
by rastilin
Rather than doing the work ourselves, it would be better to depend upon an application that is already proven to be reliable.

Posted: Mon May 23, 2005 12:20 pm
by Harteex
I'd rather see a nice native support for DOS instead of using an emulator...

So this could be a nice beginning :)

Posted: Tue May 24, 2005 10:31 am
by Phalanx
Dosbox is an emulator, so it does not allow the applications to interact with all the rest.

Posted: Tue May 24, 2005 5:24 pm
by Dr. Fred
Phalanx wrote:Dosbox is an emulator, so it does not allow the applications to interact with all the rest.
Is that good or bad in your mind ?

Posted: Thu May 26, 2005 10:19 pm
by SANiK
Yes emulators are slow, but Virtual 86 mode is not there on 64-bit machines.
What are you going to do? Keep switching to Rmode on/off when it's needed?

In Halfix, what we are currently attempting is to make a "software based virtual 86 mode." That means, interrupts can be executed in 32 bit mode using translation. No need for VM86 mode or Rmode switching. Heck, one can take it farther and execute entire programs! The above code was tested (but it's still interpreter based and was used as a testing ground) and it can be used to enter VESA using the interrupt. (I should say again that the code is buggy).

As for the DOSBox option.
DOSBox is great and all, but the emulator is interpreter based.
That means that for mostly every opcode there needs to be flags generated. Do you know how slow that is? By making a core that translates 16bit to 32bit, speed is gained significantly!

Posted: Fri May 27, 2005 1:53 am
by etko
16 to 32 bit translation seems interesting but it is possible? Why not all 16 bit programs are not translated to 32 bit that way today? How are you going to translate segment:ofsset far call pairs and segment:offset far data access into linear adress space? Are you going to convert them directly to 1MB adress? And what about program functions which accept only segment as parameter, I think that it's impossible to catch that...

Posted: Mon May 30, 2005 3:14 am
by SANiK
You are misunderstanding something. Translating 16bit to 32bit is not done once, but after every JMP instruction.

Think of it as an emulator that reads in instructions, converts them, and then executes them when a jmp instruction has been reached or when a ret instruction has been reached. Then it starts all over again.