flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Protected Mode

Author
Thread Post new topic Reply to topic
dosin



Joined: 24 Aug 2007
Posts: 337
dosin 01 Sep 2007, 02:43
I need to find a well documented example of PMode that would help me learn whats going on in PM world! I have seen a bunch of examples and what a mess
from one app to another..

I think the prob is that they do the bare min to get it working...


If anyone knows of a good example /website ect..


Thanks in advance!!!

Aslo: TY to everyones help on my OS I have the real mode OS working and it loads .exe/.com file I am thinking of adding .o executable files also..Also I have ran my first C program with a lib I found on the net..
The lib is written with asm bios functions and works with Turbo C
just replace the old libs with the new one and compile just like you normally
would..


I do have one more question.. Why has no one created a complete C .lib/vga.lib/vesa.lib written with bios functions ... This C .lib would not be OS dependent but processor dependent! or is this a bad idea? My logic is : if the functions are the same you could re-compile current c programs to work with no modification of the code or include files

example of TC .c file with bios functions:

#include <stdio.h>

int main()
{
printf("Hello OS!\n");

return 0;
}

The bios C lib I have now includes:
conio.h
Diskio.h
stdio.h
string.h
-this is nice it can read fat12/16 dos file system formats!

uses regular c functions:
fopen
printf
ect....
Post 01 Sep 2007, 02:43
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 01 Sep 2007, 08:34
It wouldn't be processor dependent but BIOS dependent... BIOS is 16bit realmode and usually extremely slow, so it's not much use for "real world" stuff. And you typically can't call BIOS from modern OS'es, unless you're actually writing DOS programs and the OS has 16-bit DOS emulation/support.
Post 01 Sep 2007, 08:34
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1900
DOS386 01 Sep 2007, 09:39
Quote:
It wouldn't be processor dependent but BIOS dependent... BIOS is 16bit realmode and usually extremely slow, so it's not much use for "real world" stuff. And you typically can't call BIOS from modern OS'es


NOT true. BIOS works pretty well and is less dead than some geeks would like to see it. It is not the fastest, but still useful, provides access to VGA, VESA, Floppy ( Sad ), HD (IDE and SATA), partially even USB storage. But right, BIOS can't be called directly from PM, have to switch to RM for BIOS calls.

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 01 Sep 2007, 09:39
View user's profile Send private message Reply with quote
dosin



Joined: 24 Aug 2007
Posts: 337
dosin 01 Sep 2007, 10:46
Well just to add I was looking for a good pmode example/tutorial-


This is what I am shooting for my first OS!
writing DOS programs and the OS has 16-bit DOS emulation/support.
and is for more of a learning environment... I have executed a pmode exe file written with this type of .clib and it worked - I was able to access the extended memory and exit pmode and return to the 16 bit os. My goal is to eventually learn pmode and have the real mode os launch the pmode kernel and have it take control from there

Plus the clib will help write utilities like edit,copy, .......and I can still use the dos int.. that my os will support

Thinking outside of the box:
boot loader
pmode
jump to graphics
wow an os!
well for beginners this is were they want to begin..I know this was my first thought on building an os!

Don't forget whats in the box - it started everything!
bios..
dos..
ect!
Post 01 Sep 2007, 10:46
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 01 Sep 2007, 11:47
You can't depend on DOS if you're building an OS, really... and depending on the BIOS? Sure, if you want to have a very slow OS. But hey, the choice is yours Smile
Post 01 Sep 2007, 11:47
View user's profile Send private message Visit poster's website Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden 01 Sep 2007, 17:17
Many OS's use the bios's extensivly at the executive level...

_________________
New User.. Hayden McKay.
Post 01 Sep 2007, 17:17
View user's profile Send private message Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u 01 Sep 2007, 17:32
First i agree with NTOSKRNL_VXE, BIOS is not slow, anyone who thinks BIOS is slow, but Dos is not, does not know how Dos works ( not say you said that ).
But Dos is just wraps in most cases that call BIOS functions.

@dosin, please post a link to the clib so we can help you more and remember C aim's to be portable.
I have written a vesa demo to go to and from pmode for mode switching that may help, let me know if you want to see the fasm code .

@f0dder, linux was fully dependent on "MINIX" in the first ver's of linux.
http://kerneltrap.org/node/14002
Post 01 Sep 2007, 17:32
View user's profile Send private message Reply with quote
dosin



Joined: 24 Aug 2007
Posts: 337
dosin 01 Sep 2007, 20:55
I will post the code and clib later tonight!

Bios -
Some of the functions could be written with in/out :IO functions instead...

I think this would be a great help developers..
Plus if you have Turbo C it is easy to configure with it!

just go to your Lib folder and replace the COS.OBJ and CS.LIB
then add the include files to either the bin or include folder


if in the include folder use:
#include <sdtio.h>

if in the bin folder use:
#include "stdio.h"

Just remember to make back ups of the lib and include files you replace!!!

