Just keeps rebooting

[rexlunae]

Grub attempts to conform to the multiboot standard.  "http://www.mcc.ac.uk/grub/multiboot_toc.html" might help with that.  Grub is also capable of loading non-multiboot kernels.  When it passes control to a multiboot kernel, it is in protected mode, and the segment registers are set up for a flat memory model.  That might explain a few things, but I am not sure why that high an address would work.  Can you tell me what commands you use to load your kernel with grub?

As for setting up your IDT, the only thing you can't do in C is set up the idtr (the register which sets the location of the IDT).  However, it is one line of inline assembly.  The other thing you will need is a GDT.  Grub uses one to load the correct segment descriptors, but you will need one in order to load new ones.

If you want a basic reference for i386 programming, this will give you a starting place.
"http://webster.cs.ucr.edu/Page_TechDocs/Doc386/0_toc.html"

"I might really be better off not working on this thing anymore... just might not be ready for it..."

The only way to learn it to try.  When I first decided I wanted to write an OS, I thought I was going to do it in QuickBASIC.  hehe.  That was a _very_ long time ago.  Writing an OS is a surpisingly good way to learn about how computers work.  Good luck.

[mercury]

I have an ok understanding of asm, and by ok I mean, I don't sit there staring at code like this: o_O I've had experience in C/C++ and Java, I guess for my age I'm decently learned. What type of OS are you designing, if I may ask.

[rexlunae]

We are still working one some of the concepts, but we know a few things about it right now.  It will be a microkernel, using the ELF format, with C and inline assembly.  We use GRUB to boot, and the kernel has a multiboot header.  It will be POSIX compliant, and will resemble Unix in a lot of ways, although we plan on making a lot of changes to the directory structure, and we don't really want to use X as the primary gui.  

Currently our kernel is capable of forking child processes and running them concurrently, and there is a primitive ability to load programs from memory images.  However, there are several bugs not yet caught in the multitasking code, and there is no pointer validation for system calls, and really no device drivers yet.  Also, some of our interrupt handlers need to be made specific to the interrupt they service.

[mercury]

That's a LOT further than I've gotten. However, now that I get a week and half off from school, I should be able to get some more done. Anyway, thanks for the help bye.

[mercury]

I just realised something. If I now switch into protected mode(I think that's done automatically now through grub) will this code still work? I have to take this in a little at a time before I understand it. But don't worry, I'm sure I'll be going through the same thing you are, teaching others how to do this, pretty soon.

[mercury]

Hey, I just realised how stupid I am. I wasn't using grub. I am now though. Sort of. I can't really figure out how to get it to work though. Loads up, then just sits there after it loads the kernel.

I've been trying to use this tutorial: http://www.openbg.net/sto/os/xml/grub.html it isn't working TOO well.
I'll try some more stuff in C. Oh well.

[mercury]

Ok, it has to do with the multiboot header, I think. I'm not sure where to define the starting address and things like that.

I'm going to set up a page by tomorrow with the source codes and stuff. That might help clear some things up. Not that I really have much done. I wouldn't be writing so many messages on here, but I am a little pressed for time unfortunately. Oh, the address: http://osdev.m-esoft.net