OSDev.org

Octocontrabass wrote:

awik wrote:I am wondering why ...

No reason. Neither one follows the Intel requirements (you must put the far JMP or far CALL immediately after the instruction that changes CR0.PE, with no other instructions between) so there is no guarantee that either will work.

Intel's sample code does only a short/near jump to clear the prefetch queue (lines 175-182).

Anyway, if there is anything I've confirmed and learned repeatedly during these efforts, it's that RETF is just fine, and I'm going to stay with it.

awik wrote:Apparently the attributes of a protected mode segment in VMware are "sticky": they won't go away even after a return to real-mode and reloading the segment register with a real mode value.

This is true of bare metal as well, and the Intel manual says as much in the section about returning to real mode.

That (the metal part) decides it. As a matter of fact, I prefer this behaviour, because it means that you can call DOS with "big" segment limits and have them stay in effect. As for the documentation, Intel could have emphasised this a bit more. Many parts of their manuals seem to imply that real mode segments always have a 0xFFFF limit.

-Albert.

awik wrote:Intel's sample code does only a short/near jump to clear the prefetch queue (lines 175-182).

Intel's sample code hasn't been updated since 1992. I'm sure it works fine on a 386 or 486, but you need a far JMP if you want it to work on newer CPUs.

awik wrote:That (the metal part) decides it. As a matter of fact, I prefer this behaviour, because it means that you can call DOS with "big" segment limits and have them stay in effect.

Microsoft calls it "big real mode" in the HIMEM.SYS source code, but most other sources refer to it as "unreal mode".

Other segment attributes may also stay in effect across mode switches, but unlike limits, you can't count on that behavior being consistent across hardware or emulators.

awik wrote:As for the documentation, Intel could have emphasised this a bit more. Many parts of their manuals seem to imply that real mode segments always have a 0xFFFF limit.

Intel doesn't want you to know about it. There's some evidence that the original 386 design wasn't supposed to allow returning to real mode, much like the 286, and someone (likely from Microsoft or Compaq) pressured Intel into changing it at the last minute. It would explain why the microcode-heavy 386 lacks any mechanism to enforce real-mode segment behavior when returning to real mode, and why Intel's documentation avoids explaining exactly what's going on.

awik wrote:Apparently the attributes of a protected mode segment in VMware are "sticky": they won't go away even after a return to real-mode and reloading the segment register with a real mode value.

Well, what wasn't clear in the manual?

intel wrote: 4. Load segment registers SS, DS, ES, FS, and GS with a selector for a descriptor
containing the following values, which are appropriate for real-address mode:
— Limit = 64 KBytes (0FFFFH)
— Byte granular (G = 0)
— Expand up (E = 0)
— Writable (W = 1)
— Present (P = 1)
— Base = any value
The segment registers must be loaded with non-null segment selectors or the
segment registers will be unusable in real-address mode. Note that if the
segment registers are not reloaded, execution continues using the descriptor
attributes loaded during protected mode.

alexfru wrote:

awik wrote:Apparently the attributes of a protected mode segment in VMware are "sticky": they won't go away even after a return to real-mode and reloading the segment register with a real mode value.

Well, what wasn't clear in the manual?

intel wrote: 4. Load segment registers SS, DS, ES, FS, and GS with a selector for a descriptor
containing the following values, which are appropriate for real-address mode:
— Limit = 64 KBytes (0FFFFH)
— Byte granular (G = 0)
— Expand up (E = 0)
— Writable (W = 1)
— Present (P = 1)
— Base = any value
The segment registers must be loaded with non-null segment selectors or the
segment registers will be unusable in real-address mode. Note that if the
segment registers are not reloaded, execution continues using the descriptor
attributes loaded during protected mode.

The main problem with it, is that I did not find (or remember or understand) that passage until *after* I needed it. It is not apparent from the rest of the manual (in fact, almost on the contrary), even in places where it would be relevant to mention. I was also confused by the statements that the *base* of a real mode segment *is* reset when you load a segment register -- I thought the same happened with the limit.

