flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Flat Real Mode

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
smiddy



Joined: 31 Oct 2004
Posts: 559
smiddy
Ah, ok, thanks!
Post 30 Mar 2012, 02:37
View user's profile Send private message Reply with quote
dileep



Joined: 27 Mar 2012
Posts: 5
dileep
On some systems i am able to access 32bit offset without changing to unreal mode and not in other systems.
This is because some systems are left in unreal mode always.

So i registered #GPF handler and switching to unreal mode only when the handler invoked. Things worked fine.

Is it okay to use #GPF handler from my pxe ROM driver?

why does this work on some machines and not others? Are they already in unreal mode, left that way by the BIOS?

Is there any way to check whether processor is in unreal mode or not?

Thanks in adv
Post 03 Apr 2012, 03:54
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
dileep wrote:
On some systems i am able to access 32bit offset without changing to unreal mode and not in other systems.
This is because some systems are left in unreal mode always.

So i registered #GPF handler and switching to unreal mode only when the handler invoked. Things worked fine.

Is it okay to use #GPF handler from my pxe ROM driver?

why does this work on some machines and not others? Are they already in unreal mode, left that way by the BIOS?

Is there any way to check whether processor is in unreal mode or not?
I explained all these things in my text unREAL mode. Yes, installing GPF is a right thing to do, and in fact the only good way to implement flat real mode (but you have also to make sure that you distinguish GPF from IRQ 5, because the same interrupt may get called by IRQ, for example Sound Blaster). I've been running fasm with Cubic Player playing music in the background on sound card using IRQ 5 (and switching modes back and forth, because CP itself uses protected mode), and it was all behaving nice.

As for why system is sometimes in flat real mode - as I mentioned in that text, this is usually because of HIMEM.SYS, which itself uses FRM to quickly move memory blocks between conventional and extended memory. If you look at HIMEM.SYS source code, you can find in X386.ASM proc Int13Handler, which is the GPF handler, it also does correctly the IRQ 5 check, and sets up the flat real mode, which they call "Real Big Mode" there*.

And about checking whether processor is in flat real mode or not - just try to access some high address and see if GPF was fired or not.

__________
* BTW, that's a hint that the "big real" was a name used in old times, the file dates to 1989. Who did coin the "Flat Real Mode" term later? I don't know, but when I first met it, it was already under the FRM label.
Post 03 Apr 2012, 08:18
View user's profile Send private message Visit poster's website Reply with quote
dileep



Joined: 27 Mar 2012
Posts: 5
dileep
I read that link.
Things worked fine with GPF handler.

Actually i am working on pre-boot environment . So i need to make sure that the use of GPF handler won't cause any other issues.
Post 03 Apr 2012, 10:48
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
dileep wrote:
I read that link.
Things worked fine with GPF handler.

Actually i am working on pre-boot environment . So i need to make sure that the use of GPF handler won't cause any other issues.


I suppose you should be fine as long as you follow the correct protocol for BIOS and/or UEFI depending on which standard are you using. Generally keep in mind that DOS as well as other 32bit system expect CPU to be in real mode. Also keep in mind how the memory is being mapped from card ROM to RAM - you can't leave your int handler address in interrupt vector table if your handler will not be preserved or will be overwritten by system loader for example. So just follow the correct protocol for your firmware standard and restore system to correct state.

One more thing: if you are working in pre boot environment than it is to early for HIMEM.SYS to get loaded and become active obviously. Your BIOS might be using flat real mode for decompression of internal blocks to RAM or for SMM mode for example and this might be the case.
Post 03 Apr 2012, 23:52
View user's profile Send private message Reply with quote
dileep



Joined: 27 Mar 2012
Posts: 5
dileep
Thanks ,
I am working on PXE driver.

ACP wrote:

you can't leave your int handler address in interrupt vector table if your handler will not be preserved or will be overwritten by system loader for example.


I keep restoring the default GPF handler, after i am done with my work.
Post 04 Apr 2012, 04:15
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
dileep wrote:
Thanks ,
I keep restoring the default GPF handler, after i am done with my work.


Also restore other CPU/system settings after you are done. After all all loader expect certain environment.
Post 04 Apr 2012, 07:37
View user's profile Send private message Reply with quote
dileep



Joined: 27 Mar 2012
Posts: 5
dileep
Thank You Guys, for your replies.
Post 06 Apr 2012, 07:08
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.