OSDev.org

[attachment deleted by admin]

maybe you could try to include some kind of "checksum code" for your kernel: before running it, sweep & add all of its bytes and see if it matches the constant you found when you did this operation of the file (before storing it on the floppy)...

and, well, moving your kernel to 0 seems dangerous design as it will limitate you to 28K (before you start overwriting the boot sector! why not ORG [0x10000] in your kernel or relocate it at that place so that it can directly run from there ?...

Limit to 28K? Argh... I guess I should try to load it to 0x100000 - the 1MByte line like most other kernels... How would I have to change my code? First, the linker arguments in the makefile will have to change to text = 0x100000, next I would have to change the code segments... How would I change the GDT? Would: ...Become this?

FritzOS loads to 0x1000 with a PMode C Kernel. www.sourceforge.net/projects/fritzos

does that help?

your changes seem to be nice, except you'll hardly succeed in loading stuffes above the 1MB barrier from real mode (where BIOS is), so i guess the best thing is to load it from 0x10000 (64K) to 0x9FFFF , which means about 512KB for your kernel (still not that bad).

I would change the A20 enable code to before I read the sectors from the disk... I have tried this code, but my computer dies before the kernel is shown...

Tom, I checked your boot.asm, and it seems as though you load your kernel at 0000:1000... What I am looking for now is 0001:0000 or 0010:0000... I am going to try to get my kernel to the 1MByte area...

If this is really what you want, then you'll have to (1) enable A20 gate in your BootLoader, (2) read block by block to a "conventionnal" memory address (because BIOS will write datas from your floppy nowhere else, and that's a shame because it could do it even in real mode as it uses DMA ), (3) move each of these block from the conventionnal buffer to its high-memory target address either using unreal mode and a rep movsb, or using the BIOS call for extended memory copy (somewhere in INT 17-19 if i remember well).

BOth techniques have already been discussed in some older threads of this forum. Search for "unreal mode" post by crazybuddah (in the time he had a scary red face )

Damn! Why does it HAVE to be sooo difficult!? >:(

Ok, 0x10000 it is going to be then... Allowing a max kernel of what? 512KBytes?

How exactly should I do this?

Tom wrote: FritzOS loads to 0x1000 with a PMode C Kernel. www.sourceforge.net/projects/fritzos

does that help?

Tom, That really does help! I have modified boot.bin to load the kernel to 0x10000. If you want, I can send you this file. Currently, you are limited to 28KBytes or whatever before hitting the bootsector, so you might want this or do the mods on your own or something...
Thanks

You welcome ;D ( I didn't make the bootsector all on my own, I had help from frank and someother people here ).
Your the first person I actually helped

I would like the code, do you have a web site, or are you going to post the code?

Also, how do you compile & link? ld -Ttext=0x10000?

I have run into that problem, but I thought it was a bug in my code.

I am at school right now, I cannot send the code at this moment(But this is Warmaster199). I can either post the code or email it later on. The boot code works, but my O.S. doesn't like it's relocation to 0x10000. The interrupts do not work correctly because an INVALID OPCODE continuously gets generated after I install the interrupt handlers and exceptions. I think that I might have to change around the IDT or something, am I correct? If so, I believe that the correction of the current code: would be... ...correct?(I don't have GCC installed at school. They use Norton Ghost so it would get killed on every start-up, but I DO have NASM and partcopy on my personal drive ) The code difference is in the shift of the offset of the idt from 0x0000:0x0000 to 0x0001:0x0000. I don't fully understand the offset field in the IDT, so I am afraid that it may offset it from the start of my code, although the offset could be from the start of memory to the start of my code... enough of my blabbering... is the code modification right or wrong? I'll check some docus at nondot.org during my spare...

If you're going to load your kernel somewhere besides address 0, why not load it at 1MB? And if you plan on writing a new bootloader and are just trying to test/debug your kernel, why not just use GRUB?

I know a lot of people hate to hear this, but since you already stated that you are just trying to test your kernel, why waste time with a throw-away bootloader when GRUB will do the job for you?

Just my 2 cents worth.

war199atschool wrote: The code difference is in the shift of the offset of the idt from 0x0000:0x0000 to 0x0001:0x0000. I don't fully understand the offset field in the IDT, so I am afraid that it may offset it from the start of my code, although the offset could be from the start of memory to the start of my code... enough of my blabbering... is the code modification right or wrong? I'll check some docus at nondot.org during my spare...

the offset of an IDT entry - as its name states - is a displacement from the base of your code segment. So regardless wether you have CS based at 0x12345678 or 0x87654321, your IDT entry will carry the same value for the handler. What is to be updated is the value of IDTR base, GDTR base, page directory (CR3), etc which are ABSOLUTE addresses...

however, if you decided to have a code segment based at 0x0000000, the address of your IDT entry will depend on where you actually load your code, but relocating text & data sections with ld should work fine in that case

[attachment deleted by admin]