OSDev.org

0x08 (and 0x10 etc.) is the selector. I don't know whether or not it is hardware set.

It is ok for the DPL0 and DPL3 segments to have the same base and limit. Then they indeed overlap but the reel security is done through paging.

0x20:0x0 Is address 0 in ram
0x10:0x0 Is also address 0 in ram.

Is the Stack Pointer and BasePointer for the Stack, being set 0x20000 relative to the selected Data Segment?

Yes, the stack pointer and basepointer are relative to the BASE of the data segment.

I would personally keep the notation such as 0x20:0x00000 on segment terms. For selectors its relitavely insufficient information anyhow, and going to confuse you more when your switching from real mode and protected mode.

The Intel manual is a great refernce but it's not a substitute for a good tutorial. Also consider reading some working code (look at BSD or MIT licensed code if you don't intend to release you're source code, GPL code should only be used if you intend to release code under the GPL. A "private kernel" you never intend to release may one day change to a released product, so don't use GPL code in a private kernel).

Ok, well...
I cant find a bug in my Bootloader.

Im being given this error in Bochs:
fetch_raw_descriptor: GDT: index (17)2 > limit (16)

I have attached the source code for the Citadel Bootloader.

I dont understand why it is refusing to work now.
The GDTs are the same, albeit there is commenting between them.

Could someone please help me find the bug? Ill post the original Bootloader after this, which works.

~Zeii

Previous version of the Citadel Bootloader in Attached.
~Zeii

Got it, my bad.
I didnt set the base for the Data Segment.
*embarrassed*.
Sorry guys!
~Zeii.

Ahhh...
Ive finally setup IRQs and such, but... whenever I activate Interrupts (STI), My exception handler catches them.

'Division by Zero'.

Whaaa?
~Zeii

IRQs are initally mapped so that IRQ0 is interrupt 0, etc. Remapping the PIC is discussed almost everywhere, along with a million implementations.

Also discussed is that the timer interrupts at ~18hz by default.

Google, read the FAQ, and you should find what you're looking for pretty quickly.

Ive remapped the PIC.
With this:

void k_irq_pic_remap()
   {
      k_outPort(0x20, 0x11);
      k_outPort(0xA0, 0x11);   
      k_outPort(0x21, 0x20);
      k_outPort(0xA1, 0x28);
      k_outPort(0x21, 0x04);
      k_outPort(0xA1, 0x02);
      k_outPort(0x21, 0x01);
      k_outPort(0xA1, 0x01);
      k_outPort(0x21, 0x0);
      k_outPort(0xA1, 0x0);
   }

Still giving me Divide by Zero exceptions though.

Alrighty, ive written an IOWAIT function, just loops so many times...
Anywho.

Ive double checked my PIC Remap code with several sources,
OSFAQ being one of them, aswell as the docs on Bonafide OS Dev.

If I DONT remap the pic, I get double fault. (My exception handler catches it ).

If I do, I get a Divide by Zero fault. (Again, exception handler catches it).
So, Im left pondering WHHYYY wont it work.

Guess more research and such will light the way...
*pleassee light the way, dear beloved research!*

paulbarker wrote: IRQs are initally mapped so that IRQ0 is interrupt 0, etc.

No no, IRQ0 is interrupt 8 to begin with...if you don't remap the PICs a timer interrupt looks like a double fault.

Zeii: perhaps it's really a division by zero. Have you looked at the faulting address to see what instruction caused it?

Well, Ive mapped it - and it still doesnt work

Sorry, my bad on where interrupts are mapped to initially.

The fault will probably be caused by dividing by an uninitialized variable or some other code problem, if it is a real divide by zero error.

Take the faulting instruction and look it up in a kernel map if you have one (if not, you should be making one whenever you build the kernel, there *should* be info about that in the FAQ, if not then ask). Using assert() and printing values while running will also help.

I have no divide by zeros.
Ive also traced it in Bochs, no idiv command.
Also, the DBZ Fault only occurs when I enable Interrupts.

From what ive read, Bochs implements APIC. Also, most modern systems use APIC rather than PIC.

But, you can order APIC to enter Legacy mode, where it sends PIC commands and acts like a PIC.

I think thats the problem, But im not sure.

The APIC starts in legacy mode - unless you program it yourself, it will pretend to be a PIC.

By the way, the code I use doesn't have the last What happens if you leave that out? (I suppose you could be accidentally remapping the PIC to interrupt 0)