Protected Mode help?

[beyondsociety]

[attachment deleted by admin]

[beyondsociety]

I have narrowed my problem down to the far jump that you have to make in order to enter protected mode.

In a earlier post, pipe suggested that I set up my gdt like this:

dw gdt_end - gdt - 1
dd gdt + 0x9000 * 16 + 0x0000

I then set up the far jump like this:

SYS_CODE_SEL:code_pm + 0x9000 * 16 + 0x0000

Does the loading of the gdt table before you enter protected mode have to be set up like this also?

ex: lgdt [gdt_ptr]

[beyondsociety]

[attachment deleted by admin]

[Pype.Clicker]

where do you load your kernel (what address) ?

[beyondsociety]

This is how I have set up my bootsector to load my kernel:

mov bx, 0x9000
mov es, bx
mov bx, 0x0000

so the jump to my kernel is:

jmp 0x9000:0x0000

I couldn't get my kernel to load as 0x0000 but it worked as 0000h which is the same thing.

0x9000 should be above the stack considering my stack was setup like this:

cli
mov ax,0x9000
mov ss,ax
mov sp,0x0000
sti

Is there some way I can set my whole offset for the kernel to zero so that I dont have to add a certain offset to my jmp to protected mode and the GDT base address?

[beyondsociety]

Why havent I gotten any replies?

[Pype.Clicker]

0x9000 should be above the stack considering my stack was setup like this:

cli
mov ax,0x9000
mov ss,ax
mov sp,0x0000
sti

Is there some way I can set my whole offset for the kernel to zero so that I dont have to add a certain offset to my jmp to protected mode and the GDT base address?

watch out: the stack pointer (SP) is the only register to be incremented/decremented when you pop/push stuff on the stack (i.e. you shouldn't expect the SS register to change by itself), so in fact, the first word you'll push will decrement SP and will go to 0x9000:0xfffe. So in fact, your stack is *ABOVE* your code rather than below it !!

[beyondsociety]

Should my stack be below my code or above it like I have it set to?

[Schol-R-LEA]

It should, in fact, be above it, given the way you have the stack and code equal to each other. The stack, by default, grows down from the highest address in the segment rather than up from the lowest. With the SP initialized to 0x0000, the first push will cause the pointer to wrap around, and write the value to locations 0xFFFF and 0xFFFE. It is probably better to set the SP value to 0xFFFF from the start (or, some say, 0xFFFE, so that it is word aligned) just so that it is clear where the top of the stack really is.

While it is possible to set the stack to grow up instead of down, that would be disasterous in this case - it woud grow right into the beginning of you code. Mind you, as it is it is possible for the stack to grow down and overwrite the end of you code, but that's unlikely; with the stack growing up, it would definitely trash part of your program.

In this case, though, there's another problem - you are writing your second stage code to the same area as the stack segment after you've been using the stack - which may trash you stack entirely, and leave the stack pointer in some random location in the middle of your code! You really should use a separate segment location for the stack, as that will prevent all of these problems (and some others as well).

Thus, if you have the stack at, say, 7000:0000, and put your
second stage code at 9000:0000 (or 6000:0000, or 1000:0000 - it doesn't matter where they are in respect to each other, any free area that doesn't overlap with the stack should do fine), you'll be far better off.

[beyondsociety]

I originally have my stack set up like this in my bootsector:

cli
mov ax,0x9000
mov ss,ax
mov sp,0xFFFF
sti

I was tired when I posted my code, and so I set the example stack up wrong in the previous post. Sorry about that schol-R-LEA but the explanation on stacks has helped.

My real problem is with my protected mode code. If you could help me out schol-R-LEA I would really appreciate it.

[Schol-R-LEA]

Sadly, I'm just learning about p-mode myself, and what I know is mostly what I've picked up on this board. I wanted to finish a small real mode OS first before diving into p-mode, and I'm still working on it.