Unreal mode howto?

[Jubbens]

The process of getting into unreal mode is confusing. Here's what I've done so far.

- Disabled interrupts
- Enabled A20 line
- Loaded GDT with segment values for real and protected mode
- Jumped to protected mode

Where do I go from here? I can't find a good guide and I'm kinda stuck.

Another thing, FASM doesn't seem to like to include files. I use
include 'myfile.asm' and it compiles fine. But when I go to use functions defined in myfile.asm, it hangs. What am I doing wrong here?

Thanks.

[AR]

• Enable A20
• Disable interrupts
• Set the protected mode bit in CR0
• Load a data segment register with a GDT Selector

You will then be able to access the whole address space from a 16bit realmode code segment.

[Jubbens]

...so that's basicly my list of what I've done in a different order. Does that mean I'm done? I thought you have to do something in pmode then jump back to real mode?

Any insight on the second question?

Thanks.

[RetainSoftware]

You have to do the jump back to real mode.

ljmp $0000:unreal
unreal:

Greets,

Rene

[AR]

Long jumping after having enabled the protected mode bit will attempt to load the descriptor from the GDT, which in that case is the NULL Descriptor which will cause a GPF.

Does FASM itself jam, or just the program when it's run? If it's the program that jams then you've most likely got a bug in the functions that prevent one of them from returning.

[Dex4u]

Fasm include file work fine, it must be your function that is wrong, also were you put the include file is very important.

[Pype.Clicker]

we have also a BabyStep about unreal mode ...

[Jubbens]

Thanks everyone for the unreal mode help. I'll see if it works once I get my include files working!

It's when the code runs that is producing the crash. I know that the code in the include files is fine, because it works when it is compiled directly into kernel.asm. The include files are in the same directory as fasm.exe and kernel.asm. I know that the code from the include files is in the compiled binary, because it is the same size as the kernel compiled with the include file's code directly in it.

[Dex4u]

Note: when i said the the place the include file is in was important, I meant its important were it is in the code.
if it for pmode you do not want it under "use16" etc.
Try puting it in the code were you want to run it and jmp over it, just to test if it in the wrong place, something like this:

Code: Select all

jmp     OverInclude
include 'MyInclude.inc'
OverInclude:
call   MyFunction

[Jubbens]

Thanks for the suggestion. But no change. :-\

Do I have to do anything to the include files to include them? This theoreticly should be working.

[Dex4u]

No, my include files are just filled with normal functions, eg:

Code: Select all

NameOfFunction1:
 ;some code here, including using var1 and var2
ret

NameOfFunction2:
 ;some code here
ret

NameOfFunction3:
 ;some code here
ret
;Data
var1   db  0
var2   dd  0

[Pype.Clicker]

i don't know what FASM is exactly able of, but with other assemblers i've experienced, you have a "listing output" mode that allows you to see what exactly is assembled (e.g. after inclusion, macro processing and the like).

That listing mode could help you to spot something you might miss (like a USE [...], ORG [...] BITS [...] SEGMENT [...] directive or whatever).