Flat Real Mode

Index > OS Construction > Flat Real Mode

Goto page 1, 2 Next

Author

Thread

VitalOne

Joined: 29 Jul 2003
Posts: 54
Location: USA

VitalOne 30 Jul 2003, 15:57

Wondering how to go into Flat Real Mode, I tried a while ago and I kept causing triple faults some how. Anyone have a sample?

30 Jul 2003, 15:57

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 30 Jul 2003, 15:59

DOS version of fasm is an example.
Let me know if you need some simpler sample.

As current DOS releases use the different interface, I'm posting those old sources here.

Description:		Download
Filename:	fasmfrm.zip
Filesize:	5.53 KB
Downloaded:	1323 Time(s)

Last edited by Tomasz Grysztar on 15 Sep 2003, 12:17; edited 2 times in total

30 Jul 2003, 15:59

VitalOne

Joined: 29 Jul 2003
Posts: 54
Location: USA

VitalOne 30 Jul 2003, 16:47

Thanks, I'll check it out.

30 Jul 2003, 16:47

VitalOne

Joined: 29 Jul 2003
Posts: 54
Location: USA

VitalOne 30 Jul 2003, 16:58

If you have a simpler example, it would help. The SYSTEM.INC is a bit too long for me (over 700 lines) since I just started OS coding.

30 Jul 2003, 16:58

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 30 Jul 2003, 17:16

Only first 80 lines are important for your needs, they contain: init_flatrm routine, int_13 routine and the GDTR and GDT data definitions. You can cut it and use in your own .com program, in such case you need also the short routine fatal_error which you can find later in that file.
The init_flatrm doesn't initialize FRM, it ony sets the interrupt vector for exception 13, which occurs, when some program in DOS tries to access memory offsets above the 64KB, but is not allowed to. The exception handler initializes FRM and returns control to the program, which is now allowed to proceed with the instruction that caused an exception. This approach has two advantages: first, even if some program (for example a TSR switching to protected mode and back) breaks the FRM, it won't affect your program, because FRM is automatically restored; second, if DOS is already in FRM, the FRM initialization won't be invoked at all, as it is unnecessary.

30 Jul 2003, 17:16

VitalOne

Joined: 29 Jul 2003
Posts: 54
Location: USA

VitalOne 30 Jul 2003, 17:25

Thanks Alot ! Very Happy

30 Jul 2003, 17:25

Perica

Joined: 07 Sep 2003
Posts: 5

Perica 07 Sep 2003, 04:46

Just in case you might want another example of how to enter flat real mode, here is some code which I wrote to do it:

Code:

; Code to enter flat real mode.
; Released into the public domain.

; *****Put these structures into the data section of your code*****

 StartOf_GDT:

 FlatRM_GDTR:
         dw (EndOf_GDT - StartOf_GDT - 1)
         dd (StartOf_GDT)

         dw 0

; 32-Bit Data Selector Descriptor
         db 0xFF
         db 0xFF
         db 0x00
         db 0x00
         db 0x00
         db 10010010b
         db ((1100b << 4) | (0x0F))
         db 0x00

 EndOf_GDT:

; *****Put this code into the code section of your code*****

; Enter "flat" real mode
    push ds
    push es
    push fs
    push gs

    lgdt[FlatRM_GDTR]

    mov eax, cr0
    or al, 00000001b
    mov cr0, eax

    mov bx, 0x0008
    mov ds, bx
    mov es, bx
    mov fs, bx
    mov gs, bx

    and al, 11111110b
    mov cr0, eax

    pop gs
    pop fs
    pop es
    pop ds

Last edited by Perica on 25 Mar 2005, 22:36; edited 2 times in total

07 Sep 2003, 04:46

Tommy

Joined: 17 Jun 2003
Posts: 489
Location: Norway

Tommy 07 Sep 2003, 07:21

Can someone help me get my OS into flat real mode... I'm just a newbie in developing operating systems, so I really need help... Confused

Thanks!

Regards,
Tommy

Description:		Download
Filename:	os.zip
Filesize:	2.34 KB
Downloaded:	1117 Time(s)

07 Sep 2003, 07:21

tom tobias

Joined: 09 Sep 2003
Posts: 1320
Location: usa

tom tobias 09 Sep 2003, 13:12

I apologize for displaying such profound ignorance, I thought gdt was needed for protected mode, not real mode. Why should it be required for real mode?? The idea, at least in my mind if not in reality, is that "flat" corresponds to assigning ALL of the segment selectors to the same physical location, hence the entire 32 bit address space is available to the os in protected mode. I thought real mode accessed a considerably smaller address space, regardless of whether or not the segment registers are all assigned to the same physical address. I understand, perhaps incorrectly, that real mode offers one advantage to compensate for the more limited address space: faster execution, since there is no need to check for protection violations, though with pipelining, perhaps this is incorrect. I would profit from your further explanation of the benefits of flat real mode. thanks, tom tobias

