OSDev.org

I'm building an OS and i want it to boot into V86-mode.
Is it only the PE-bit that i would have to set or
also VME-bit or VM-flag.
Tell me all about it plz!

plz in ASM!

plz in ASM!

plz in ASM!

>On 2002-01-22 14:38:31, _the_crow_ wrote:
>I'm building an OS and i want it to boot into V86-mode.
>Is it only the PE-bit that i would have to set or
>also VME-bit or VM-flag.
>Tell me all about it plz!

Hmmmn, not an easy task. Correct me if I'm wrong, but AFAIK v86 mode only exists in user state under p-mode. You'd have to fully set up protected mode first, then fork a user level task, and set *that* into v86. There's no kernel state for v86; your kernel would have to be in p-mode, and trap the v86 interrupts.

Why do you want to automatically go into v86 mode, anyway? What is your intended design?

>On 2002-01-23 02:10:43, Schol-R-LEA wrote:
>>On 2002-01-22 14:38:31, _the_crow_ wrote:
>>I'm building an OS and i want it to boot into V86-mode.
>>Is it only the PE-bit that i would have to set or
>>also VME-bit or VM-flag.
>>Tell me all about it plz!
>
>Hmmmn, not an easy task. Correct me if I'm wrong, but AFAIK v86 mode only exists in user state under p-mode. You'd have to fully set up protected mode first, then fork a user level task, and set *that* into v86. There's no kernel state for v86; your kernel would have to be in p-mode, and trap the v86 interrupts.
>
>Why do you want to automatically go into v86 mode, anyway? What is your intended design?


You are very correct in your understanding...
I have been successful in entering protected mode..
The reason that I want to enter V86 mode, is to
be able to use bios!

>On 2002-01-23 04:44:16, chatamballi wrote:
>
>
>>On 2002-01-23 02:10:43, Schol-R-LEA wrote:
>>>On 2002-01-22 14:38:31, _the_crow_ wrote:
>>>I'm building an OS and i want it to boot into V86-mode.
>>>Is it only the PE-bit that i would have to set or
>>>also VME-bit or VM-flag.
>>>Tell me all about it plz!
>>
>>Hmmmn, not an easy task. Correct me if I'm wrong, but AFAIK v86 mode only exists in user state under p-mode. You'd have to fully set up protected mode first, then fork a user level task, and set *that* into v86. There's no kernel state for v86; your kernel would have to be in p-mode, and trap the v86 interrupts.
>>
>>Why do you want to automatically go into v86 mode, anyway? What is your intended design?
>
>
>You are very correct in your understanding...
>I have been successful in entering protected mode..