This lib is still not fully tested!! You should not need to recompile it unless you add some functions/or change it!

Also:


Quote:
I have written a vesa demo to go to and from pmode for mode switching that may help, let me know if you want to see the fasm code .


Sure that would be great!!! I am still not real comfortable with PMODE yet!
Thats why I was asking for a good tutorial/examples
Post 01 Sep 2007, 20:55
View user's profile Send private message Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u 02 Sep 2007, 00:21
http://www.dex4u.com/demos/DemoVesa.zip
NOTE: I was called ASHLEY4 when i coded it.
Post 02 Sep 2007, 00:21
View user's profile Send private message Reply with quote
dosin



Joined: 24 Aug 2007
Posts: 337
dosin 02 Sep 2007, 20:21
Dex4u: In your demovesa application I loose the keyboard and disk functions..ect I am guessing its because the IRQs need to reprogrammed
Great example very easy to follow!!!!

could you list the steps for pmode:
example:
1. Build the GDT
2. Enable A20 on the address bus
3. Enable protected mode in the CPU control register (CR0)
4. JUMP to clear the prefetch queue
ect..


Thanks again!!!




Here is that clib I found on the net!
it does have a pmode sample that worked on my computer and I ran it from my os... Also it will run non dos .com and .exe files..


Description:
Download
Filename: los4d.zip
Filesize: 109.18 KB
Downloaded: 219 Time(s)

Post 02 Sep 2007, 20:21
View user's profile Send private message Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u 03 Sep 2007, 01:57
Thanks for the lib code, as for why no keyboard etc, when entering pmode you need setup IDT and remap pic before you can use int, if not you need to disable them with cli in realmode before entering pmode, that means you can not use keyboard.
But as a temp measure, you can use poll to get keyboard input
Example:
Code:
NoKey:        xor   eax,eax        in    AL,60h        cmp   al,0x50        jne   NoKey1;do something here        jmp   NoKeyNoKey1:        cmp   al,0x48        jne   NoKey2;do something here        jmp   NoKeyNoKey2:        cmp   al,0x1c        jne   NoKey  ;do something here        jmp   NoKey    


Setting up GDT
Quote:

How to get into protected mode? First, you need a GLOBAL DESCRIPTOR
TABLE (GDT). There is one at the end of this file, at address "gdt:"
The GDT contains 8-byte DESCRIPTORS for each protected-mode segment.
Each descriptor contains a 32-bit segment base address, a 20-bit segment
limit, and 12 bits describing the segment type. The descriptors look
like this:

MSB bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 LSB
+-------+-------+-------+-------+-------+-------+-------+-------+
byte 0 | bit 7<---------------- segment limit------------------->bit 0 |
+-------+-------+-------+-------+-------+-------+-------+-------+

+-------+-------+-------+-------+-------+-------+-------+-------+
byte 1 |bit 15<---------------- segment limit------------------->bit 8 |
+-------+-------+-------+-------+-------+-------+-------+-------+

+-------+-------+-------+-------+-------+-------+-------+-------+
byte 2 | bit 7<---------------- segment base-------------------->bit 0 |
+-------+-------+-------+-------+-------+-------+-------+-------+

+-------+-------+-------+-------+-------+-------+-------+-------+
byte 3 |bit 15<---------------- segment base-------------------->bit 8 |
+-------+-------+-------+-------+-------+-------+-------+-------+

+-------+-------+-------+-------+-------+-------+-------+-------+
byte 4 |bit 23<---------------- segment base-------------------->bit 16|
+-------+-------+-------+-------+-------+-------+-------+-------+

+-------+-------+-------+-------+-------+-------+-------+-------+
byte 5 | P | DPL | <----------- segment type ----------> |
+-------+-------+-------+-------+-------+-------+-------+-------+

P is the Segment Present bit. It should always be 1.

DPL is the DESCRIPTOR PRIVILEGE LEVEL. For simple code like this, these
two bits should always be zeroes.

Segment Type (again, for simple code like this) is hex 12 for data
segments, hex 1A for code segments.

+-------+-------+-------+-------+-------+-------+-------+-------+
byte 6 | G | B | 0 | avail | bit 19<-- seg limit--->bit 16 |
+-------+-------+-------+-------+-------+-------+-------+-------+

G is the Limit Granularity. If zero, the segment limit is in bytes
(0 to 1M, in 1-byte increments). If one, the segment limit is in 4K PAGES
(0 to 4G, in 4K increments). For simple code, set this bit to 1, and
set the segment limit to its highest value (FFFFF hex). You now have
segments that are 4G in size! The Intel CPUs can address no more than
4G of memory, so this is like having no segments at all. No wonder
protected mode is popular.

B is the Big bit; also called the D (Default) bit. For code segments,
all instructions will use 32-bit operands and addresses by default
(BITS 32, in NASM syntax, USE32 in Microsoft syntax) if this bit is set.
16-bit protected mode is not very interesting, so set this bit to 1.