09 Sep 2003, 13:12

Tommy

Joined: 17 Jun 2003
Posts: 489
Location: Norway

Tommy 09 Sep 2003, 13:31

...I'm not used to all these expressions, but: the thing I want with my OS is to run it in 32-bit mode... How do I?

09 Sep 2003, 13:31

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 09 Sep 2003, 13:55

Flat real mode is a standard 16-bit real mode combined with the 32-bit addressing inside the segments, so the whole 4 GB of addressing space is available. The reason why we can't use 32-bit offsets for addressing in the standard real mode is the limit of 64 KB, which is set by default for all the selectors in real mode. And the important detail is: altough in real mode selectors are just segment numbers, that are converted to base address of selector, other fields of the selector - which can be loaded only in protected mode - are still used even after returning from protected mode. Therefore every application that switches back to real mode, is responsible for restoring all selectors to the valid state for real mode, including 64 KB limit. And this also allows us to make a FRM trick - we are switching to protected mode, setting limit for all selectors to 4 GB (that's what we need GDT for), and then we are switching back to real mode, "forgetting" to restore the selectors. This way we obtain real mode with offsets above 64 KB allowed.

The segment limit is the only difference between "classic" real mode and flat real mode, which was discussed above. Code in FRM is still 16-bit, so when you use 32-bit registers and addressing, there will be a lot of prefixes in your code, causing it to be bigger and slower. There is also a more advanced trick (I prefer to call it unreal mode, altough some people used to call even the standard FRM the "unreal mode"), which allows to execute 32-bit code in real mode. It seems to be simple to do - just set the flag of code selector to 32-bit and return to real mode without restoring it; but it causes more problems, mainly with interrupts. There is a version of fasm interface that uses unreal mode (I have posted it in DOS forum), you can look at its source for more details - I'm using two IDT tables to switch correctly between 16-bit and 32-bit real mode in order to correctly handle BIOS/DOS interrupts, etc.

09 Sep 2003, 13:55

Tommy

Joined: 17 Jun 2003
Posts: 489
Location: Norway

Tommy 09 Sep 2003, 19:50

If I'm going to have a screen resolution on 800x600 (VESA), I need to make the OS executing 32-bit code - to get it as easy as possible to access all the video memory -, am I right?? Sorry if I'm asking stupid questions, I'm totally new to this.... Can someone help me getting my OS into protected mode and avail it to use 32-bit registers??

Thanks!

09 Sep 2003, 19:50

tom tobias

Joined: 09 Sep 2003
Posts: 1320
Location: usa

tom tobias 09 Sep 2003, 20:41

[quote="Privalov"]Flat real mode is a standard 16-bit real mode combined with the 32-bit addressing inside the segments, so the whole 4 GB of addressing space is available.

Thank you very much Privalov. Wow, excellent explanation. I will follow your advice and read your dos documentation, Thanks for clarifying the roles of GDT and IDT in real mode. Since it would appear, from your well written explanation, that FRM is SLOWER than plain vanilla real mode, I wonder what advantage it offers compared with protected mode? If one wants to use 32 bit addressing, why not stick to protected mode, rather than switching back and forth? My code (voice recognition) is all in ordinary real mode (plain vanilla, can I call it PVRM??), and I have been following Ville's terrific MENUET with great interest, but, now, after reading about FRM, I am wondering if it might be simpler to attempt to convert rather to FRM, instead of protected mode. I don't require protected mode per se, I just want 32 bit flat addressing, "neutralizing" the damn segment registers. I don't need (or seek) ring 3 protection, and DO need to process interrupts in real mode. My 100% ASM code is sufficiently fast, using a split radix FFT, so I don't mind the relative decrase in execution speed associated with the overhead of switching back and forth to protected mode to access IDT. Thanks again. Regards, Tom Tobias Smile

]

09 Sep 2003, 20:41

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 15 Sep 2003, 12:19

Tommy wrote:

If I'm going to have a screen resolution on 800x600 (VESA), I need to make the OS executing 32-bit code - to get it as easy as possible to access all the video memory -, am I right??

No, the 16-bit code with 32-bit addressing will be enough to use linear framebuffer of VESA 2.0, and for banked VESA 1.2 you don't even need 32-bit addresses.
The kelvar example on the fasm's website is using VESA in 32-bit real mode, you can look there, but it's a bit complex.

15 Sep 2003, 12:19

Tommy

Joined: 17 Jun 2003
Posts: 489
Location: Norway

Tommy 15 Sep 2003, 12:43