-Albert.

awik wrote:

intel wrote: ...

The main problem with it, is that I did not find (or remember or understand) that passage until *after* I needed it. It is not apparent from the rest of the manual (in fact, almost on the contrary), even in places where it would be relevant to mention. I was also confused by the statements that the *base* of a real mode segment *is* reset when you load a segment register -- I thought the same happened with the limit.

Got it, yes, it happens. The manual is not a particularly easy read. You often need to go through many of mentions of something in it in order to get the picture. And then come back to some of them and reread them.

Hi all,

I've come a long way since I last posted. I have in fact reached one of the original goals, which was to enter V86 mode. For anyone who is interested, here is the latest revision:
v86.zip

Currently, I'm trying to figure out how, inside my V86 monitor, to do an INT 21h call on behalf of (in the context of) the interrupted task (the task that generated the GPF/INT 0Dh).

Another question that has come up, is whether figure 16-4 of the Intel system programmer's manual applies only to V86 mode or to regular protected mode (with privilege level transition) as well? If you can't find this figure, basically, it illustrates the stack layout at the point where an interrupt/exception handler has been called. It shows that the interrupted task's segment registers are all saved on the interrupt/exception handler's stack.

Cheers,
Albert.

Currently, I'm trying to figure out how, inside my V86 monitor, to do an INT 21h call on behalf of (in the context of) the interrupted task (the task that generated the GPF/INT 0Dh).

Are you writing a DOS emulator or just running DOS inside V86 mode?

Another question that has come up, is whether figure 16-4 of the Intel system programmer's manual applies only to V86 mode or to regular protected mode (with privilege level transition) as well?

No, DS, ES, FS and GS are only present when entering or leaving V86 mode.

Gigasoft wrote:

Currently, I'm trying to figure out how, inside my V86 monitor, to do an INT 21h call on behalf of (in the context of) the interrupted task (the task that generated the GPF/INT 0Dh).

Are you writing a DOS emulator or just running DOS inside V86 mode?

The latter. I don't know if it is realistic, but the ideal is to implement a DOS multitasker loosely based on the VxD layer (ie. kernel mode) of Win3.x/9x. I have little interest in writing a clone of the Win16/32/64 API, but possibly a platform upon which such a project (by someone else) could be based.

Another question that has come up, is whether figure 16-4 of the Intel system programmer's manual applies only to V86 mode or to regular protected mode (with privilege level transition) as well?

No, DS, ES, FS and GS are only present when entering or leaving V86 mode.

Thanks.

-Albert.

I've had a lot of success with this project lately.

I can now return to DOS while in V86 mode, and even run real-mode programs successfully. This is despite that my V86 monitor is very simple. Basically, it just handles INT xx and IN/OUT. On the other hand, the VM runs with IOPL=3 and a clear I/O bitmap (meaning allowed without generating a fault) for ports 0-4096.

Obviously, protected mode programs cannot run properly, because the machine is already in protected mode, and I haven't implemented DPMI or VCPI.

The NASM assembly language source code is 1347 lines, and the binary .COM file is 3184 bytes. I don't know if that is compact or not for a program of this nature. Alex's TUT15 .EXE is about 15K, but that is not a fair comparison because it is written largely in C language.

The source and binary are available at:
https://drive.google.com/file/d/1utPCWh ... sp=sharing

Cheerio,
Albert.

Hi all,

I'm trying to modify my program to use only one TSS, and trying to enter V86 mode through setting up the stack for an IRETD.

I'm getting an 0Ah (Invalid TSS) exception at the point of the IRETD. Does anyone see an obvious error with the following code?
Regards,
Albert.

OK, never mind, I solved it.

You need to clear the NT flag before trying to IRETD. On the other hand, it does not matter whether the NT flag is set in the EFLAGS image on the stack.

-Albert.