None of these notes apply to the NULL descriptor. All of its bytes
should be set to zero.

+-------+-------+-------+-------+-------+-------+-------+-------+
byte 7 |bit 31<---------------- segment base------------------->bit 24 |
+-------+-------+-------+-------+-------+-------+-------+-------+

Build a simple GDT with four descriptors: NULL (all zeroes), linear data
(lets you use 32-bit addresses), code, and data/stack. (An extra
descriptor or two is needed to return to real mode.) For simplicity,
the limits of all descriptors (except NULL and the real-mode descriptors)
are FFFFF hex, the largest possible limit.

In a real-mode .COM file, CS=DS. To make addressing identical in real
mode and protected mode, we set the base of the code and data descriptors
to DS * 16. This number is computed at run-time; the other numbers in
the GDT can be done at assemble-time.


The steps are the same as you put but i would add settingup IDT or disableing with cli
This is the min thing you need, and remember this is for a single-tasking 32bit pmode OS,
If you want a 32bit pmode multi-tasking OS, with uses using ring3 and paging etc there more.
Note: also in pmode you can not use any bios ints, eg: int 13h, but you can goto and from pmode to realmode or write you own pmode driver.
Post 03 Sep 2007, 01:57
View user's profile Send private message Reply with quote
dosin



Joined: 24 Aug 2007
Posts: 337
dosin 03 Sep 2007, 04:38
Dex4u: Thank you, for all your help!

One thing I was wondering.. with that clib... it uses bios int 10h/16h ect
and in pmode these don't work correct!

Quote:

Note: also in pmode you can not use any bios ints, eg: int 13h,


with this clib I was able to enter pmode and use them with the printf fucntion ect.......

could it be that tc compiler sets up a virtual bus that points to those functions..
Since this virtual bus is running on windows?
I read this is possible to program into pmode..
If so a clib like this would be worth using and building upon!..

if you want to see what I am talking about :
boot the loader2.exe in the PM LOADER file
Post 03 Sep 2007, 04:38
View user's profile Send private message Reply with quote
dosin



Joined: 24 Aug 2007
Posts: 337
dosin 04 Sep 2007, 13:16
Dex4u would you mind taking a look at this example I uploaded!


Load the files on a floppy and boot- at the prompt type -dir and run the vm86.com/exe

it uses the virtual real mode....

it seems to work!!!

if you want to help to convert the nasm to FASM just let me know and I will up load it!!! It was an open source nasm/gcc program for virtual real mode I found..


Description:
Download
Filename: SAMP.zip
Filesize: 127.83 KB
Downloaded: 218 Time(s)

Post 04 Sep 2007, 13:16
View user's profile Send private message Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u 04 Sep 2007, 15:36
I have down loaded it, i will test it later and let you know how it runs, on some of my test PC.

PS: I think that demo2 users this for string out put, in pmode.
Code:
print_str:;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Input : ESI = ASCIIZ string address   ;;;;         BH  = Y coordinate (Y>=0)     ;;;;         BL  = X coordinate            ;;;;         textattr = color attribute    ;;;; Output: None, registers are preserved ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;    push      es    pushad    mov       ax, 18h    mov       es, ax    shl       ebx, 1                   ; y*=2, x*=2    movzx     edi, bh                  ; edi = y*2    shl       edi, 4                   ; edi = (y*2)*16    mov       eax, edi                 ; eax = (y*2)*16    shl       edi, 2                   ; edi = (y*2)*64    add       edi, eax                 ; edi = (y*2)*80    movzx     ebx, bl                  ; ebx = x*2    add       edi, ebx                 ; edi = (y*80+x)*2    add       edi, [video_addr]    mov       ah, [textattr]           ; background color    cld.1:    lodsb    or        al, al    jz        .2    stosw    jmp       .1.2:    popad    pop       es    ret    
Which does not use any realmode int's, and is what a pmode print string should look like.


Last edited by Dex4u on 05 Sep 2007, 15:13; edited 1 time in total
Post 04 Sep 2007, 15:36
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1900
DOS386 04 Sep 2007, 22:35
> it uses bios int 10h/16h ect and in pmode these don't work correct!

Char output: do-it-yourself in PM, it's trivial (see above)

VGA: switch to RM or do it from PM via ports

VESA: switch to RM (very difficult to do from PM via ports)

FD/HD: switch to RM or do it from PM via ports
Post 04 Sep 2007, 22:35
View user's profile Send private message Reply with quote
dosin



Joined: 24 Aug 2007
Posts: 337
dosin 06 Sep 2007, 20:33
I think I have a good idea now on how to do it...
Thanks for all the help!!!
Post 06 Sep 2007, 20:33
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4330
Location: Now
edfed 12 Oct 2007, 10:32
ok

but for vesa i prefer pm (via ports) and the rm possibility
even it's very difficult
Post 12 Oct 2007, 10:32
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.