Thanks Privalov! Cool

15 Sep 2003, 12:43

Pharabee

Joined: 18 Nov 2003
Posts: 16
Location: Sukabumi,Indonesia

Pharabee 29 Nov 2003, 13:47

Perica wrote:

Just in case you might want another example of how to get into Flat Real Mode, here is some code taken from my Operating System.

Code:

; Code to get into Flat Real Mode.
; Copyright (C) 2003, Perica Senjak. All Rights Reserved.

; *****Put these structures into the Data Section of your code*****

 StartOf_GDT:

 FlatRM_GDTR:
         dw (EndOf_GDT - StartOf_GDT - 1)
         dd (StartOf_GDT)

         dw 0

; 32-Bit Data Selector Descriptor
         db 0xFF
         db 0xFF
         db 0x00
         db 0x00
         db 0x00
         db 10010010b
         db ((1100b << 4) | (0x0F))
         db 0x00

 EndOf_GDT:

; *****Put this code into the Code Section of your code*****

; Enter "flat" real mode
    push ds
    push es
    push fs
    push gs

    lgdt[FlatRM_GDTR]

    mov eax, cr0
    or al, 00000001b
    mov cr0, eax

    mov bx, 0x0008
    mov ds, bx
    mov es, bx
    mov fs, bx
    mov gs, bx

    and al, 11111110b
    mov cr0, eax

    pop gs
    pop fs
    pop es
    pop ds

Why did it pop es and ds again after change it?

_________________
How to Get work Fast:
10% Skill, 90% honesty.

29 Nov 2003, 13:47

RedGhost

Joined: 18 May 2005
Posts: 443
Location: BC, Canada

RedGhost 26 Jan 2006, 01:33

Pharabee wrote:

Perica wrote:

Just in case you might want another example of how to get into Flat Real Mode, here is some code taken from my Operating System.

Code:

; Code to get into Flat Real Mode.
; Copyright (C) 2003, Perica Senjak. All Rights Reserved.

; *****Put these structures into the Data Section of your code*****

 StartOf_GDT:

 FlatRM_GDTR:
         dw (EndOf_GDT - StartOf_GDT - 1)
         dd (StartOf_GDT)

         dw 0

; 32-Bit Data Selector Descriptor
         db 0xFF
         db 0xFF
         db 0x00
         db 0x00
         db 0x00
         db 10010010b
         db ((1100b << 4) | (0x0F))
         db 0x00

 EndOf_GDT:

; *****Put this code into the Code Section of your code*****

; Enter "flat" real mode
    push ds
    push es
    push fs
    push gs

    lgdt[FlatRM_GDTR]

    mov eax, cr0
    or al, 00000001b
    mov cr0, eax

    mov bx, 0x0008
    mov ds, bx
    mov es, bx
    mov fs, bx
    mov gs, bx

    and al, 11111110b
    mov cr0, eax

    pop gs
    pop fs
    pop es
    pop ds

Why did it pop es and ds again after change it?

he was preserving them

_________________
redghost.ca

26 Jan 2006, 01:33

dileep

Joined: 27 Mar 2012
Posts: 5

dileep 27 Mar 2012, 11:25

Tomasz Grysztar wrote:

It seems to be simple to do - just set the flag of code selector to 32-bit and return to real mode without restoring it; but it causes more problems, mainly with interrupts..

What are the problems with interrupts while entering unreal mode?
Can you please explain it?

27 Mar 2012, 11:25

smiddy

Joined: 31 Oct 2004
Posts: 557

smiddy 27 Mar 2012, 13:24

dileep wrote:

Tomasz Grysztar wrote:
It seems to be simple to do - just set the flag of code selector to 32-bit and return to real mode without restoring it; but it causes more problems, mainly with interrupts..

What are the problems with interrupts while entering unreal mode?
Can you please explain it?

In unreal mode, there isn't a problem per se'. It is if you go to Protected Mode, you have to setup interrupts quite a bit differently. When you go back to (un)Real Mode, you have to re-setup interrupts. I've been able to go back and forth between PM and RM, but I update the IVT (Interrupt Vector Table) in each instance. I suspect, theoretically, you can do it with Long Mode too, and you probably need to set it up three times, once for RM, PM, and LM. At some point I will try it, but I'm not ready at the moment.

27 Mar 2012, 13:24

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 27 Mar 2012, 13:31

dileep wrote:

What are the problems with interrupts while entering unreal mode?
Can you please explain it?

I gave the detailed explanation here: http://board.flatassembler.net/topic.php?t=11940

smiddy: note that I used the term "unreal mode" in the different sense than simple "flat real mode". "unreal" here means running the FRM with 32-bit code.

27 Mar 2012, 13:31

Goto page 1, 2 Next

< 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