OSDev.org

Posted: **Sat Nov 14, 2009 5:11 pm**

tom9876543 wrote:Unreal mode IS documented by Intel and AMD. They just call it SMM mode. BIOSes rely on it to operate. SMM was officially implemented with the 386. Unreal mode is simply the OS taking advantage of the 4gb limit in the same way the BIOS does under SMM mode.

Hm, you are right - It does provide the same tactic the BIOS uses (alot of them, anyways) for the OS to use for its own purposes. Also, removing this "feature" would break alot of existing software which I dont see Intel or AMD wanting to do. I personally still would not use it though (no need) but considering the above I suppose it doesnt matter if it gets used or not.

Posted: **Sun Nov 15, 2009 12:14 am**

tom9876543 wrote:Unreal mode IS documented by Intel and AMD. They just call it SMM mode. BIOSes rely on it to operate. SMM was officially implemented with the 386. Unreal mode is simply the OS taking advantage of the 4gb limit in the same way the BIOS does under SMM mode.

I can't even begin to say how wrong this is...

Posted: **Sun Nov 15, 2009 4:04 am**

Love4Boobies wrote:I can't even begin to say how wrong this is...

That is not wrong per se. SMM uses the unreal mode "trick", afaik. And as for everyone claiming support for unreal mode will maybe disappear, and that's why you shouldn't use it: that's a fallacy. Intel and/or AMD can remove any support, even documented ones. v86 / 64-bit anyone? As far as I am aware, it is documented that when switching from real to protected mode, the CPU does not flush its TLBs, which is what unreal mode relies on. So stop complaining about use of unreal mode: it is a perfectly acceptable way of copying your OS to > 1MB, especially in a boot loader since that is a limited piece of software that can be replaced if needed. Other ways are loading the OS below 1MB, then copying it to upper after switching to protected mode, or constantly switching between real and protected mode.

JAL

Posted: **Sun Nov 15, 2009 4:05 am**

XanClic wrote:When I wrote my own bootloader, I used the unreal mode first. But it didn't work on my computer

Since unreal mode relies on documented behaviour, unless you did not have an Intel/AMD/VIA CPU, I believe that statement is false.

JAL

Posted: **Sun Nov 15, 2009 4:08 am**

Karlosoft wrote:Hi! I'm trying to support the unreal mode in my bootloader. Is there a way to use the old segment:offest notation up to the first megabyte and the physical for the upper addresses?

Unreal mode allows you to specify a 32 bit offset to any segment, instead of just 16 bit. So you'll always have segment:offset working as in real mode (in fact, unreal mode is real mode). If you want to use "physical addresses", set your segment(s) to 0. There is no difference between the first MB and other memory, so the most direct answer to your question is "no".

JAL

Posted: **Sun Nov 15, 2009 5:30 am**

jal wrote:I believe that statement is false.

Yes, it is:

I wrote:I still found that old piece of code but it was only the "switch" version (switching from real to protected mode and back). That worked as expected. Then I changed that code to do everything in unreal mode and... It still worked. So it was the usual stuff, just a bug made by me and not an unusual CPU behaviour. Though I don't have the original code to locate that bug.

Posted: **Sun Nov 15, 2009 6:38 am**

XanClic wrote:Yes, it is

Right, that'll teach me to post before reading the entire thread. My apologies!

JAL

Posted: **Sun Nov 15, 2009 9:08 am**

jal wrote:
Love4Boobies wrote:I can't even begin to say how wrong this is...
That is not wrong per se. SMM uses the unreal mode "trick", afaik.

It is wrong par se. SMM is a mode it can't "use" anything; as for firmware code running in SMM it makes just as little sense. Some BIOSes do make use of unreal mode at boot time but it's not SMM code.

Posted: **Sun Nov 15, 2009 1:47 pm**

Not an extension on whether or not to use unreal mode, but an explanation as to why it may fail on some computers even with AMD and Intel CPUs:

The BIOS can load the segment registers when it gets called (either via HW or user INT) and when it tries to "restore" the segments it doesn't properly restore the hidden fields (because it can't) meaning that segment register is no longer in unreal mode.

Posted: **Mon Nov 16, 2009 4:18 am**

We had a discussion once of what you (original topic poster) are trying to do. You just need to go to protected mode, overwrite the hidden potion of segment registers to allow read/write (and for CS read/execute) to all of the 4GB address space, go back into real mode and overwrite the segments visible portion (and of course unlock gateA20). In this way addressing will be segment*16:offset, where offset can be 16-bit or 32-bit number and the limit will be 4GB.

Posted: **Mon Nov 16, 2009 5:39 am**

Thanks to everyone who has replied

However I'm going to work in unreal mode because it's the simplest way.
And If one day it won't work, rewrite a bootloader isn't very difficult.
There is just an other problem. I'm writing this bootloader in Assembly and C. My compiler (TCC) use pointers with a lenght of 16bits. So I am limited in a space of just 64k. Is there any way to use (or force the use of) 32bit pointers in the C code? I know it's a little different problem but I prefer post it here

Posted: **Mon Nov 16, 2009 6:40 am**

You may try inline assembly.

Code: Select all

#pragma inline

typedef unsigned int word;
typedef unsigned long dword;

word peek(dword address)
{
    asm mov edx, address
    asm mov ax, word ptr [edx]
    return _AX;
}

void poke(word value, dword address)
{
    asm mov edx, address
    asm mov ax, value
    asm mov word ptr [edx], ax
}

This needs an external assembler (TASM). I haven't tried it, so please test it first.

Posted: **Mon Nov 16, 2009 6:59 am**

Firestryke31 wrote:The BIOS can load the segment registers when it gets called (either via HW or user INT) and when it tries to "restore" the segments it doesn't properly restore the hidden fields (because it can't) meaning that segment register is no longer in unreal mode.

Unless the BIOS switches to PM, there's no way to touch the "hidden parts" of the segments. Although not really BIOS, HIMEM.SYS switches to PM iirc for doing XMS copying of memory chunks. Your plain old standard BIOS does not though, afaik.

JAL

Posted: **Mon Nov 16, 2009 10:38 am**

jal wrote:
Firestryke31 wrote:The BIOS can load the segment registers when it gets called (either via HW or user INT) and when it tries to "restore" the segments it doesn't properly restore the hidden fields (because it can't) meaning that segment register is no longer in unreal mode.
Unless the BIOS switches to PM, there's no way to touch the "hidden parts" of the segments. Although not really BIOS, HIMEM.SYS switches to PM iirc for doing XMS copying of memory chunks. Your plain old standard BIOS does not though, afaik.

JAL

My (admittedly limited) understanding was that XMS managers ran the system in v8086 mode with paging - though of course this may be wrong - which therefore necessitated the introduction of VCPI to enter protected mode. (Then DPMI came along which is an altogether much cleaner solution)

Posted: **Mon Nov 16, 2009 12:12 pm**

jal wrote:
Firestryke31 wrote:The BIOS can load the segment registers when it gets called (either via HW or user INT) and when it tries to "restore" the segments it doesn't properly restore the hidden fields (because it can't) meaning that segment register is no longer in unreal mode.
Unless the BIOS switches to PM, there's no way to touch the "hidden parts" of the segments. Although not really BIOS, HIMEM.SYS switches to PM iirc for doing XMS copying of memory chunks. Your plain old standard BIOS does not though, afaik.

JAL

I thought reloading the segment registers in real mode flushed the "hidden parts" with the real mode compatible values (i.e. limit of 0xFFFFF and byte granularity). Perhaps I should read up on it though.

OSDev.org

Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode

Re: Unreal mode