OSDev.org

DynatOS wrote: Yes, 0x66 is a 32-bit operand override, 0xEA is the far-jump code.

Why would I need the override?

Why not place the override just above the jmp that I have?

If you are 100% sure that it will treat that code as a far-jump, go right ahead.

The override tells the CPU to expect the 32-bit GDT-VECTOR:OFFSET instead of 16-bit SEGMENT:OFFSET. It's the difference between a WORD:DWORD and a WORD:WORD

DynatOS wrote: If you are 100% sure that it will treat that code as a far-jump, go right ahead.

As far as I know, Nasm handles a jmp as a far jmp unlike other assemblers that optimize it to a short jmp...

nothing: I don't thinks so... And invalid IDT would either reset the computer or not matter since it isn't used.

DynatOS wrote: Try this...

Code: Select all

;;;;; Enter Protected Mode ;;;;;

mov eax,cr0
inc ax??????; This instead of Or Al,1 saves 1 byte
mov cr0,eax
jmp CLEAR               ;Clear instruction prefetch cache
CLEAR:
DB 0x66
DB 0xEA
DD EnterProtectedMode
DW SystemCodeSelector

I've tested it now and it didn't help...

Both versions (yours and mine) of the jump code, with the proper - 1 added on the the IDTR and GDTR variable, work fine on my tests, it jumps to protected mode and everything. Something is going wrong prior to the protected mode jump.

NASM alternative:

Curufir wrote: NASM alternative:

Code: Select all

mov eax,cr0
or al,1
mov cr0,eax
jmp SYS_CODE_SEL:pmode label

That's what I have in mine...

DynatOS wrote: Both versions (yours and mine) of the jump code, with the proper - 1 added on the the IDTR and GDTR variable, work fine on my tests, it jumps to protected mode and everything. Something is going wrong prior to the protected mode jump.

It may be because I'm tired but don't you first say that the code jumps correctly and then it doesn't?

I was suggesting a test of 100% assurance, the only way to do that is to map out the opcodes.

I disabled your NMI disabling code and bypassed your lessthan8MB test and it hanged where it should have just fine.

2 suggestions:
-Delete the NMI disable code, interrupts are already cleared, and it is a relatively short time between no IDT and an IDT at MHz speeds... if something happens to the hardware inbetween that short of a time... nothing you can do about it anyways
-Check your lessthan8MB for errors

Sorry about the doubling up far jump, missed it in your attachment.

Doubt it would be the problem, but SMSW is deprecated on processors above 286 afaik.

I think as you missed the -1 in the GDT, you also missed it in the IDT. Furter more i think you need more interrupt handlers, because the IDT of yours only traps the divide by zero (i think). If you add routines for the other 31 interrupts as well, that it'll work. But it can be the case that because of the missing -1 an int#1 get called. And in the IDT you didn't specify the handler for #1 correctly. So it's doing something wrong and unexpected(but not a triple-fault)

A trick is to write a different character to the screen for each int handler and halt. Then atleast you know wich interrupt trapps your system.

Hope this helps abit ,

Sephiroth Angellus.

Did anything the people here told you help you?