OK, then in that case enter v86 mode from p-mode
is fairly straightforward. _The 80386
Programmer's Reference_, chapter 15
(http://webster.cs.ucr.edu/Page_TechDocs ... S15_03.HTM)
describes who to do it in reasonable detail,
assuming. You already know how to set up a
user-level task. An example in code can be found
at http://www.execpc.com/~geezer/johnfine/ ;
scroll down to the link to 'v86test2.zip'.

Unfortunately, I have not been able to find much
information on the Pentium Virtual Mode
Extensions that would be helpful in this
instance. The only link I can really give you as
a starting point on VME is
http://www.ddj.com/documents/s=924/ddj9801o/9801o.htm . Since it works on all modern CPUs, it is best to stick to the i386
level of v86 support anyway, at least for now.

>The reason that I want to enter V86 mode, is to
>be able to use bios!

*sigh* If you intend to use the BIOS for your
I/O, I really recommend reconsidering. The BIOS
is meant only to provide a minimal support to get
the machine started, and even MS-DOS uses it's
own I/O for most of the (very few) services it
provides directly (disk management, primarily).
Not only are the ROMs much slower than code in
RAM (which is why, when DOS was still common,
many 386 BIOS could be set to run 'shadowed' in
RAM), but they all work by polling - acceptable
in a single tasking system with no virtual memory
(just barely), but absolutely unthinkable in most
multitasking OSes.

As for using the BIOS routines as a main I/O (in
v86 mode) for a protected mode OS, frankly it
would be easier to write your own p-mode drivers
instead. *Much* easier.

That having been said, it is certainly possible
to do so; Fine's v86 code sample even mentions
the possibility of doing so. As a step along the
way of developing your system, it may not be too
bad (though it probably is still not worth it
). As a long term solution to a problem, it ranks
somewhere below WIN buttons and airstrips on
icebergs (yes, they really did experiment with
that in WWII, oddly enough).

Hi Schol-R-LEA,
Thanks alot for the detailed explaination...It is
certainly better to write drivers compared to
using BIOS...The problem is how do I find out
how to program the various HARDARE devices....
I struggled a lot to find out how to access the
Hard drive using direct IO and did find some info
although, I still dont have info on how to access
hard drives using LBA...
I am thoroughly convinced that, it is not worth
spending time in figuring out V86!
Now..a little off track...I have a basic doubt...
My IDT contains TSS selectors that point to the
TSS that points to the ISR...now the problem is
that IRET does not seem to work...Should ISR
do something so that the IRET works!!!
regards,
chatamballi

>On 2002-01-25 01:49:14, Schol-R-LEA wrote:
>>On 2002-01-23 04:44:16, chatamballi wrote:
>>
>>
>>>On 2002-01-23 02:10:43, Schol-R-LEA wrote:
>>>>On 2002-01-22 14:38:31, _the_crow_ wrote:
>>>>I'm building an OS and i want it to boot into V86-mode.
>>>>Is it only the PE-bit that i would have to set or
>>>>also VME-bit or VM-flag.
>>>>Tell me all about it plz!
>>>
>>>Hmmmn, not an easy task. Correct me if I'm wrong, but AFAIK v86 mode only exists in user state under p-mode. You'd have to fully set up protected mode first, then fork a user level task, and set *that* into v86. There's no kernel state for v86; your kernel would have to be in p-mode, and trap the v86 interrupts.
>>>
>>>Why do you want to automatically go into v86 mode, anyway? What is your intended design?
>>
>>
>>You are very correct in your understanding...
>>I have been successful in entering protected mode..
>
>OK, then in that case enter v86 mode from p-mode
>is fairly straightforward. _The 80386
>Programmer's Reference_, chapter 15
>(http://webster.cs.ucr.edu/Page_TechDocs ... S15_03.HTM)
>describes who to do it in reasonable detail,
>assuming. You already know how to set up a
>user-level task. An example in code can be found
>at http://www.execpc.com/~geezer/johnfine/ ;
>scroll down to the link to 'v86test2.zip'.
>
>Unfortunately, I have not been able to find much
>information on the Pentium Virtual Mode
>Extensions that would be helpful in this
>instance. The only link I can really give you as
>a starting point on VME is
>http://www.ddj.com/documents/s=924/ddj9801o/9801o.htm . Since it works on all modern CPUs, it is best to stick to the i386
>level of v86 support anyway, at least for now.
>
>>The reason that I want to enter V86 mode, is to
>>be able to use bios!
>
>*sigh* If you intend to use the BIOS for your
>I/O, I really recommend reconsidering. The BIOS
>is meant only to provide a minimal support to get
>the machine started, and even MS-DOS uses it's
>own I/O for most of the (very few) services it
>provides directly (disk management, primarily).
>Not only are the ROMs much slower than code in
>RAM (which is why, when DOS was still common,
>many 386 BIOS could be set to run 'shadowed' in
>RAM), but they all work by polling - acceptable
>in a single tasking system with no virtual memory
>(just barely), but absolutely unthinkable in most
>multitasking OSes.
>
>As for using the BIOS routines as a main I/O (in
>v86 mode) for a protected mode OS, frankly it
>would be easier to write your own p-mode drivers
>instead. *Much* easier.
>
>That having been said, it is certainly possible
>to do so; Fine's v86 code sample even mentions
>the possibility of doing so. As a step along the
>way of developing your system, it may not be too
>bad (though it probably is still not worth it
>). As a long term solution to a problem, it ranks
>somewhere below WIN buttons and airstrips on
>icebergs (yes, they really did experiment with
>that in WWII, oddly enough).

Hi Schol-R-LEA,
Thanks alot for the detailed explaination...It is
certainly better to write drivers compared to
using BIOS...The problem is how do I find out
how to program the various HARDARE devices....
I struggled a lot to find out how to access the
Hard drive using direct IO and did find some info
although, I still dont have info on how to access
hard drives using LBA...
I am thoroughly convinced that, it is not worth
spending time in figuring out V86!
Now..a little off track...I have a basic doubt...
My IDT contains TSS selectors that point to the
TSS that points to the ISR...now the problem is
that IRET does not seem to work...Should ISR
do something so that the IRET works!!!
regards,
chatamballi

>On 2002-01-25 01:49:14, Schol-R-LEA wrote:
>>On 2002-01-23 04:44:16, chatamballi wrote:
>>
>>
>>>On 2002-01-23 02:10:43, Schol-R-LEA wrote:
>>>>On 2002-01-22 14:38:31, _the_crow_ wrote:
>>>>I'm building an OS and i want it to boot into V86-mode.
>>>>Is it only the PE-bit that i would have to set or
>>>>also VME-bit or VM-flag.
>>>>Tell me all about it plz!
>>>
>>>Hmmmn, not an easy task. Correct me if I'm wrong, but AFAIK v86 mode only exists in user state under p-mode. You'd have to fully set up protected mode first, then fork a user level task, and set *that* into v86. There's no kernel state for v86; your kernel would have to be in p-mode, and trap the v86 interrupts.
>>>
>>>Why do you want to automatically go into v86 mode, anyway? What is your intended design?
>>
>>
>>You are very correct in your understanding...
>>I have been successful in entering protected mode..
>
>OK, then in that case enter v86 mode from p-mode
>is fairly straightforward. _The 80386
>Programmer's Reference_, chapter 15
>(http://webster.cs.ucr.edu/Page_TechDocs ... S15_03.HTM)
>describes who to do it in reasonable detail,
>assuming. You already know how to set up a
>user-level task. An example in code can be found
>at http://www.execpc.com/~geezer/johnfine/ ;
>scroll down to the link to 'v86test2.zip'.
>
>Unfortunately, I have not been able to find much
>information on the Pentium Virtual Mode
>Extensions that would be helpful in this
>instance. The only link I can really give you as
>a starting point on VME is
>http://www.ddj.com/documents/s=924/ddj9801o/9801o.htm . Since it works on all modern CPUs, it is best to stick to the i386
>level of v86 support anyway, at least for now.
>
>>The reason that I want to enter V86 mode, is to
>>be able to use bios!
>
>*sigh* If you intend to use the BIOS for your
>I/O, I really recommend reconsidering. The BIOS
>is meant only to provide a minimal support to get
>the machine started, and even MS-DOS uses it's
>own I/O for most of the (very few) services it
>provides directly (disk management, primarily).
>Not only are the ROMs much slower than code in
>RAM (which is why, when DOS was still common,
>many 386 BIOS could be set to run 'shadowed' in
>RAM), but they all work by polling - acceptable
>in a single tasking system with no virtual memory
>(just barely), but absolutely unthinkable in most
>multitasking OSes.
>
>As for using the BIOS routines as a main I/O (in
>v86 mode) for a protected mode OS, frankly it
>would be easier to write your own p-mode drivers
>instead. *Much* easier.
>
>That having been said, it is certainly possible
>to do so; Fine's v86 code sample even mentions
>the possibility of doing so. As a step along the
>way of developing your system, it may not be too
>bad (though it probably is still not worth it
>). As a long term solution to a problem, it ranks
>somewhere below WIN buttons and airstrips on
>icebergs (yes, they really did experiment with
>that in WWII, oddly enough).

Hi Schol-R-LEA,
Thanks alot for the detailed explaination...It is
certainly better to write drivers compared to
using BIOS...The problem is how do I find out
how to program the various HARDARE devices....
I struggled a lot to find out how to access the
Hard drive using direct IO and did find some info
although, I still dont have info on how to access
hard drives using LBA...
I am thoroughly convinced that, it is not worth
spending time in figuring out V86!
Now..a little off track...I have a basic doubt...
My IDT contains TSS selectors that point to the
TSS that points to the ISR...now the problem is
that IRET does not seem to work...Should ISR
do something so that the IRET works!!!
regards,
chatamballi

>On 2002-01-25 01:49:14, Schol-R-LEA wrote:
>>On 2002-01-23 04:44:16, chatamballi wrote:
>>
>>
>>>On 2002-01-23 02:10:43, Schol-R-LEA wrote:
>>>>On 2002-01-22 14:38:31, _the_crow_ wrote:
>>>>I'm building an OS and i want it to boot into V86-mode.
>>>>Is it only the PE-bit that i would have to set or
>>>>also VME-bit or VM-flag.
>>>>Tell me all about it plz!
>>>
>>>Hmmmn, not an easy task. Correct me if I'm wrong, but AFAIK v86 mode only exists in user state under p-mode. You'd have to fully set up protected mode first, then fork a user level task, and set *that* into v86. There's no kernel state for v86; your kernel would have to be in p-mode, and trap the v86 interrupts.
>>>
>>>Why do you want to automatically go into v86 mode, anyway? What is your intended design?
>>
>>
>>You are very correct in your understanding...
>>I have been successful in entering protected mode..
>
>OK, then in that case enter v86 mode from p-mode
>is fairly straightforward. _The 80386
>Programmer's Reference_, chapter 15
>(http://webster.cs.ucr.edu/Page_TechDocs ... S15_03.HTM)
>describes who to do it in reasonable detail,
>assuming. You already know how to set up a
>user-level task. An example in code can be found
>at http://www.execpc.com/~geezer/johnfine/ ;
>scroll down to the link to 'v86test2.zip'.
>
>Unfortunately, I have not been able to find much
>information on the Pentium Virtual Mode
>Extensions that would be helpful in this
>instance. The only link I can really give you as
>a starting point on VME is
>http://www.ddj.com/documents/s=924/ddj9801o/9801o.htm . Since it works on all modern CPUs, it is best to stick to the i386
>level of v86 support anyway, at least for now.
>
>>The reason that I want to enter V86 mode, is to
>>be able to use bios!
>
>*sigh* If you intend to use the BIOS for your
>I/O, I really recommend reconsidering. The BIOS
>is meant only to provide a minimal support to get
>the machine started, and even MS-DOS uses it's
>own I/O for most of the (very few) services it
>provides directly (disk management, primarily).
>Not only are the ROMs much slower than code in
>RAM (which is why, when DOS was still common,
>many 386 BIOS could be set to run 'shadowed' in
>RAM), but they all work by polling - acceptable
>in a single tasking system with no virtual memory
>(just barely), but absolutely unthinkable in most
>multitasking OSes.
>
>As for using the BIOS routines as a main I/O (in
>v86 mode) for a protected mode OS, frankly it
>would be easier to write your own p-mode drivers
>instead. *Much* easier.
>
>That having been said, it is certainly possible
>to do so; Fine's v86 code sample even mentions
>the possibility of doing so. As a step along the
>way of developing your system, it may not be too
>bad (though it probably is still not worth it
>). As a long term solution to a problem, it ranks
>somewhere below WIN buttons and airstrips on
>icebergs (yes, they really did experiment with
>that in WWII, oddly enough).

But then I must write all the interrupts myself.
How else do I access the disk (INT 13h) or
screenpossibilities (INT 10h)?
That's the whole problem!

1. I want to be in Protected Mode.
2. I want to access the disk via INTs.

>On 2002-01-27 09:19:10, _the_crow_ wrote:
>But then I must write all the interrupts myself.
>How else do I access the disk (INT 13h) or
>screenpossibilities (INT 10h)?
>That's the whole problem!
>
>1. I want to be in Protected Mode.
>2. I want to access the disk via INTs.

That's going to be the case pretty much no matter what you do, if you are going to have a p-mode kernel. While you can use the v86 mode for I/O, you still have to define all the interrupt vectors for at least the kernel task. Also, if you want to have a kernel level I/O of any kind, (the equivelent of printk()), you'd have to write your own functions, anyway.

Is going through v86 mode to do basic I/O is easier than writing your own I/O? Not really, I'd say, even for complex or highly variable hardware such as hard drives. Most of the time, you're interfacing with a controller chip, rather than bit-banging the device directly. Text output is essentially trivial; assuming the default text mode, you can treat the text video memory at 0xB000 as if it were defined:

typedef struct {
unsigned char character, attribute;
} text;

text text_pages[4][25][80];

To write a character at a given position on a given video page, you simply figure out its horizontal and vertical position, and write the character and attribute values to that part of the memory buffer. To keep a cursor position, you can define a cursor as

struct cursor {
unsigned int x, y;
}

and increment y as you add new character-attribute pairs (making sure to roll over the increment at 80, resetting y to zero and incrmementing x).

I'm skipping some important details, here - scrolling, for example - but that should more or less work as a starting point. BTW, this is more or less the way it is done in any of the different modes; the major difference is that in p-mode the driver has to have permission to read from and write to the video memory area, AFAICT.

Disk management is actually not as complex, as the ATA and SCSI interfaces are fairly well established. The major problems come from detecting the type and charateristics of the drive, which is a headache by anyone's standards and would be a problem even using the BIOS.

I forgot to hand-wrap my text again, damn it all.

>On 2002-01-27 09:19:10, _the_crow_ wrote:
>But then I must write all the interrupts myself.
>How else do I access the disk (INT 13h) or
>screenpossibilities (INT 10h)?
>That's the whole problem!
>
>1. I want to be in Protected Mode.
>2. I want to access the disk via INTs.

That's going to be the case pretty much no
matter what you do, if you are going to have a p-
mode kernel. While you can use the v86 mode for
I/O, you still have to define all the interrupt
vectors for at least the kernel task. Also, if
you want to have a kernel level I/O of any kind,
(the equivelent of printk()), you'd have to write
your own functions, anyway.

Is going through v86 mode to do basic I/O is
easier than writing your own I/O? Not really, I'd
say, even for complex or highly variable hardware
such as hard drives. Most of the time, you're
interfacing with a controller chip, rather than
bit-banging the device directly. Text output is
essentially trivial; assuming the default text
mode, you can treat the text video memory at
0xB000 as if it were defined:

typedef struct {
unsigned char character, attribute;
} text;

text text_pages[4][25][80];

To write a character at a given position on a
given video page, you simply figure out its
horizontal and vertical position, and write the
character and attribute values to that part of
the memory buffer. To keep a cursor position, you
can define a cursor as

struct cursor {
unsigned int x, y;
}


and increment y as you add new character-
attribute pairs (making sure to roll over the
increment at 80, resetting y to zero and
incrmementing x).

I'm skipping some important details, here -
scrolling, for example - but that should more or
less work as a starting point. BTW, this is more
or less the way it is done in any of the
different modes; the major difference is that in
p-mode the driver has to have permission to read
from and write to the video memory area, AFAICT.

Disk management is actually not as complex, as
the ATA and SCSI interfaces are fairly well
established. The major problems come from
detecting the type and charateristics of the
drive, which is a headache by anyone's standards
and would be a problem even using the BIOS.

>On 2002-01-27 15:27:17, Schol-R-LEA wrote:

> Text output is
>essentially trivial; assuming the default text
>mode, you can treat the text video memory at
>0xB000 as if it were defined:

Oops, that should have been 0xB000:0000, or
0x00B00000 linear (assuming I've done my segment
arithmetic correct).

Hi Schol-R-LEA,
Thanks alot for the detailed explaination...It is
certainly better to write drivers compared to
using BIOS...The problem is how do I find out
how to program the various HARDARE devices....
I struggled a lot to find out how to access the
Hard drive using direct IO and did find some info
although, I still dont have info on how to access
hard drives using LBA...
I am thoroughly convinced that, it is not worth
spending time in figuring out V86!
Now..a little off track...I have a basic doubt...
My IDT contains TSS selectors that point to the
TSS that points to the ISR...now the problem is
that IRET does not seem to work...Should ISR
do something so that the IRET works!!!
regards,
chatamballi

>On 2002-01-25 01:49:14, Schol-R-LEA wrote:
>>On 2002-01-23 04:44:16, chatamballi wrote:
>>
>>
>>>On 2002-01-23 02:10:43, Schol-R-LEA wrote:
>>>>On 2002-01-22 14:38:31, _the_crow_ wrote:
>>>>I'm building an OS and i want it to boot into V86-mode.
>>>>Is it only the PE-bit that i would have to set or
>>>>also VME-bit or VM-flag.
>>>>Tell me all about it plz!
>>>
>>>Hmmmn, not an easy task. Correct me if I'm wrong, but AFAIK v86 mode only exists in user state under p-mode. You'd have to fully set up protected mode first, then fork a user level task, and set *that* into v86. There's no kernel state for v86; your kernel would have to be in p-mode, and trap the v86 interrupts.
>>>
>>>Why do you want to automatically go into v86 mode, anyway? What is your intended design?
>>
>>
>>You are very correct in your understanding...
>>I have been successful in entering protected mode..
>
>OK, then in that case enter v86 mode from p-mode
>is fairly straightforward. _The 80386
>Programmer's Reference_, chapter 15
>(http://webster.cs.ucr.edu/Page_TechDocs ... S15_03.HTM)
>describes who to do it in reasonable detail,
>assuming. You already know how to set up a
>user-level task. An example in code can be found
>at http://www.execpc.com/~geezer/johnfine/ ;
>scroll down to the link to 'v86test2.zip'.
>
>Unfortunately, I have not been able to find much
>information on the Pentium Virtual Mode
>Extensions that would be helpful in this
>instance. The only link I can really give you as
>a starting point on VME is
>http://www.ddj.com/documents/s=924/ddj9801o/9801o.htm . Since it works on all modern CPUs, it is best to stick to the i386
>level of v86 support anyway, at least for now.
>
>>The reason that I want to enter V86 mode, is to
>>be able to use bios!
>
>*sigh* If you intend to use the BIOS for your
>I/O, I really recommend reconsidering. The BIOS
>is meant only to provide a minimal support to get
>the machine started, and even MS-DOS uses it's
>own I/O for most of the (very few) services it
>provides directly (disk management, primarily).
>Not only are the ROMs much slower than code in
>RAM (which is why, when DOS was still common,
>many 386 BIOS could be set to run 'shadowed' in
>RAM), but they all work by polling - acceptable
>in a single tasking system with no virtual memory
>(just barely), but absolutely unthinkable in most
>multitasking OSes.
>
>As for using the BIOS routines as a main I/O (in
>v86 mode) for a protected mode OS, frankly it
>would be easier to write your own p-mode drivers
>instead. *Much* easier.
>
>That having been said, it is certainly possible
>to do so; Fine's v86 code sample even mentions
>the possibility of doing so. As a step along the
>way of developing your system, it may not be too
>bad (though it probably is still not worth it
>). As a long term solution to a problem, it ranks
>somewhere below WIN buttons and airstrips on
>icebergs (yes, they really did experiment with
>that in WWII, oddly enough).