Ah, ok, thanks!

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

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.

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.

Thanks ,
I am working on PXE driver.



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.

Thank You Guys, for your replies.